Two hours of thinking can save two months of coding
Many (perhaps most) programmers, especially when under pressure—e.g., at the start of a project with tight deadlines, or when trying to fix a bug—are eager to go as fast as they can, and demonstrate progress as early as possible. I’m definitely one of them.
However, many confuse speed with coding as much as they can, and feel unproductive (or even guilty) when not doing that. Unfortunately, this is more often than not the wrong approach: software problems are generally more complex than what they look at first sight, and if we don’t spend enough thinking time in trying to understand them better, chances are that our solutions will be either wrong or more complex than necessary, and, almost certainly, very difficult to maintain and evolve. [add example here]
Note that thinking does not have to be passive—e.g., staring at the monitor with a strange blank expression—but it can be very active indeed. In fact, it can be searching the web for information, browsing books and references (e.g., pattern ones) for inspiration, drawing sketches, hacking a prototype to try an idea (just be sure you discard the code afterwards), or even starting to solve it in small steps, possibly using Test Driven Development (TDD).
Unfortunately, success is never guaranteed; however, code written after the problem has been investigated for a while tends to be much cleaner and understandable than code written in a rush, so, even if the solution is not the best possible one, the code will be easier to maintain and evolve, and, possibly, refactor to a better design.
[this is work in progress]
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page