Two hours of thinking can save two months of coding

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (08:16, 3 July 2009) (edit) (undo)
 
(One intermediate revision not shown.)
Line 1: Line 1:
-
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.
+
Many (perhaps most) programmers, especially when under pressure—e.g., very close to a project deadline, 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 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]
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).
+
Note that thinking does not have to be passive—i.e., staring at the screen with a 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.
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]
+
 
 +
By [[Giovanni Asproni]]
 +
 
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
Back to [[97 Things Every Programmer Should Know]] home page
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

Many (perhaps most) programmers, especially when under pressure—e.g., very close to a project deadline, 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 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—i.e., staring at the screen with a 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.


By Giovanni Asproni


This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools