In a previous post I discussed the reasons some programmers are much more productive than others. But the fact is that every programmer experiences periods of time when he is much more productive than average, and I think there are several reasons for that.
Focus
It is clear that to be productive you must be focused. This means that, even if you have several things to do, and even if all of them appear to be important, you must be able to concentrate on a single task. This requires the ability to define your priorities and your posteriorities. Better yet, decide that there are things you do not really need to do.
Peter Drucker dedicates an entire chapter of his classical book, “The Effective Executive”, to this issue. In the chapter entitled “First Things First”, he says: “Most of us find it hard enough to do well even one thing at a time, let alone two”. Thus, multi-tasking is something that should clearly be avoided.
I believe that Agile Software Development improves focus because it reduces the granularity of programming tasks. Developers participating in a Scrum project normally have relatively small features to implement at each Sprint, and extensions are done iteratively. Agile methods also help the team to prioritize the tasks and focus first on the most important features, using artifacts such as backlogs.
Problem Solving Mindset
Programming is an exercise in Problem Solving and as such it is natural that programmers dedicate a considerable amount of time to think about the problem, analyzing its several aspects. In general a problem will have diverse possible solutions, and in this case the programmer needs to compare these solutions and understand their advantages and disadvantages.
During this time spent thinking the programmer will not write any line of code, so it may appear he is not producing anything. But when he has completed his analysis and found a good solution, he can suddenly implement all the functionality very fast and with few errors, becoming Super-Productive. I believe that this ability to dedicate enough time to analysis before jumping to a solution is a key for real productivity, but unfortunately it seems that not all programmers have this habit.
This is similar to a chess game. Watching a chess game may be very boring, because most of the time nothing is happening on the board: The players are thinking. But after they have decided what to do and chosen a strategy, they can move very fast. Good chess players can plan many steps in advance, and thus avoid making mistakes.
Inspiration
Many programmers claim that software development is a form of art. I believe that this is partially true, because, like painters or musicians, programmers need inspiration to produce really great software.
Everyone has at least once faced a problem that at first appeared impossible to be solved. No matter how hard you examined it, you could not imagine a way to overcome its difficulties. And then, suddenly, you saw the solution. You were inspired by something or someone that allowed your brain to follow a different reasoning path.
There are also these days when you just wake up inspired. Everything will appear easier, you will just sit in front of the keyboard and let the code flow directly from your brain to your fingertips, typing new instructions as fast as possible. In these days you are Super-Productive, even if you will never be able to explain why. Unfortunately, there is no general recipe of how to become inspired.
Pressure
It is not easy to admit it, but the truth is that most people work better under pressure. It is very easy to postpone some action or decision if you know that you still have lots of time to implement it. Most programmers work much harder when they get closer to the deadline. They often regret being complacent in the beginning of the project, when it appeared to them that the allocated time was more than sufficient. But it rarely is.
I believe that Agile methods improve this situation by defining short development cycles. For a team working with Scrum, each Sprint has a well-defined set of tasks that must be completed in a few weeks. The end of each Sprint is a deadline, and it is always close enough to make the developers feel they need to work intensively, since the beginning. They programmers in a Scrum team cannot postpone their work, because their progress is being measured on a daily basis and exhibited clearly in a burn down chart.
In Summary
There are several factors that may help you become Super-Productive:
- Focus: Defining your priorities and concentrating on a single task.
- Problem Solving Mindset: Thoroughly analyzing the problem and comparing possible solutions before implementing.
- Inspiration: That state of mind in which all your thoughts flow with amazing clarity.
- Pressure: Having a well-defined deadline, ideally in less than a month.
Notice that three of these factors may result of using the right methodology: You can systematically become more focused, adopt a Problem Solving Mindset and follow a Software Development Life Cycle (SDLC) with short iterations. But you also need to learn what inspires you. For me, personally, inspiration only happens when I face a challenging task.
Of course each programmer may have his own personal reasons that help him dramatically increase his productivity. For some people it may be compensation for improved performance in the form of bonuses or prizes. For others it may be the feeling of full ownership of a project, like “this is my baby”. Please feel free to use the comments below to share your experience. Thanks!
Nice post!
One thing to add on improving productivity is testing.
The notion that what I am coding now will be tested later on today is a great incentive to leave my source files in a working manner, and to focus on my tasks.
Thinking in testing up front is yet another drive for producing working software earlier
Thanks for your comment, Ilan! It was a source of inspiration for my latest post about TDD and Gamification:
https://effectivesoftwaredesign.com/2011/11/21/tdd-and-the-gamification-of-testing/
Devon,Both RUP and MSF process moedls employ a team’ approach that emphasize what Agile is now purporting. The issue really is not whether QA/Test needs to embrace Agile, it is that the other groups are finally catching up to what QA/Test has been trying to do for years.I’m in total agreement with Joe on this. Fifteen years ago I worked for a company that implemented MSF (Microsoft Solution Framework an Iterative model) and really bought into the Team’ model part of MSF. QA/Test was put on equal weight with the other groups and we were seen as the partners’ to development. We worked together, and not against each other.So realize that Agile is a process model that has gained acceptance over the last 10 years or so, but it is only as good as the people who use it and how much they buy-in’ to it. And that is true for any process model/methodology.
Pingback: Self-meetings: Avoiding distractions in the workplace | Effective Software Design