Making better use of your time

I came across this post on techcrunch.com and found many good suggestions that I am going to use to improve my day-to-day productivity.

Don't spend a whole day trying to solve one problem

For the last couple of weeks I have been working on an internal project, related to Web Industries' New Development Workflow. My task was to create a simple system to deal with git processes, such as creating shared repositories, pushing/pulling changes and allocating developers to repositories. During the development process, I got stuck several times with some small issues.

While it is normal to get stuck every now and then, I've realised that in the interests of keeping things progressing, it is not ok to spend the whole day trying to solve it. Of course, if it's a major issue that has triggered a whole set of nasty events, we probably need to solve it ASAP if it has implications for other pieces of work. But the principle holds true - we're far more likely to find a faster solution if we break the big nasty problem into smaller chunks and then work through addressing them.

While this seems to be obvious, some people neglect it and try to solve the whole thing in one shot. One of the principles behind the Lean Software Development model (which is applied in the Lean Startup framework), is to always work with short tasks. So, if there's a task that could take three days to complete, we should generally break that up into smaller portions.

This way, you can measure your progress more easily, and get a little motivation boost after finishing each task. Plus, by organising your thoughts to handle only one thing at a time, you'll find that you deliver faster - even after a few days following this approach I am noticing a huge difference!

Try to have a clear view of the objective

While it's tempting to add 'one more cool feature', it is even better to have something to show at the end of the day. Endless feature-creep is not a good place to be! Every new feature should be discussed and its purpose clearly defined. Just try not to spend five hours deciding upon one new feature. If it is taking too long, break the feature into small chunks and discuss each new addition separately.

This point is very important, I could see that sometimes I was coding without a north. I was just creating some new button but didn't have the whole picture of why I was doing it. And this usually leads to rework, as the feature wasn't solving the problem completely.

Ask for feedback

Every day we have a quick morning meeting to say what we are up to that day and to discuss how to avoid getting stuck on something. It can be a good strategy to introduce what you achieved in the day before - and, not just to talk about it, but actually show what you did - to the person that is going to use your product the most. If, in your scenario, this is a client, then sure, just show the new system to some and see if they approve the changes. If it is, as in my case, an internal tool, talk to the relevant colleagues that are going to use it on a daily basis and ask if your solution is the best one to solve that particular task.

As people usually say about git: "Commit often and commit early". This is exactly the point. If you can validate your solutions early, you should do it. This way, if we are heading in the wrong direction, we can just quickly turn around, instead of going all the way and realising that we hit a dead end.

Seja produtivo! :)