Are There Actually Companies Out There That Write Good Code?

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? The reader says:

"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.