

Writing good code requires you to perform experiments - edw519
http://confusion.tweakblogs.net/blog/1456/writing-good-code-requires-you-to-perform-experiments.html

======
Dove
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.

------
drewcrawford
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...)

~~~
calcnerd256
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.

