This is excellent advice. I constantly experiment when writing code. It is one of the main reasons that I'm such a fan of using a scripting language like Perl to shake out an algorithm before committing it to whatever language I'm really working in.
I particularly agree with the comment about rewriting code. I typically force myself to re-type the solution at the end of an experiment (or I'm forced to by the fact that it's two different languages), resulting in clearer expression, better comments, and just generally cleaner results. The reason is that the second time through, I can focus on presenting the solution rather than finding it. (Moreover, it is not that uncommon to find bugs in the process of thinking about how to make it most apparent to the reader that the code is correct). I am of the opinion that rewriting an essay or a piece of code almost always improves it, and in some cases this is a sound investment.
One advantage the OP doesn't really discuss is that the short dev cycle encourages you to more fully characterize the behavior of what you've written. When plugging a solution into the larger app, it's tempting to say, "huh, looks like it works," and move on. But if you've got it isolated and under the glass, you can poke it a bit. Call it in funny ways, give it unusual inputs, think about how robust it needs to be. It doesn't really take long -- a few minutes, maybe, if you've got the framework already set up -- and it cuts down immensely on subtle bugs. Confidence that you understand how important sections of the code work is an immense boon, and can result in weird long stretches of simply . . . writing things that you know are correct.
Overall, I agree wholeheartedly with experimenting. I think it is a faster way to work that also produces significantly higher quality results. Just don't get carried away -- like comments, you should only indulge when it's useful to dispel uncertainty.
And yet, all the rage in hiring processes is to present some ridiculous coding problem and hire the first person who can guess the right answer quickly and explain it over the phone within 30 seconds of thinking of it.
Don't get me wrong, I'm all for thinking on your feet, but if you do anything remotely hard at your company you need to hire people who are willing to experiment rather than arguing the first solution that comes into their head.
(Sorry, still a little bitter about that last interview...)
Thanks for that comment. It's always important to compare our metrics with reality. So if we are selecting in a way that punishes the right way to do things, complaining about it is an appropriate first step.
The author's notion of "experimenting" is "debugging". I'd rather have someone write it correctly the first time than have to debug it; however, knowing how to debug well is also essential.
I particularly agree with the comment about rewriting code. I typically force myself to re-type the solution at the end of an experiment (or I'm forced to by the fact that it's two different languages), resulting in clearer expression, better comments, and just generally cleaner results. The reason is that the second time through, I can focus on presenting the solution rather than finding it. (Moreover, it is not that uncommon to find bugs in the process of thinking about how to make it most apparent to the reader that the code is correct). I am of the opinion that rewriting an essay or a piece of code almost always improves it, and in some cases this is a sound investment.
One advantage the OP doesn't really discuss is that the short dev cycle encourages you to more fully characterize the behavior of what you've written. When plugging a solution into the larger app, it's tempting to say, "huh, looks like it works," and move on. But if you've got it isolated and under the glass, you can poke it a bit. Call it in funny ways, give it unusual inputs, think about how robust it needs to be. It doesn't really take long -- a few minutes, maybe, if you've got the framework already set up -- and it cuts down immensely on subtle bugs. Confidence that you understand how important sections of the code work is an immense boon, and can result in weird long stretches of simply . . . writing things that you know are correct.
Overall, I agree wholeheartedly with experimenting. I think it is a faster way to work that also produces significantly higher quality results. Just don't get carried away -- like comments, you should only indulge when it's useful to dispel uncertainty.