“He who never made a mistake never made a discovery.”
— Samuel Smiles
Picture the scene: Scotland, 1928.
It’s probably raining (it’s Scotland).
A scientist accidentally contaminates his Petri dish with mold. Little did he know this mistake would eventually save the lives of millions.
His discovery? Penicillin.
His name? Alexander Fleming.
And his one small technical blunder changed the world for the better.
Fast forward a century, and today, the idea of (and vehement aversion to) mistakes sits uncomfortably in another realm — software development.
But why?
In a similar way to Fleming’s botched-batch-turned-discovery, coarse code can lead the way to unexpected surprises.
In this blog post, we’ll take a look at the influx of the notions of “good code” vs. “bad code”, and why we shouldn’t be afraid of achieving “bad” code in the first place.
Why “bad” code can be good
Let’s get one thing straight — we are not in the business of code-shaming.
But we’re well aware that there’s some bad code out there.
And that’s okay.
What’s not okay is how much we’ve come to rely on the term “bad code”.
The notions of “good code” and “bad code” have crept into the sector over the past decade or so, and it’s become quite a complicated matter.
Not because we can’t tell the difference — though that can sometimes be the case — but because we often put so much emphasis on writing perfect code from the get-go, that we forget that first drafts are a thing.
You can guarantee that the great artists, writers, and engineers of the world — your Da Vincis and Shakespeares and Teslas — never started creating masterpieces without at least one rough sketch beforehand.
So why are we suddenly afraid of rough drafts when it comes to coding?
And how can we rethink code and remove the word “bad” from our code vocabulary?
It’s simple: Bad code is an important part of writing good code.
“But that doesn’t make sense!” I hear you cry.
Put it this way: When you start writing a program, app, or even a random idea for a coding project, you shouldn’t be concerned with code quality.
You should focus on idea quality.
What does that mean? It’s about taking a step back from the pressure to create something ‘perfect’, without concerning yourself too much about the final result.
Getting something on paper, writing something that barely works but has good bones, will help you towards that goal of ‘good’ code.
You can’t build a body without a skeleton, after all.
RELATED: Enhancing Code Quality Through Your CI with GitHub Actions
Should we even call it “bad” code?
What do we actually mean by “bad” code?
Is it code that doesn’t work? Code that is full of bugs? Or is it just code that isn’t up to our standards?
Let me rephrase the original question: What does bad code mean to you?
‘Bad’ code means something different to everyone. Truthfully, it’s a vague term that could mean multiple different things.
And to developers, it’s just downright lazy – a one-word answer posing as non-existent, stale, flavorless feedback.
Slapping the “bad” label on something can actually do more harm than good.
It doubles down on driving more fear into devs who want to avoid doing something ‘wrong’ and getting the “bad” stamp at all costs.
So let’s decide today, as an industry, to fix it — no more “bad code” term.
After all, even “bad code” can still do what it’s supposed to. Does that really make it “bad”?
In fact, let’s rethink the term and create something more productive, something that’s more likely to boost developer confidence, and therefore productivity and velocity as a result.
RELATED: How to Improve C++ Code Quality
The goal is to write usable software and, yes, eventually good code
Don’t get it twisted. We’re not saying that you should grow complacent, write rubbish copy and just shrug your shoulders and leave it there.
It’s vital to write good code for a huge number of reasons — app speed, security, and maintenance, to name just a few — putting such an enormous emphasis on ‘bad’ code will make it harder to eventually write good code.
But the biggest takeaway from this is this: we shouldn’t be afraid of writing ‘bad’ code.
As long as we understand it’s only a starting point. And getting started is half the battle.
For those of us out there reviewing our team’s code — or heck, even our own — we need to get better at finding ways to critique our code without throwing our hands up in the air and saying things like “Ugh, this sucks”.
Being specific with our feedback will take us a lot further into getting the best out of our code.
Badmouthing won’t.
