Two hours of thinking can save two months of coding - Revision history

Gasproni at 08:16, 3 July 2009

Gasproni — Fri, 03 Jul 2009 08:16:37 GMT

←Older revision		Revision as of 08:16, 3 July 2009
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]

Kevlin at 08:50, 1 November 2008

Kevlin — Sat, 01 Nov 2008 08:50:03 GMT

←Older revision		Revision as of 08:50, 1 November 2008
Line 8:		Line 8:

	[this is work in progress]		[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

Gasproni at 17:29, 27 October 2008

Gasproni — Mon, 27 Oct 2008 17:29:31 GMT

←Older revision		Revision as of 17:29, 27 October 2008
Line 8:		Line 8:

	[this is work in progress]		[this is work in progress]
		+
		+	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

Gasproni: New page: 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, a...

Gasproni — Mon, 27 Oct 2008 17:26:39 GMT

New page: 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, a...

New page

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]