While we’re aiming for good, what’s often overlooked is — what truly passes for ‘good’ in a given setting. Good is highly subjective, and can mean different things to different people, in different situations.

This is applicable in most contexts — including software engineering. While we strive to write ‘good’ code, many of us might be oblivious to what good code should look like.

A major challenge when seeking ‘goodness’ is that it’s hard to visualise and measure. Any goal becomes harder to achieve if one isn’t clear on what the end result is supposed to be.

The Programmer’s Perspective

Imagine writing code without specs/tests. Sounds outrageous, right? The absence of specs implies that we don’t know what we are aiming for. So one can toil endlessly, but the entire endeavour is unlikely to yield any meaningful results.

Now recall the last time you refactored a piece of code. You begin with the aim of improving the code to a somewhat better state. After spending some time on the problem, you could notice significant change in your code. Perhaps you decomposed a method into two, replaced inheritance with delegation, or something else. Whatever it was, it improved the state and appearance of the code, and gave you a momentary feeling of respite.

While working towards something better didn’t take you to the pinnacle, it took you a step forward.

The end of good?

We are certainly not meant to stop chasing good. We only need to have a clear picture of what good is. If ever in doubt, of what good is, seek better. For no step is too small, as long as it moves forward.