Stop Calling it Bad Code

“This code is bad. We should refactor it.” is something I still hear frequently. “Bad code” has become the common way to refer to any code that's not up to our quality bar. I'm seeing it become a defacto description across the industry, blog posts and in software engineering literature. The summary of the classic book Clean Code starts like this: “Even bad code can function.” But while books and blog posts untangle what they mean by bad code, us, engineers, we rarely do. I’m just as guilty of this behaviour, often just calling code that is not good as bad or sloppy.

But "bad code" is a lazy expression. It’s not specific and means different things to everyone. Take this code sample that is an implementation of FizzBuzz. Is it bad code?

var fizzBuzz = function(n) {
    var outputs = [];
    let fizzDiv = 3;
    let buzzDivision = 5;
    for(let counter=1;counter<=n;counter++) {
        let currentNumber = counter;
        let FIZZ_OUTPUT = "Fizz";
        let buzzOutput = "Buzz";
        if(currentNumber % fizzDiv == 0 
           && currentNumber % buzzDivision == 0) {
            outputs.push(FIZZ_OUTPUT + buzzOutput);
        } else if(currentNumber % fizzDiv == 0) {
        } else if(currentNumber % buzzDivision == 0) {
        } else {
    return outputs;

Most people will call this bad code, indeed. But what if we banned using the term “bad” and started to be more specific? Then this code could be called inconsistent in naming, overly verbose and hard to maintain. If it was lacking tests, it could also be called untested.

Take this piece of code:

var fizzBuzz = function(n) {
    var o = [];
    for(let c=1;c<=n;c++) {
    return o;

How could this be described without using generic terms like bad? You could say it’s hard to read, the variable names are non intuitive. But some might also it concise or note the (overly) clever use of the ternary operator. Depending on the environment the code is being written, either of these code samples might be described as following or not following coding conventions.

Beyond just “bad code”

Instead of sticking to a lazy term, put some more effort to describe flaws of the code you see, and improvements you could think of.

  • Be specific on the flaws you see, even at the cost of being more verbose. “I find this function too complicated”. “This class has multiple responsibilities”. “The variable name does not describe its purpose clearly”.
  • Give a specific suggestion on how to improve the issue, if it not obvious from your description. Thins like “This class has multiple responsibilities. What would you think of breaking it into two parts, one being responsible for serialisation, another for price calculation?” or“I find the name calculate hard to understand. How about calling it getPriceWithoutVAT instead?”
  • Talk about the future implications of the code you see, if not changed. Things like “I think the class would probably be hard to reuse, because it has many things hardcoded.” or “I’m pretty sure newcomers would find this code hard to comprehend, as it does not follow conventions used across the codebase.”
  • Ask the person writing the code, what they think about your comments. Say thinks like “what do you think about this?” or “do you think this would make sense?”.

From “bad code" to “how to make this better” code

By not using generic and negative terms like “bad”, conversations about code become constructive. Instead of starting with an emotional statement - this code is bad! - you’re now starting with observations and suggestions. Using this approach, people who you give feedback to will not feel threatened and act reflexively defensive, pushing back on your comments. That is what would happen if you started with vague and judging terms, like “bad code”.

Even if it is bad code, take the time and energy to describe what is bad about it. This will help you grow your ability to verbalise of practices that make good code. It will also challenge your own assumptions on what good and bad code means to you, improve your ability to give constructive feedback and it will also help with mentor other developers better, helping them improve their code.

Featured Pragmatic Engineer Jobs

  1. Senior DevOps Engineer at Polarsteps. Amsterdam.
  2. Senior Software Engineer at Ladder. $150-175K + equity. Palo Alto (CA) or Remote (US).
  3. Senior Software Engineer at GetYourGuide. Berlin, Germany.
  4. Senior MLOps Engineer at GetYourGuide. Berlin, Germany.
  5. Senior Software Engineer (Reporting) at CAST.AI. €72-96K + equity. Remote (Europe).
  6. Senior Software Engineer (Security) at CAST.AI. €60-90K + equity. Remote (Europe).
  7. Senior Sales Engineer at CAST.AI. Remote (Europe, US).
  8. Senior Frontend Developer at TalentBait. €60-80K + equity. Barcelona, Spain.
  9. Technical Lead at Ably. £95-120K + equity. London or Remote (UK).
  10. Senior Software Engineer, Missions at Ably. £80-100K + equity. Remote (UK).
  11. Software Engineer at Freshpaint. $130-210K + equity. Remote (US).
  12. Senior Software Engineer, Developer Ecosystems at Ably. £80-100K. Remote (UK).
  13. Senior Web Engineer, Activation at Ably. £75-85K. Remote (UK).
  14. Web Engineer at Ably. £70-75K. Remote (UK).
  15. Staff Software Engineer at Onaroll. $170-190K + equity. Remote (US).
  16. Staff Software Engineer at Deepset. Remote (US, Europe).

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.