How To Tell If Someone Is a Bad Programmer

Listen to this text here!

0:00

/617.848163

1×

What makes a bad programmer?

Let's first agree on what words mean before we talk about them. What makes a good programmer? It's pretty simple: a good programmer is any professional who gets hired and creates maintainable and understandable code that other devs can then build upon.

Now, defining a bad one is not that straightforward; many traits make someone a bad programmer. This article will discuss which signs to watch out for in programmers, and we’re also recommending you shouldn’t be so dismissive about certain scenarios that could be considered part of “bad” coding. For example, when we sourced our opinions from various developer sites, we noticed that, as a rule, inexperience is never categorized as part of “bad programming.” Coders seem to agree that being inexperienced is quickly remediable, while other signs of being a bad developer are not so much.

So, we’ve put together a list of what the Internet believes are the most typical kinds of bad developers, and we’re also offering quick ways to spot them. These are the main characteristics of a bad programmer in 2023:

1. The arrogant developer

This type of developer will not admit they’ve hit a brick wall — and almost always proceed to berate you for not being as smart as they claim they are. According to social media lore, arrogant developers are so abundant they’ve even been categorized into three subsets. Yes, that’s the extent of their influence. Forum boards usually define them as:

• Apathetic-arrogant developers will tell you off for your allegedly lousy coding practices, but will never offer help.
• Lifeless-arrogant programmers are those who learned one or two specific programs or technology stacks and have never felt the need to branch out. The lifeless-arrogant programmer won’t code in any language other than Java. Then again, that would be in their own right. Now, the lifeless-arrogant dev will loudly bad-mouth “new” tech stacks such as (scoff) Python, Go, or C++. Moreover, they won’t forgive junior devs who complete a full-stack course and will hurl mean jabs even if the person sharing the diploma on LinkedIn is just 19 years old. “Full stack, huh? Back in my day, we programmed in 15 languages, and we didn’t even dare to call ourselves ‘code artisans,’ which is what we were, honestly.” Now, where’s your human touch?
• Rockstar-arrogant developers are those who believe they are celebrities in the programming world and therefore can't do teamwork. These kinds of programmers can have the audacity to change APIs by the hour without telling others in their team, as everyone should consider themselves privileged to work with them.

🔍 How to Spot: They're quick to criticize but never offer constructive feedback or help. They're die-hard fans of specific tech stacks and ridicule anything new or different, even if it's more efficient or popular. They consistently update the API, causing breakdowns in other parts of the system, and when confronted, they brush it off saying, “It's better this way, just adapt.” Yes, you got what we’re saying: we’re basically explaining to you how to spot a jerk.

2. The robotic code applicator

Code can’t solve everything, and there are some programmers who think it can. This person ran into an error, did a quick Google search, and applied one of the first solutions they found. It's a never-ending patch upon patch that needs to cover up the errors of the first one. These people will often say they understand something when they don't, robotically applying codes without a proper investigation and identification of what is going wrong. These programmers typically leave chunks of dead code in commits when pushed for time.

🔍 How to Spot: If a developer's first step after an error is always a Google search followed by random code patches without understanding, you've spotted one.

📌 Example: An application throws a database error, and they instantly add a database retry mechanism without understanding the root cause. And they do this while browsing through Stack Overflow and yelling, “I don’t get it!”

3. The inadequate (or non-existent) tester

These are programmers who believe they don't need to test their code, as that is the job of the testers. This attitude has never been wanted and is never going to be. Part of it comes from a lack of interest in setting up a testing environment, and partly from a lack of coherent knowledge of testing. When writing an application, you need to ensure that it does what it is supposed to do. How? By testing it. If you refactor something, test to make sure that nothing breaks without intending it to break.

🔍 How to Spot: Their commits rarely, if ever, include test cases, and they often say, “It worked on my machine.” (At least so they say…)

📌 Example: A new feature works perfectly in a dev environment but crashes the staging server because it was never tested outside their local setup.

