The question is not "What's wrong with this?" The proper question is "How can I make this better?" He's adopted a negative mindset by choice, whether he realizes it or not. That's not even what really grinds my gears about this post.
The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:
1. Write some code
2. Run the code
3. Get an error message
4. Find the error and back to step 1
There are some critical steps missing. A more appropriate approach would be:
0. Think about what I'm building
1. Write some code
2. Run (Test) the code
3. Get an error (of some sort)
3.5 Think about what might have gone wrong and verify it
4. Go to step zero.
That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.
Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.
God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.
The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:
1. Write some code
2. Run the code
3. Get an error message
4. Find the error and back to step 1
There are some critical steps missing. A more appropriate approach would be:
0. Think about what I'm building
1. Write some code
2. Run (Test) the code
3. Get an error (of some sort)
3.5 Think about what might have gone wrong and verify it
4. Go to step zero.
That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.
Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.
God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.