I originally posted this on my blog about a year and a half ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.
Let's do a reader question post today. It's been a while, huh?
I'm now answering different questions in different forums, so it can be hard to keep track of. But this one fits squarely in the realm of the DaedTech blog.
So let's do it.
This particular reader question is quite detailed, so I'm just going to post in verbatim without adding context. It doesn't really need it, in all of its detailed, semi-depressing glory.
Are Good Teams Writing Good Code a Myth?
The short version. Where are these mythical companies where people write code like you read about in blogs?
I'm in an odd place. While I'm no rock star I feel reasonably skilled. I left a soul-crushing Fortune 100 company for a consulting company a year ago and I've found that in one engagement after another I can quickly get up to speed and be productive. I write decent, unit-tested code that works, and it usually takes less time than I expect.
But, to put it bluntly, more often than not I find myself working on crap. Either the code rotted years ago and no one wants to improve it, or it's in an early state of decay. Our Scrum is flaccid. I can still do some good work and occasionally enjoy it, but most days I sense a huge gap between what I do and what I can do. (I don't think I'm Dunning-Kruger delusional. But who does?)
Sometimes I spend more time reading and practicing, but after a while I realize that I've become two developers: the one who works forty hours a week and the one whose hobby is practicing for nothing. I enjoy it, but not quite enough to do it just for the sake of doing it.
Are high-velocity agile teams who write great code nonexistent like unicorns or the real man Esquire tells me I'm supposed to be, or just needles in a haystack? Is there a different city I should move to?
Social Media Envy, But for Careers
Let's get this out of the way up front.
Social media envy is the phenomenon where everyone puts a rosy spin on their lives for public consumption. You see pictures of them at the Leaning Tower of Pisa or doing WTF-ever "hot yoga" is on a beach somewhere with 12 hard-bodied BFFs.
And then you look at the Cheetos crumbs on your shirt and on the couch from your day of binge-watching Married with Children reruns, and you wonder where you went so wrong.
This is the classic parallel to the discussion here, I suppose.
But I actually prefer a different one. One that's more career-focused, and right in my lane as a business owner.
Go listen to entrepreneurial podcasts. And you hear endless success stories.
"Oh, yeah, here's how I grew my T-shirt side hustle into an 8 figure business in 6 weeks." They're cool to listen to, but it tends to be some of the most intentional survivorship bias imaginable, coupled with the same "best foot forward" attitude you see on social media.
As a business owner, this creates a sense that I'm constantly doing something badly wrong.
Why did I just work a 90 hour week and we're somehow on track for less revenue than last month? That doesn't happen in the podcast, so there must be something deeply wrong with me.
All of this is to say that these good teams writing this good software probably have skeletons that you don't perceive. You are seeing, to some extent, unicorns and lantern jawed Esquire models.
On a Long Enough Timeline, All Codebases Suck
Let's move out of my dime store psychology hot-take, though, and into talk about codebases and teams. First, codebases.
Codebases usually start off as beautiful things. Hence the allure of the green field project.
No need to contend with legacy dependencies, mountains of technical debt, old code written by people that have since quit, or production constraints. You can just start building, using the latest and greatest patterns, techniques, and frameworks.
But no matter what, and no matter how good the team, the codebase eventually slides down toward a state that sucks. Depending on myriad factors, that slide can be a slow one down a very gentle slope, or it can be an amusement park death-slide coated in Crisco.
But the grade exists and it's only a question of steepness.
If you build and add features, you will contend with non-linear complexity, which will eventually make it harder to work with the code. Even with the best test suite imaginable this will happen because scale always degrades things.
The test suite itself may become cumbersome or brittle.
Likewise, say you leave the code alone. No changes no tech debt, right?
Well, sure, until you wake up one day, need to change it, and realize that it's a Winforms app build in 2004. You can barely remember this codebase, and why is all of the logic in the GUI's code-behind?
What's the point?
The point is that the example code people blog about comes from toy codebases and fields of green. And there aren't a whole lot of jobs out there that deal only with such things.
Maybe if you worked as a developer evangelist, building exemplars.
And, on a Long Timeline, Familiarity Can Breed Contempt
Now this accretion problem of code quality doesn't mean that you have a bad team. It doesn't even mean that you have a bad codebase.
It's just kind of an incontrovertible law of code entropy that comes with time and scale.
Likewise, there's kind of an incontrovertible law of familiarity breeding contempt. Or, if not that dire, familiarity at least breeds, well, familiarity.
If you go work somewhere with people you admire and think are awesome, you'll have kind of an initial honeymoon feeling.
But as you're there, those people will become human to you, and you'll learn important, helpful lessons from them.
The star appeal wanes and they become your coworkers. You've learned from them and, perhaps them from you, and any remaining differences of opinion become long-standing points of contention or "agree-to-disagreement," depending on your relationship.
And all of this is happening while you and these people collaborate on a codebase that is undergoing entropy and slowly, naturally aging and rotting.
Again, none of this is horrible or necessarily unexpected. But it's also not straight out of a stock company recruitment video where people high five each other over a TDD-in-the-latest-javascript framework, revolutionary breakthrough.
All codebases rot. All teams start to look less impressive the more you're part of them.
So, Find People that Care about and Value the Same Things As You
Now all of this sounds pretty depressing, but it's really a matter of expectations management. Your side hustle/toy projects will always be more appealing than your day job ones.
The day job ones die by a thousand papercuts while you can keep the side hustle ones nice and pure, finding sanity and happiness in them.
But remember, not all day jobs are created equal, either. You can find ones where the facepalm moments are few and far between, the opportunities for good code abound, and you share common beliefs and camaraderie with your teammates.
That does exist.
The main challenge is that there's no perfect outfit for finding such a thing. And what should serve in that capacity -- the job interview -- is oriented toward tricking you into thinking that the company's developers are much better at life than they actually are.
(The same way your role is to trick them into thinking that you're much better at life than you actually are. In case it's not clear, I don't think much of job interviews.)
So you need to remain vigilant for good places, and you need to flex your network muscle. Ask developers you know a lot of questions over time about where they work, what it's like, what they like, and what they don't.
Keep your antennae up for shops that value the same things that you value, and where people care.
You're never going to find a place that ushers you into the Elysian green fields of coding, to sling angle brackets eternally in paradise. But you can find a place where people care and where they might even occasionally do something worth blogging about.
If you'd like to ask a reader question, you can do so at the "ask me" page.
Top comments (5)
Such great article 👏🏽, Erik.
You know what? I used to believe that I could find awesome code, creme de la creme code in OSS projects. Until one day I read an article explaining a topic for Ruby on Rails apps and the author pointed out a "bad example" in the GitLab codebase.
In disbelieve, I went to the GitLab repo to find 😆the file and the lines. They were real. Worst of all, there were many more, in all the place!
In that moment I really thought about all those posts saying "don't do this or that because it's all wrong" and then seeing those very examples in the source code of such company, well, it taught me bad code is everywhere and we should live with that.
I think if we look closely to DEV sources we would find so called "bad code"
Thanks for the kind words!
And yeah, bad code is everywhere. Some of it is because we all have a natural impulse to categorize "I didn't write it and don't immediately understand it" as bad. But I used to audit codebases for a living, and it really just stems from the fact that we're all fallible humans, making decisions in the moment with imperfect information. All codebases rot and have weird stuff in them.
One thing I find helpful is to write out every possible thing I could have an issue with in a code review and then pick the most important comments and drop the rest. You start realizing what is actually bad and what is just a different style.
That is such a GREAT strategy.
Years ago, I used to write more on my blog about how to conduct code reviews without demoralizing people. If memory serves, I once wrote a satirical post called something like "How to Use a Code Review to Execute Someone's Soul." IIRC, that popped on Reddit/Hacker News.
Anyway, for a decade, my message regarding code reviews has always been what you're saying here. "You're going to find dozens, or even hundreds, of things that you'd do differently. Jot them all down, prioritize them, and then share 5, max. Anymore than that, and you just demoralize people. Leave the rest in the codebase -- we can fix code later, but we can't fix demoralized teammates later."
Yes, there are companies that write good code. But the scarcity of such companies is to the point that they are very rare. Besides that, companies who do write good code don't need the blogging attention either. They focus on the code. So you probably will never hear from them.
I am familiar with just one exception: Spatie (Belgian Laravel/PHP expertise shop). They talk the talk (often on conferences) and also walk the walk. Their code is high standard and is applied in many industries all over the world.
Like Erik also says: too many critical comments will demoralize the team member(s). So having a very strict convention culture just kills morale, unless you make it also fun and lighter. Gamify the process of code reviews, debugging, blaming etc. This way the result can still be very strict, but the atmosphere around it can be human and with dignity.
I wouldn't say senior developers don't make mistakes, but far less than junior and medior developers. On the other hand, junior and medior developers can be mold into better senior developers over time. Until they jump ship and go somewhere else and this cycle restarts.
So yeah, multiple factors are responsible for code quality. And they are highly dynamic. That's also why it's more important to learn a lot about principles and best practices in general vs. all ins and outs of a language. This minimizes the negative risk of keeping and creating bad code much more than understanding just code conventions.
Every five years the amount of developers needed (!!!) doubles. The amount of developers joining the forces are far less. And the broad spectrum of acumen amongst these joining developers is even more dim. And they all start with "monkey sees, monkey does". Provided they get very bad examples in a lot of areas, this problem continues and "broken windows" keep appearing every where.
In all the code bases I've worked with, they were all in very, very bad shape and sometimes still sold as an "Ferrari engine".
Not everyone has read the books by Juval Lowy, Robert Martin, Martin Fowler or the Sussmans etc. and that is something we all should cope with.