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.
Good Developer vs Bad Developer
- A good developer tries to understand their users, is involved in feature design and spec from conception (if possible). A bad developer feels that anything that is not coding is a waste of time.
- A good developer is able to instrument, tune and measure performance. A bad developer doesn’t know what those things are.
- A good developer is obsessed with learning new things, improving processes and voicing concerns. A bad developer is resistant to change.
- A good developer can give accurate estimates and timelines on work and be diligent with status updates. A bad developer makes you chase them up constantly.
- A good developer always puts the team and organisation before themselves. A bad developer only cares about delivering their own work.
- A good developer knows how to break down complex functionality into small deliverable pieces. A bad developer gets bogged down in problems and no progress can be seen “until it’s all done”.
- A good developer understands their work only has value once it reaches production and satisfies customers needs. A bad developer painstakingly agonizes about writing code which is only ever works on their machine.
- A good developer will always look to write the minimum amount of code possible to solve a problem. A bad developer believes their worth is related to the amount of code they write.
- Good developers understand the value of code reviews and pair programming. Bad developers get offended when someone critiques their work.
So buddies, honestly, I have 3 characteristics of a Bad developer and I'm trying to change them. Hey see? That's a good developer's characteristic(Just joking) What about you? Bad Developer or a Good Developer?
Top comments (2)
I'm not sure writing the minimum amount of code possible is a hallmark of a good programmer. Maybe I'm a bad programmer, but I think clarity beats cleverness. I'd rather have 3 or 4 lines I can clearly understand than a nested one-liner.
That's correct and you are a great dev if you prefer clarity.
I think author wants to point out something else. I am saying this because it happens with me sometimes. I write some function(50-100 lines) using my "awesome coding skills" only to realize(in code review) that there was some other function already doing very similar task and I could've just refactored and reused it.