How to Write Good “Bad” Code

If you’re anything like me, you take lots of pride in your work. This is usually a good thing, but in the software developing and consulting world, it can sometimes become a hindrance to your clients. Sometimes, writing bad code is actually the right solution to a development team’s current problem. What I mean is that perfectionism with the code you write can get in the way of progress on your project. What I don’t mean is that it is alright to lower your standards, write some bad code, and never come back and improve upon it.

When should I write “bad” code?

Sometimes on a project, you can find yourself stuck on a problem. Maybe you have a working solution that contains a bad coding practice or two. Or, maybe you’re just plain stuck with no elegant solution in sight. I know I’ve found myself in both of these situations countless times. Sometimes, I’ve been hemming and hawing over the problem for what feels like too much time, an intuition that comes with time as a consultant. When this happens, I know it’s time to reach out to a more senior dev and ask for help getting unstuck.

But what if the senior developer isn’t around? Maybe they took the day off, and you still have more than a few hours left in the working day. The wrong thing to do here would be to continue banging your head against the wall trying to find the perfect solution. That could result in halting development for the rest of the day. This would waste both your time and your client’s budget. I argue that this is the perfect time to write some bad code. 

How do I unblock myself with “bad” code?

Even in some of the trickiest situations, developers can usually unstick themselves with bad code. Maybe this comes in the form of making multiple database queries that you know you could somehow consolidate into one. Or maybe it’s a really gross and complicated iteration over list. In either case, write the bad code that you’re uncomfortable with and move on to the next thing for the time being.

The key phrase here is “for the time being.” Don’t just write the code and never come back. Maybe leave a TODO by the poor code so you have a reminder to come back to. I even like to throw in a question pointed at one of my seniors in the comment. Here, I’ll explain what I think is wrong with the current code or what I think could be better. This usually prompts a coaching session later on.

Now that you’ve unblocked yourself (with some shameful code probably), you’ve freed yourself to move on and solve other problems with your client’s budget. I’ve found that, more often than not, once I shift my brain’s focus away from the problem I was stuck on, the solution I was looking for comes to me. Often, I can circle back and “perfect” it before I even need to show someone else my disgusting solution.

If the solution still doesn’t come, however, don’t fret. You’ve still freed yourself to solve other problems while you wait for a senior dev to come up for air and help you. Sometimes the bad solution you write can be the perfect prompt for a senior dev to contextualize the problem you’re trying to solve and help you out.

Is pride getting in the way?

Writing bad code boils down to an issue of pride if you ask me. It can be hard, as a developer paid to write quality code, to accept that you don’t know the solution to a problem. Accepting this reality, trying something wrong or inefficient, and learning from those mistakes is how we get better and spend less time stuck on problems where we’re forced to write “bad” code.