I’ve spent most of my career writing bad code – code that is ugly, hard to read, hard to understand, darn near impossible to update and fix problem. It’s bad code, not because it didn’t satisfy the original needs, but that it did so in a way that was not maintainable.
Most people (myself included) look at the code they just wrote and think about how great it is; how it’s so easy to read and understand, and how they will be able to use this code to do so many things. The thing that we forget, is that we are always looking at the code we just wrote through the eyes of context and short term memory. Of course I understand how that function works – I just wrote it. But in a few months, weeks, days… sometimes hours? Well…
For most of my career, though, I’ve had this lofty ideal of writing great code all the time. Worse yet, I’ve had this delusion that my code is somehow better than the code that I was reading from other people. But as I continue to grow and learn, in invariably look back at my old code and think about how bad it is. I’ve come to realize – albeit slowly, over many years – that this is ok for a couple of reasons.
You’re Learning
Most of the bad code that I write is because I’m learning – learning a new language, a new framework, a new tool, a new API, a new … something. When we’re learning, we don’t know the answers yet. That’s why it’s learning – to find the answers.
To find the answers, though, we have to solve the problem at least once – and there’s a good chance that the code we write will be bad, the first time we solve it. We can’t be concerned with good abstraction, clean code, elegance, simplicity or maintainability when we’re in learning mode. We have to focus on succinct, to the point, solve the immediate problem styles of coding with little to no regard for 10 minutes from now, let alone 10 days from now. This is the nature of learning.
You’re Ready To Learn
If you know you’re writing bad code, then you’re already one step ahead of the game. Knowing that the code you’re writing is a sign that you know you can improve. It’s a sign that you want to improve. It’s also a sign that you are ready (or almost ready) to take the next steps to improve.
Recognizing your own code as bad code is a sign of learning. That code you wrote 3 months ago, which you are now embarrassed to look at? That’s a good sign. It means you’ve learned since then. The code you’re writing for your current project, which keeps giving you bad feelings and making you nervous? At least that is recognition of the need to learn.
Recognizing your own code as bad is one of the best things you can do for yourself, you projects and your career because it means you want to learn and improve.
The Learning Experience
The real problem with bad code isn’t the code itself. The real problem stems from confusing the learning experience with solving problems for production systems. Far too often, we allow code that we know is bad to become production code. Sometimes this can’t be helped. Sometimes it isn’t a bad thing, either. But most of the time, the bad code that we wrote while learning shouldn’t be put in production.
Learning should be done in throw away projects, samples and demos. Rather than trying to learn how to use that library in your production code, build a demo app that mimics your production needs (to a minimum). Instead of deciding to use a new framework for the first time when starting a new project, take some time to play with it first. Dig in a little deeper than you think you need to, and try to understand how it works and why.
Separating the learning process from the production code process is important. Taking the time to learn how to solve a problem will produce better code and better understanding of the problem when you get back to your production system. You’ll be better equipped to deal with edge cases, additional requirements and other issues that don’t show up the first time you solve sometime.
Write Bad Code
You may not always have control over timelines. You might not have time to write a sample project for every idea., and sometimes you don’t have a choice but to release bad code. This is the reality in which we live. But I encourage you to to try, whenever possible, to write bad code knowing that you will be throwing it away once you start working on the production-ready solution.