There is a general pattern in professional people. We start out idealistic and adventurous, and as disasters inevitably accumulate we become more circumspect and pessimistic.
(Pre-emptive snarky response: “you say that like it’s a bad thing.”)
While pessimism is invaluable to a tester, it should be tempered with a just sense of hubris. Larry Wall’s saw about the three virtues of any great programmer has a historical antecedent from one of the canonical American authors:
We should be careful to get out of an experience only the wisdom that is in it — and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again — and that is well; but also she will never sit down on a cold one any more.
— Mark Twain, Following the Equator
Keep your childlike optimism.
Insight is a tricky thing. To a certain degree people are born with it (or without it) – but if you are gifted with a measure of it, you can develop it (as though it were a muscle) by working at it.
The late mathematician George Pólya had a number of helpful problem-solving mottos, one of which is the title of this post. There’s a nice echo in the chess world, where the maxim “If you see a good move, wait – look for a better one!” is popular (as is the simpler version, “Sit on your hands!”)
The granddaddy of them all is William of Ockham’s “entia non sunt multiplicanda praeter necessitatem“… AKA, Occam’s [sic] Razor.
KISS, as they say.
What am I going on about?
In the Computer Science world, it happens very often that your first idea… though it works… is inferior to your second idea. A great tragedy that is played over and over is:
- Developer is faced with a problem.
- Developer has brilliant idea.
- Developer starts coding. And coding. For hours. Straight.
- After a few hours developer pauses. Hmm. Developer has better idea.
- Developer goes back and hacks up what they wrote to implement the better idea.
- Goto step 3.
- Catch out-of-time exception. Finish the latest iteration as quickly as possible. Ship it.
I’m exaggerating a bit by calling this a great tragedy. It’s also a perfectly good development strategy to begin coding with the knowledge that you will probably come back and redo a large chunk of what you’re doing as you become more familiar with the problem domain. The key words here are “with the knowledge“… if you know that what you’re coding is experimental, you can avoid a lot of scheduling Sturm und Drang.
Bottom line: it happens frequently that a good idea has a better one as a sequel. Keep your eyes open… are you solving a specific case when you could, with less work, solve the general problem? Look at your fixed code fresh – are you introducing another problem with the fix? Is there a more appropriate way to fix the problem? Is it better to fix the symptom instead of the disease? Stop and think. Even if you don’t find a better way, it’s good exercise for your noodle.