How I boost my productivity as a developer - part 2

Nov '14

Over the years, I have been forced to become more productive. I ended up making a small check list of both mental and technological tool to help me getting the maximum of myself during the day. Here it is.

Being more productive is a simple ratio between time spent to perform a task and the output that you get out of it. While you can perform a task as a hobby and get next to nothing out of it, we will focus on pure professional execution here. Being productive, to me, is how many tasks I can perform during a day with maximum quality. While I tend to say that "good enough is good", I dont want to have to iterate on that task later so when a task is "completed", it should be useable, not in the way for my future productivity.

In a previous post, I already mentioned a couple of tricks like the excellent bullet journal, or understanding your tools. This is the necessary blocks to build upon.

Now that you have the basic tools (if you dont, go and read this previous article), it is important to get the mindset right.

Let's jump into some more specifics.

Be harsh with yourself

At any time, ask yourself if what you are doing makes sense. If it doesn't, or if you are uncertain, leave that task and move one to the next one. You will be amazed by how efficient this is. Both mentally and in term of outcome. Feeling that what you do is important is the #1 reason for you to give it maximum attention and quality.

Prevent any interruption

Recently, as I signed a freelance contract with a company, I decided to kill any interruption. Goodbye facebook, twitter, phone notifications and sms. I also answer to instant messaging with my fellow co-workers only when in between two tasks or when the message is urgent (or coordination).

Read the documentation thoroughly before embarquing on a new development path

This apply to explorative development or any new project you might start. Reading the documentation upfront can be counter intuitive when you "just want to get stuff done" as quick as possible. I agree with that. But if you plan on building anything stable on the long run, reading the documentation first will help you building something more robust, with less refactoring in the long run (and even help you to make the good choices at times), saving you a lot of time for other tasks. In my book, it is OK to spend a day reading the documentation of a framework. You will endup saving about a week of trial and errors down the road anyway because "you know" how things are working.

Reduce progressively the number of break you take during the day

Productivity is hard because your energy level is decreasing during the day, and because days will never ever contain more than 24 hours. This sets an upper bound to any productivity afficonado. One thing that I found relevant is how many time do I take a break, either by browsing randomely on the internet (hello hackernews) or just doing something unimportant and chatting with someone. I then decided that I would only take a break every 3 tasks performed and that break should be extremely rewarding. A kind of game about quantity versus quality. Rewards can be playing a game, making myself a good cup of coffee and drinking it away from the computer, or simply enjoying 10 minutes on the balcony. A real break makes me feel refreshed. If it doesn't, I can take a nap too.

Is that enough ?

Part 1 was more based on technical solution and this part is more on the human side. At times, you will leverage one or the other. They both work and can be combined easily. I have myself improved my productivity and also my level of satisfaction at the end of the day. I can now go to bed saying "enough for the day!".

It is a great feeling that I encourage you to experience.

comments powered by Disqus