4. The short-term investor

A programmer who codes, deploys, and moves on. One that has no intention of learning the issue whatsoever. You will get working software, but nothing else will be achieved from it. The first time their application runs successfully, they think their job is done. Because of this, they never think about clear and maintainable code, which will impact the future of the project and its reusability.

🔍 How to Spot: They have a 'fire-and-forget' approach, never revisiting or refining code after initial deployment.

📌 Example: They implement a quick fix for a bug but don't spend time ensuring the architecture remains clean and maintainable. So in a JavaScript web application, there's a bug where unauthorized users can access restricted resources. To fix it, a developer added a quick validation check to the login process. However, they don't spend time refining the code or considering long-term consequences.

5. The authoritarian “code maestro”

It’s their way or no other. The term “project ideas” is non-existent. There is always going to be an argument about a code that discomforts them, even if it does work. They tend to think there’s only one way to solve the problem perfectly and will burst if it is not done their way. This kind of programmer is a bottleneck to productivity and will start pointing fingers if under pressure. They’ll also bring up claims that sound very credible to an executive, but fellow programmers know that they’re just nonsense, such as “You can’t help me with this because you’re not a mobile developer!” It’d be like saying: “You can’t teach me to play a G chord because this is an electric guitar, not an acoustic guitar.”

🔍 How to Spot: They often have lengthy, aggressive code review comments and resist alternative solutions to problems.

📌 Example: A team member suggests a more efficient sorting algorithm — such as Quick Sort on JavaScript — but they reject it purely based on their personal preference for Bubble Sort.

6. The overcautious panic-monger

The developer panics when learning that something in the registry needs changing or when things need to be input in the database. One that freezes when finding out that he has to write a Python script when he specializes in Java. These developers will do anything to avoid getting out of their comfort zone. Many developers pray for their favorite language and stay at a tool that is not fit for the task they need to do.

Some of these programmers are stuck in a time bubble and believe what they are used to is the right path, but this is a profession where everything is evolving, always. Part of being a good programmer is to stay abreast of things to solve problems more efficiently. Overcautious programmers usually tend to avoid conflict and discussions that could help them from following the wrong path.

🔍 How to Spot: Their pace slows considerably outside their comfort zone, and they often hesitate or avoid unfamiliar tasks.

📌 Example: Tasked with writing a small script in a new language, they spend days researching basics rather than diving in, saying out loud that the company’s new direction regarding their tech stack will doom us all.

7. The lazy developer who does not care

We've all encountered them at some point—the developers who opt for the quickest solution, often at the expense of code quality and long-term maintainability. They're the “lazy programmers”, and while their shortcuts might offer temporary relief (“Thanks to my input, we shipped the iOS app in a record-breaking six days”), they can result in hidden defects and technical debt.

🔍 How to Spot: A classic sign of such laziness in Python is the notorious except pass construct. This is a catch-all approach to exceptions, effectively sweeping all errors under the rug. Instead of addressing issues head-on, these programmers mask them, potentially leading to elusive bugs 🪲 down the line.

📌 Example: The crux? Good developers handle exceptions with precision, specifying which ones they can manage and always staying informed about unexpected errors, often through logging. If except: pass is a programmer's go-to without a valid reason, caution is advised.

So… are you a bad programmer?

You surely met a bad programmer at one point in your life or will do so eventually. All programmers were awful at some point in their careers, but that did not make them bad software engineers. Those of them who care to learn, get better, and do a better job at every opportunity.

The thing is, to do so, you need to admit that some things you do are wrong and can be better. Good programmers need to be confident with criticism and know that sometimes, having to rewrite all their code is the best thing one can do for the team and themselves as well. You won't be a bad programmer if you care not to be one.

You’ll soon notice that being a good or bad programmer is really about the culture. Make sure to check company reviews to try to understand a company’s culture and see if any comment a colleague left makes you suspect that there’s a bad programmer prowling.