Improving Programming Productivity
Paul Homer has a post listing several ways in which you can waste your time while programming. Much of the waste comes from lack of thought about how to write code, primarily because people jump directly from specs into coding without thinking about how they can structure their code well. I sometimes read articles about how test-driven development (TDD) will solve that problem by forcing developers to think about how to test the code, magic happens and the design is all perfect.
TDD is good, but as usual, when people find something has benefits, they try to turn it into a silver bullet, ignoring everything else that must be done. The fact is that to be good, programmers need to think deeply about their code. Not just while they are at a computer typing stuff in, but also while they are away from their desk. They need to be visualizing, critiquing and fixing their code while they cannot see it. They should be actively thinking about how to make the code better when they are not engaged in other tasks not requiring deep mental thought, like walking or taking a shower.
This is one important reason why programmers should not do multiple non-trivial projects in parallel. If they do one project, they can think about that project and all the various things (for example, class design, database structure, performance needs, etc.) that are involved, and their mind can be busy exploring solutions, sometimes going down a dead end and realizing it is a dead end before they come to the keyboard.
Learning and hobby coding is also part of this. I recently read a comment on Hacker News by a person complaining how difficult it was to do any coding after hours because of family needs and so companies shouldn’t expect programmers to put stuff on Github. To be fair, I am somewhat sympathetic to this argument, as I know free time dries up as family responsibilities (spouse, baby) increase. But at the same time, if one doesn’t carve out some daily time to catch up on good practices and examples in their programming space, they will be wasting so much time at work using outdated coding paradigms.
Anyway, the point is “think” instead of being on auto-pilot. What functionality are you trying to achieve? What are the different possibilities and conditions you need to take into account? What is the right way to structure the data and the various relationships? What packages can you use to reduce coding time and improve quality? These and many other questions don’t require you to be staring at a screen. You could even close your eyes and come up with questions and sometimes the answers. When you start doing that in earnest, then you start finding yourself a faster and more effective programmer.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)