Here's a nice cautionary tale I found in Quora. Enjoy. 
Original: http://www.quora.com/How-do-I-train-myself-to-code-faster-and-with-fewer-bugs
Three programmers were asked to cross a field and go to the house at the other side.
The novice programmer looks at the short distance and says, "it's not far!. That will take me ten minutes"
The senior programmer looks at the field, thinks for a while and says "I should be able to get there in a day". The novice looks surprised.
The ninja programmer looks at the field and says. "Looks like ten minutes, but I think fifteen should be enough". The senior programmer sneers.
The novice programmer sets off, but within a few moments, explosive land mines go off, blasting huge holes. Taking him off course, and requiring him to double back and attempt the crossing many times. It takes him two days to reach the goal. Although he is shaking and injured when he arrives.
The senior programmer sets off on all fours. And carefully taps the ground searching for mines, proceeding only when it is safe. Slowly and meticulously he crosses the field over the course of the day. Only setting-off a couple of mines.
The ninja programmer sets off, and walks directly across the field. Purposefully and directly. He arrives at the other side in just ten minutes.
"How did you do it"?, the others ask. "How come the mines didn't get you?"
"Easy" he replies. "I didn't plant any mines in the first place".
---
Programming gets tough when we encounter logic bombs which we (or others) have planted for ourselves. We write logic bombs all the time.
And they sit there, beneath the surface, waiting to go off. Often with vast and unpredictable consequences.
With each new module of code added to a project, the project complexity goes up. Not in a linear level but by some exponential function.
The programmers mind is a limited resource, so this exploding level of complexity eventually overwhelms the programmer. At some point it becomes too much to hold in your head. That's the turning point.
That's when the bombs start to go off. The gotcha about not modifying the array while iterating goes off. Then the bomb where the array index is occasionally negative. And there's the one where the second thread can actually change the state of the object between the point where you enter the function and the point at the end. Boom, Boom, Boom.
I think the fastest, most, reliable programming is about developing a style where you avoid this class of problem.
Write code which clearly describes what it does. Select meaningful symbol names which are precise and unambiguous. Be very precise with naming schemes, don't use different words to describe the same stuff.
Adopt the simplest solutions if they are available. Do not optimize for speed. Do optimize for readability and transparency.
Don't fool yourself into thinking your code is magically reusable, if you didn't originally write it with reusability in mind. Instead, start with single use code, and keep it inline. If it makes sense to generalize it, then be prepared to re-write it completely.
Original: http://www.quora.com/How-do-I-train-myself-to-code-faster-and-with-fewer-bugs
Three programmers were asked to cross a field and go to the house at the other side.
The novice programmer looks at the short distance and says, "it's not far!. That will take me ten minutes"
The senior programmer looks at the field, thinks for a while and says "I should be able to get there in a day". The novice looks surprised.
The ninja programmer looks at the field and says. "Looks like ten minutes, but I think fifteen should be enough". The senior programmer sneers.
The novice programmer sets off, but within a few moments, explosive land mines go off, blasting huge holes. Taking him off course, and requiring him to double back and attempt the crossing many times. It takes him two days to reach the goal. Although he is shaking and injured when he arrives.
The senior programmer sets off on all fours. And carefully taps the ground searching for mines, proceeding only when it is safe. Slowly and meticulously he crosses the field over the course of the day. Only setting-off a couple of mines.
The ninja programmer sets off, and walks directly across the field. Purposefully and directly. He arrives at the other side in just ten minutes.
"How did you do it"?, the others ask. "How come the mines didn't get you?"
"Easy" he replies. "I didn't plant any mines in the first place".
---
Programming gets tough when we encounter logic bombs which we (or others) have planted for ourselves. We write logic bombs all the time.
And they sit there, beneath the surface, waiting to go off. Often with vast and unpredictable consequences.
With each new module of code added to a project, the project complexity goes up. Not in a linear level but by some exponential function.
The programmers mind is a limited resource, so this exploding level of complexity eventually overwhelms the programmer. At some point it becomes too much to hold in your head. That's the turning point.
That's when the bombs start to go off. The gotcha about not modifying the array while iterating goes off. Then the bomb where the array index is occasionally negative. And there's the one where the second thread can actually change the state of the object between the point where you enter the function and the point at the end. Boom, Boom, Boom.
I think the fastest, most, reliable programming is about developing a style where you avoid this class of problem.
Write code which clearly describes what it does. Select meaningful symbol names which are precise and unambiguous. Be very precise with naming schemes, don't use different words to describe the same stuff.
Adopt the simplest solutions if they are available. Do not optimize for speed. Do optimize for readability and transparency.
Don't fool yourself into thinking your code is magically reusable, if you didn't originally write it with reusability in mind. Instead, start with single use code, and keep it inline. If it makes sense to generalize it, then be prepared to re-write it completely.
Last edited:
