On Programmers Productivity

This morning I stumbled on How to destroy Programmer Productivity by George Stocker, and Fire And Motion by Joel Spolsky. These posts talk about Programmer Productivity, especially the killing productivity patterns. So I though about sharing my positive productivity practices.


The number one productivity trick is to be passionate by the project(s) you are working on daily. You must believe in them. You must imagine how cool the result will be in one, two, three years from now. In several occasions I took a while to stop and think: hey NDepend (my project) has evolved so much during the last two years. Two years back from now, imagining it would have had all these new features and improvements was science-fiction, today it is reality, a reality that has been delivered to real-world users. How cool!

Patience and Confidence

So not only passion and even love is required but also patience. Measuring all the work achieved during the last X years makes me think that it will keep going up, one feature, one improvement, one bug fix, one line of code, at a time. Each past win is nurturing future wins, and will motivate you to be productive every each hour, because there is no more important (professional) things than that.

Today it seems I lost my whole day fixing a pesky bug, if I wouldn’t have been so dumb I could have fix it in half an hour! No stress, it happened to me tons of time in the past and looking back at all those years I can see it is the way to go. This is confidence.

Getting Started

One central facet of passion for a project, is to have a good idea of where we want to go. Short term (days, week), Mid term (months), Long term (years).

Short term means to me having my code base filled up with prioritized TODO comments, TODO5 being more urgent than TODO4. This sounds like a very rudimentary way of listing tasks but there is a strong advantage with TODOs.

TODOs are located where the coding action must take place. Hence starting working on a TODO eliminate the prior step of finding where to start in code. And the act of getting started (or actually getting not started) is a productivity killer. Hence everything that can possibly help getting started writing code is a productivity asset.

Another advantage of TODOs is that when all TODO(n) have been done, the job is done. No more TODO(n) is a very simple Definition of Done since all tasks surrounding coding (writing tests, code review, validation…) can and must be TODOed.

Getting Focused

Of course at a point, TODOs must be defined and then code must be crawled to find the best possible location where to write them. Typically this happens when starting working on a stuff (a stuff is what Agile and Scrum guys calls a PBI, Product Backlog Item). At this point a PBI gets transformed into (a few or many) prioritized TODOs, depending on the scale of the PBI. It can be a one hour bug fix or a feature that will take 3 months of dev.

There shouldn’t be more than 10 top priority TODOs at a time because one productivity important trick is to get focused on what to do. Hence a feature can be divided in 90 TODO1 and 10 TODO2. Once there is no more TODO2, then we can pickup the 10 next tasks to be done within the 90 TODO1 set. And if the current TODO2 to work on is too coarse, then transform it into 10 TODO3 and so on.

This way every morning you just have to search for TODO(n) in your workspace to instantly know what to do. This way you don’t have to think of what to do today, just get started and stay focused.


Imagining Mid-term (months) and Long-terms (years) goals is what can nurture passion and then day-to-day productivity. Two TODO lists must be maintained for that. Since NDepend follows Visual Studio releases our sprint duration is around 12 to 18 months. So we have one Mid-term list of what to do for the next major version that will be released in N months from now. The Mid-term list is driven both by ROI (Return Over Investment, the ratio of  Feature impact/ Dev effort) and the User Voice, that offers a good idea of each future feature impact. The same applies to the Long term list, except that this list is not limited by the sprint duration.


So far I especially covered some project management and organisation practices that are designed to boost productivity by maintaining the flame of passion intact. But Passion, Patience, Confidence, Getting Started, Getting Focused, defining Goals, are all about psychology. And there are several classic every-day psychology routines that are essential to keep up with high-productivity.

Having a sane and joyful life is of course essential. Personally I need something else than coding in my life. Friends, familly, kids and hobbies. Everyday several hours must be dedicated to something else than coding. One must sleep enough and work at regular hours. You must identify the hours when you are the most focused (typically early morning or late night) and struggle to be able to work during this privileged time. This might sounds obvious to you (and to me) but super-geeky individuals must be reminded that. You just can’t dive into code 14 hours a day and keep up with productivity in the long-term.

