The 3 Worst Developers I Ever Worked With
There are enough stories out there about how to be a 10x developer, whatever the hell that means.
I think these kinds of articles can be useful actually. They give us something to aspire to.
To know what good is however, you need to understand what’s bad.
I want to share with you the 3 worst developers I ever worked with and what made them so awful.
The names have been changed to protect the innocent.
Except for the first one…
The Dunning-Kruger.
Well this is embarrassing.
At the top of the list is me.
“Wait, your last name is Dunning-Kruger?”
No.
The Dunning-Kruger effect is when someone greatly over estimates their knowledge in a certain subject because they aren’t aware of how little they know.
YouTube is a breeding ground for these types and they make some of the most popular videos for early career coders.
“Coding is dead!” — dude who never worked as a coder.
“AI already took your dev job” — product manager at a startup.
“How to get into FAANG” — college sophomore who got internship at Microsoft.
I fell into this trap during my first 2 years as a professional developer. I would confidently tell our product manager that a feature was not possible because I did not understand it. I refused to learn ReactJS because “AngularJS is so much better” (RIP Angular JS btw). I wrote code that brought down our system because I didn’t understand the basics of Big O notation.
I thought coding as a profession was just getting things to work at any cost.
Forget performance. Forget maintainability.
My ignorance led to arrogance which led to sub-par code.
As an early career coder, you need exposure to differing opinions and technologies.
Here’s how to avoid my fate:
- Read books about software design patterns
- Join the Inner-Circle, a program for ambitious career changers who want to learn software (forgive me for the shameless plug)
- Learn system design (Alex Xu has great books on this subject)
- Research why your favorite library or framework exists
This can lead you interesting rabbit holes, expose gaps in your knowledge and help you decide where to focus your learning efforts.
The sneaky thing about this type of developer is that you don’t even know you are this type of developer 😅. I hope I’m not anymore.
The code bro
Let’s call him Brock.
This dude was actually pretty good at coding but that’s expected once you move past junior.
What made Brock a pain to work with is that he was, shall we say, less than truthful.
Each day during our morning meeting, Brock would give a status update on his work. Things seemed to be moving along at a good pace. Like most teams, we had some arbitrary deadline to launch a feature and businesses love deadlines (maybe even more than layoffs).
The day we were ready to launch, Brock hit us with a curveball.
“I need at least another day or 2 to complete this.”
We were all shocked.
Literally, every morning he had a chance to tell us if he was stuck or blocked or needed help.
Crickets.
Brock waited until the day our project was due to deliver us the bad news.
“I’ll need at least a couple more days to figure out this issue I found.”
Turns out the issue was that the feature was half-done.
Don’t be Brock.
I know it’s embarrassing. I know it’s difficult, especially if you’re newer to coding but you MUST raise your hand when you’re stuck.
Software is a team sport and there is no reward for suffering in silence but there is a hefty penalty that the entire team pays when you do.
Brock didn’t last too long on this team once he pulled this move a second time. And shockingly, a third time 😑.
The ass hat
I’ve actually met this type more than once.
Maybe you have too: super smart, super senior developer who knows how everything works and actually has really good insight into the business and codebase.
One problem: they are an ass hat.
How their ass-hat-ness may manifest:
- Overly brutal code reviews that leave no room for discussion
- Berating developers publicly or privately
- Hoarding critical knowledge so they can be the hero
- Sowing seeds of distrust among the team towards other devs or managers
These people are insufferable but sometimes the business will tolerate them out of fear that if they leave, the entire team will fail.
What a dumb move.
In reality these people rot the team from the inside out:
- Confident developers who are skilled simply leave or wait until the market improves to jump ship.
- Sub-par developers or those who cannot move, stay and tolerate the ass-hat. His power grows as the team weakens.
- Once the ass-hat leaves, critical knowledge goes with them and the remaining developers scramble to figure out what this person knew.
Sometimes this person doesn’t even know they are this type. So if this is you:
- Realize sharing knowledge and empowering the team makes you look stronger and sets you up for leadership roles.
- Resist your instinct to shut down less-skilled team members and instead ask questions or offer suggestions. Find out why they think what they do and offer an alternative.
- Fake it. Maybe you do think we’re all dumb keyboard jockeys. That’s OK. Don’t show us your true feelings and consider why, if you’re so smart, you can’t seem to break into any leadership positions? Could it be that you are in fact, an ass-hat?
I’ve met a few reformed ass-hats in my day and they are often the best types of leaders because they don’t rely on natural charm to reach consensus but methodical approaches they’ve had to learn after bring alerted to their own behavior.
Honestly, sometimes I wish I was a little more of an ass-hat myself.
Feels like something is missing?
You may notice how I didn’t mention any coders who just sucked at coding?
I’ve met plenty, including myself.
Please don’t take this to mean that you can be a terrible coder and have a wonderful career. That’s highly unlikely my boy.
A profession that includes coding is about a lot more than coding. Now that a junior dev can use AI tools to write mostly working code, expectations have risen.
Coding is a learn-able skill with well documented syntax, patterns and use-cases. What’s much less obvious is the professional part of being a coder:
- Understanding how to work within a team of humans
- Translating ideas from non-technical people into working code
- Designing maintainable software that others can extend
I write articles like this in the hopes you avoid these pitfalls or course-correct. I always hope you find it useful.
Good luck!
If you want to avoid being the worst coder on a team, change careers and build complex software. Join me here
