DaedTech

Stories about Software

By

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?

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.

8 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Peter Holmdahl
5 years ago

I recognize much of what the asked question. I have worked in a team where code base was much better than my hobby project. Partly because we challenged our selves within the team to always take right path over the easy path. And partly, probably, because I was quite junior and my bestest knowledge of coding was what was used in the team. We did TDD and other cool stuff, but I can of course still recall 5 hotspots of accidental complexity and technical debt. Comparing those problems to problems of other places I’ve worked.. well I remember it as… Read more »

Erik Dietrich
5 years ago
Reply to  Peter Holmdahl

That’s a great litmus test, and it never really occurred to me. When you talk about a codebase ironically, it means that contempt has crept into the equation. And usually, that’s a bad sign — a toxic mix of fatalism and shame.

TehShrike
TehShrike
5 years ago

In my experience, on teams with good/experienced developers, the amount of skeletons/nastiness is a function of how much pressure the team feels to get code committed as quickly as possible.

Erik Dietrich
5 years ago
Reply to  TehShrike

I’m assuming you mean external delivery pressure? Or do you see a mix — external, but teams also scrambling to deliver because they want to or feel somehow like they must?

Scott Hannen
5 years ago

I find that developers who code well do so both when under pressure and when given more time. Conversely, those who write bad code (for lack of a more concise term) do so regardless of time constraints. In fact, given more time they often make it worse. They use it to cram in more instead of refactoring or writing tests. (I’ve heard, “We don’t have time to write unit tests.” Really? Give them time and see if they write unit tests.) I tried explaining this to a director with no development experience. He was stuck in the mindset that writing… Read more »

Erik Dietrich
5 years ago
Reply to  Scott Hannen

I like that. It’d be interesting to do an applied experiment that way with good practices. Literally give them more time and see what they do.

Andres G. Aragoneses
Andres G. Aragoneses
5 years ago

While I agree that all codebases rot, to a certain extent, I disagree with determining this as a lost cause, as there are many examples on the contrary: many opensource projects (e.g. the Linux kernel, the Mono project, etc.) Most successful opensource projects not only keep growing, but their contributor list keeps growing as well, and the code quality rarely decreases. IMO this is because in opensource there usually is a lot of peer-review, much much much more than in most companies where proprietary software is written. This might be because usually opensource projects survive companies (anyone can fork them,… Read more »

Aschwin Wesselius
Aschwin Wesselius
5 years ago

When I was in London for the Software Design and Development Conference (SDD Conf, London 2018), I attended one of the talks about architecture. The speaker talked about the state of the “Software Crisis” (https://en.wikipedia.org/wiki/Software_crisis), how it came about, why it still exists and what could be done to progress in the proper direction. The speaker owns a company that delivers projects on time, on budget and with zero defects. That company also provides material to teach you how to do the same. The speaker himself put together this material because he has been in the industry for a very… Read more »