I found exercise being the number one creativity boost in my programmer life. Running often is for me a productivity routine. Not only new ideas comes to me gently, they just pops up to my mind, but endurance sport provokes endorphin’s hormones rush that can relieve most pain and stress. Runners actually develop an addiction to this, which is a pretty cool addiction. I consider sport-hours like being part of work-hours. Doing so is pretty practical to never miss a session. Btw I found recently that Alan Turing got many of his super brilliant ideas while running (he got almost qualified for 1948 Olympic marathon).

In addition to sport, I also do some every day meditation, especially mindfulness-based stress reduction (MBSR). This just works to get me more quiet, peaceful and focused. MBSR is a very simple activity that can be practiced several times a day in few minutes sessions. It consists in developing the ability to feel the present moment, by listening to the breath, the body sensation, the environment. The key is to develop the ability to be not emotionally disturbed by the flow of thoughts that constantly comes to the mind. We all know that to develop muscle one must train, but few realizes that brain can and must be trained as well. MBSR and meditation in general, is training to develop brain and cognition capacity.

When it comes to psychology and productivity we often hear of the notion of flow. Being in the flow means being totally focused to the current activity. The conditions for reaching the flow, which is the Saint Graal of the productivity are: being passionate about the activity and having solid skills. We often hear that to be skilled in a domain 10.000 hours of practice are needed. Flow is more for seasoned programmers. Another condition for the flow magic to happen, is to be challenged enough by the task. Flow cannot be reached when doing simple stuffs. The good news is that programming (well) is more often difficult than simple!

Of course avoiding interruption is also an important part when it comes to productivity. There are many interruptions you can control, like treating emails in batch mode twice a day, not arguing on the web, not periodically checking twitter or facebook… This is where the benefits of meditation and sport comes into play, because focus is increased.  There are all non-controllable interruptions, whether it is colleague, meeting, or kids (if you work at home). There is no more alternative than coping with that and be able to get back focused as quickly as possible.

There is this theory of reward that never worked with me. Like if I do code 3 hours in a row then I can go to the beach an hour. This just don’t work for me. I consider the reward to be getting the job done and then if I decided to go to beach an hour today, I will go anyway. Theory of reward maybe work for those that are not passionate by their work. It is your number one professional responsibility to find a job that will passionate you.

I hope sharing my practices of productivity can and will help you getting more productive! Now its time to get back to code (so do I!).

