Productivity tips

Productivity is a highly subjective topic. What makes one person productive might not work for another. However, that doesn't mean that sharing your own experience is not useful for other people. If some of the following tips don't work for you, that is perfectly fine.😃

No distractions

Nothing kills productivity as much as being distracted all the time: kids, coworkers, bosses, cats, dogs, social media, ...

While you cannot always eliminate the source of distraction, you can minimize its impact (at least sometimes). When you know up front that you are going to be distracted, doing highly focused work will be frustrating and totally unproductive. At such times, it is more productive to do some tasks where being distracted will not harm the process as much. At least you will be able to do some work, as opposed to not doing it at all, or doing it poorly.

Getting into the Zone

Not all distractions come from the outside. If your own state of mind is not in the right place, pushing yourself too hard is not a productive thing to do. Again, doing easier tasks at such times will at least enable you to do some work, and you might also get into the Zone while doing them. Switching from one task to another (if it makes sense) will make you more productive than focusing on one task you are unable to do right at that time.

Take short breaks

Take short breaks between tasks, or at points where it will not be too much of a distraction. Taking a break will improve your ability to focus further. Also, keeping your mind off a problem for a while can often trigger your subconscious mind and present you with a solution.

Understand the problem

Writing code before you fully understand the problem is the least productive thing to do. If you don't understand the problem, the solution will usually be wrong, and you will waste time making solutions that don't fit well. Time spent planning and researching is time spent well.

However, you will sometimes need to make some quick proof of concept just to verify that you are going in the right direction, and that the idea you have is easily achievable in code. You don't need to have a complete understanding of a problem to do such quick tests.

Asking, rubber ducking and brainstorming

If you are stuck, ask your coworkers for help before you waste plenty of your time achieving nothing. However, make sure that you don't distract them and kill their productivity while enhancing yours. Rubber duck first before you ask others—you will need to explain your problem anyway, and presenting it to a rubber duck can often lead to a solution without getting others involved.

Brainstorming is a different category, and if you work in teams, having planned brainstorm sessions around some design choices is also good for overall productivity.

Good old notebook

Using a plain paper and pencil to make a draft code-flow is also a good way to brush up your overall design before you start writing wrong code.

Test of time

If you have some larger piece of code you need to design and write, then after you have drafted the overall structure, make it rest for a few days before you start coding it. If there are some obvious flaws, you will be able to see them more clearly if you give yourself some time.

Discard early

If you end up with a bad design or code that doesn't work well, don't be afraid to discard it and start over. The sooner you do that, the more time you will save.

Unit test

When you write code, unless it is UI-related, the fastest way to make sure it works properly is to write unit tests. This also saves you time later on, because such code will have fewer bugs. If it has bugs, they will be easier to find and fix than in untested code. You will also end up with a solid base that will enable you to apply changes and extensions to such code without breaking existing functionality.

Use version control and commit often

Making frequent code commits while you are working on some code will give you the ability to easily revert and start over from some good point faster, in case you reach a dead end.

Comments

Popular posts from this blog

Virtual methods in Delphi

Are generics slow?

Building better serialization