Good Developer vs. Bad Developer

Hello, buddies! No one really wants to be labeled as a bad developer, but the sad reality is that a lot of developers aren’t even aware that they’re bad. So, today is the day to know whether you are a good developer or a Bad developer. Be genuine!

Bad Developer

If you’re still a beginner to coding and you’re worried if you’re producing bad code, in terms of ability you are naturally not good right now. However, don’t feel discouraged as there is one major characteristic that makes a developer bad, and as long as you don’t fall into that trap, you have room for improvement (i.e. You’re green, not bad).

So simply, I'm going to show you some characteristics of Bad coders.

Codes Very Quickly

Usually these types of bad devs can churn out new features far more quickly than the average dev, and unfortunately people who don’t know code would think these speedy coders are awesome (which only further bolsters the cowboy’s ego). These devs work best alone and for clients with extremely tight deadlines and who are only looking to get feature out as soon as possible.

Bad coders code very fast because they usually code on the fly — meaning, they code without any planning for future maintainability. Which leads to…

Messy, Unreadable Code

The code design of quickly built projects would be a complete mess (or rather, code design is non-existent). This sort of messy code is often referred to as “Spaghetti Code”, which is not at all as tasty as it sounds.

Spaghetti code is difficult to understand and is usually unnecessarily large and complex to the point where others will find it difficult to understand what the programmer does, and thus it is usually a nightmare to maintain. This means decreased productivity for the whole team if anyone is unfortunate enough to have to work with a bad coder.

The result of messy code is…

Bugs. Bugs, Everywhere

If a company’s software grows larger and more complex and their code is still a pile of spaghetti, then it’s just a ticking bomb waiting to explode.

What’s more, spaghetti code is not extensible. This means that adding new features to a Spaghetti code is like walking in a minefield that will explode, no matter how large or small the step and what direction you take. This is usually because a bad coder jumbled every functionality together, so any change would break the software altogether. This could be prevented with better code design and/or unit tests, but of course, cowboys don’t give a care for whether their code is usable and also don’t care for writing tests (something that takes time). Not to mention, with the way their code is structured thanks to bad design decisions, it’s hardly going to be testable or even debuggable anyway.

All in all, every bug and error created by a bad developer would cause negative productivity. At first it seems that this cowboy is being super productive by always meeting deadlines other developers won’t dare to promise, but this is at the cost of loads of “unexpected” errors that could have been prevented by well-designed and clean code programmed by a good dev.

Arrogance

As long as you are willing to take responsibility for your mistakes and as long as you are learning from your mistakes, you’re not a bad developer

The most important attribute that makes programmers bad is arrogance.

Bad programmers think their code is perfect and would blame customers for being stupid and for crashing their program rather than reflect on why their software crashed. Cowboy coders are usually selfish devs who don’t have a shred of empathy for others who have to clean up after all the problems they’ve created.

What’s more, these arrogant programmers also think others are beneath them in terms of intelligence. They’d usually assume people who need comments and who don’t understand their code are too dumb to work with them, but never try to think about why people don’t understand their code. As a result of always thinking they’re right and always thinking other people are inferior, they are uncommunicative when they build features, which can cause a lot of problems for a team. Some may think they’re so good that they would sometimes shun “best practices” or “standards” as they assume their own code is better (without good reason).

Worst of all, bad programmers are unwilling to listen or learn from mistakes because they don’t acknowledge that they’ve made mistakes — as mentioned before, they usually play the blaming game instead.

Good Developer

After rambling about bad developers for long enough, you probably already have an idea of what makes a good developer. Good developers should make up the bulk of the development workforce, and they usually have the following characteristics:

Awareness that there is always going to be a better developer
Humbleness and a willingness to take responsibility for mistakes as well as to learn from mistakes
Writes readable, structured code
Solid code design that can be debugged easily
Strives to understand how things work
Communicates/cooperates well with others in a team
Open to criticism and different approaches
Able to keep up with learning new technologies
Likes solving problems

Good devs are humble, responsible good buddies who will get things done and make sure everything works as it should, but they lack the curiosity and passion for coding that will make them “great”. That’s ok, however. Most employers only need good devs and they don’t really have a need for “great” developers. You don’t have to feel pressured to be a “great” developer, as you can’t force yourself to be who you aren’t.

After reading Bad Developer Part, you can understand more about Good Developer. Let's compare both.