This entry was posted in Productivity. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://wesnerm.blogs.com Wesner Moise

    I posted a comment earlier. The viral link that I posted to was the wrong one, but both this and the one that I was looking for deal with habits of effective people and stages of maturity.I can’t find the link that I wanted to show.

  • http://wesnerm.blogs.com Wesner Moise

    Let me suggest a poster on maturity here: http://www.viruscomix.com/page532.html
    A compilation of different behaviors exhibited by people at different stages of maturity. There’s a ton of good advice in there, one of which involves keeping a journal.

    Mature people tend to keep journals. My reason for starting journals is that I find that I forget things that I want to remember, even if strongly and emotionally. A blogger talked about how he learned new things from senior people, smarter than himself; one example was seeing the use of a journal.

    I know that you are very well off, but you can still improve yourself even if you don’t need to.

  • PatrickSmacchia

    Since I have the chance to work on the same code base for 10 years, most of what I learned, pro/cons, urls, trade-offs… are encapsulated in dated comments in the code base itself. And indeed, daily I scan the code base for something I’ve done and I don’t remember exactly how. This is a real art to write comments that will be useful in the future :)

  • http://wesnerm.blogs.com Wesner Moise

    It’s not just a done list, but all the knowledge you gain that day, and things accomplished outside of any particular project. Things like hyperlinks, pros/cons tradeoff matrix of various decisions or purchases you made, info you came across the internet, solutions you found on stack overflow.

    It keeps your head clear and you don’t have to remember as much stuff, and retrieving past info is fast and predictable. For example, when I was using xamarin, I discovered a lot of gotchas that wasted my time and I was able to find solutions on the internet; sometimes, I come across the same problem months later and don’t recall the original solution. Xamarin doesn’t give rich errors for small typos that cause problems, like creating a Resource directory (which causes an app to fail on launch), exporting a property with an illegal type (cause runtime creation to fail silently), removing the window property of an appdelegate (causes launches to fail). The failures occur far from the source. Other issues I had were App_Data folder not being writable in a virtual directory on my server. Maybe I will remember the solution, next time; maybe I won’t; maybe another year from now or when I start a new website, I will forget.

    You can see what you were doing months or years back if you ever. You can review the past quarter or six-months.

    I don’t use pomodorro on a regular basis. Only when I am finding it hard to get started/procrastinating on a particular task, usually because it involves a lot of unknowns and research.

  • PatrickSmacchia

    Concerning ‘Keeping a daily journal of things that you have’ while I have a TODO list, I don’t need to maintain a DONE list. So much efforts and (dare I say) emotions have been put in each feature development that I can tell what I was working on almost each day (or at least week) during the past ten years.

    Concerning pomodorro timer I couldn’t use this. Being interrupted every 25 minutes is not an option. My dream work conditions is to have 3 or more hours in a row without anything else to do than coding, and then jump in the flow.

  • http://wesnerm.blogs.com Wesner Moise

    Other things I found…
    Keeping a daily journal of things that you have done during the day keeps you focused… I use evernote but onenote is good too. It helps to buy timesnapper ($25) with takes snapshots of activity during the day (every 10s).

    Time management… Using noprocrast setting in HackerNews. Reading blogs once a week in an RSS browser. Using the pomodorro timer technique.

    Set aside time for learning through a MOOC or an interactive tutorials (like codeschool). I just tell myself the time I spend doing this will likely be productive than anything else my brain suggests–just to get through psychological objections. Videos are often edited and streamlined. It makes sense to watch videos at higher speeds, particularly when the instructor speaks slowly; closed captioning is helpful when videos are played at double speed. MOOCs result in greater intellectual growth. If you take a lot of courses, you start to seeing recurring concepts and become aware of which ones are very important.

  • http://blog.developers.ba Radenko Zec

    Great post Patrick.For meditation I am practicing Qi Gong it is very similar to your description of MBSR.
    I think it is also useful to have good pair of headphones if you share office with others to reduce background noice. I also recommend some good music when you do repetitive tasks to relax and concentrate.
    I even have a blog post about Best music to listen while programming

  • Christian Bjerre

    Thanks for your insights, Patrick! I am impressed by how simple you express what I try to get into the hearts and mind of developers.
    if you don’t know where you’re going – how can you plan the best way to get there while you enjoy the trip? Often developers sit and work on something similar to a Death March (capital to honor Ed Yourdon :)). When they don’t – by themselves or by their leaders (not managers) – get to look at head and skip forward to where months and years are then they stay down and never get to where you are.
    I will use your post here as part of the internal mindset change I am starting on now. The developers are competent, but they need to see their work in a different light. At the same time the understanding of the work of software developers must be made more clear for project managers, consultants, accountants and management. As a professional software craftsman and their leader that is my duty – every day and in every decision.

    So maybe I should check back here a month or two down the road from here with an update?

    Once again thanks for a great post, Patrick!!!

  • PatrickSmacchia

    I talked about my experience with LoC here: http://codebetter.com/patricksmacchia/2012/01/23/mythical-man-month-10-lines-per-developer-day/ More and more my productivity measurement is made by feature size, not necessarily only LoC but also the instinct idea I get about a feature size. I know this feature took 1 month, this other 2 and half, so this helps me know how long will take this next one.

    As most of us, during the last 10 years I experienced significant life events that obviously impaired my productivity for some weeks or even months, but except that, I estimate being constant enough. So measuring productivity is not so much a yardstick, but instead a way to realistically anticipate what can be packed up within the next release, and which PBIs to choose (and which to postpone) to maximize users satisfaction.

  • Daniel Root

    Great post. I’d like to hear your take on how to _measure_ productivity in the way you describe. We all know by now that LoC doesn’t cut it. But are there numbers and cold hard data can I look at to see flow and passion in my work? Counting TODOs in a solution and TODOs killed seems like one good metric..

  • http://mike-ward.net/ Mike Ward

    +1. Pretty much sums up my experiences.