[Philip-J-Fry]

>A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that.

That only holds true so long as the developer believes the end result is interesting and not the puzzle of software development on the journey. A lot of people are developing very boring software. It's hard to stay passionate about that sort of thing, which is why developers take it out on the code. It's especially hard to stay passionate even if you think the product is interesting but the journey is a slog. You will get burnt out.

I like programming in boring languages. I code Go for a living, and I think it's a relatively boring language. But I love Go.

>In my experience, good developers recognise that complexity is always the enemy of good code, complexity is a necessary evil. Developers enamoured of complexity or novelty are not good developers but usually beginners who think that new x must be better than older y.

Yes, complexity is evil. But it's a necessary evil like you say. At some point you have to face the music. We write the same code 3 times, we extract it to a function. We use it in 3 separate places, we extract it to a package... and so on. This applies to every step along the way from development to deploying to production. Someone is going to get fed up with repetitive tedious work and they're going to write a tool or abstraction or something to fix the issue. You can't get away from complexity but you can limit its scope.

Good developers aren't suggesting frameworks because they're newer, or refactoring because the code looks nicer, or anything like that. But a good developer is always tinkering and experimenting. If they think there's an oppurtunity to improve the developer experience at the cost of complexity, they'll try it and see what it looks like. Often nothing comes of it, but sometimes they find a nice middle ground. That's the sort of developer you want. One who is always thinking and not hacking out code just to reach a deadline.

>Not sure what you meant here, but IME boring code makes it significantly easier to onboard new developers and to develop new features - boring code meaning code that is easy to understand, does what it purports to, and has minimal layers of complexity and minimal architectural busywork.

"Good" boring code bases in my experience are flexible but tedious. You couldn't write half the software you write without someone sprinkling some of that necessary complexity into the mix. There's no room for unnecessary complexity. But if doing things in your code base is tedious, boring and eats up dev time, then there's an argument to be made that some refactoring is warranted. It'll introduce complexity, but the trade of it faster development and happier developers.

I work on a "boring" code base. I don't mind it, but I can see the duct tape holding it together. Adding new features is easy but time consuming. We said from the very start that we will not write complex code. And we stuck to that and we saw the benefits of conciously deciding that. Development velocity initially was rapid, but now it has tapered off. Getting buy-in for refactoring is a huge effort because everyone argues "complexity is evil", but I'm seeing my velocity drop off a cliff. What was once fun because it was simple, is now boring and tedious because it's too simple. We sidelined some basic patterns and complexity for that boring-ness. That's why there's a fine balance between what is simple vs complex.

How do you solve that issue? Do you stand by your guns and say "Yeah it's a slog and you're bored, but it is how it is"? Or do you work with the developers that are working on this code base 8 hours and day and reach a middleground at the cost of your ideal "simple is better" approach?

[hbrn]

> If they think there's an oppurtunity to improve the developer experience at the cost of complexity, they'll try it and see what it looks like

IME this fails most of the time. Perception of complexity varies across the team. A proactive developer pushing for a new shiny thing is unable to properly recognize complexity of his solution because he is the most familiar with his solution. Familiarity changes perception of complexity.

A lot of developers have a catastrophic combination of being non-confrontational and having impostor syndrome, so when then new shiny thing gets enforced upon them they are unable to push back. They don't like it, but they think it's their fault, so they keep silent.

> "Good" boring code bases in my experience are flexible but tedious

It is true, but I taught myself to love that tediousness and I absolutely love it. I treat it as enlightenment. I write way less code, but ship way more value.

It's really sad that most engineers are excited by solving their own problems, not by solving customer problems. Talk about misaligned incentives.

We even rank companies based on how much fun they allow us to have, not by how much impact they are allowing us to have. I've heard numerous stories about folks at Google not being able to ship to production for months, but still praising their tech stack. To me that's just insane.

> Getting buy-in for refactoring is a huge effort because everyone argues "complexity is evil"

That's strange. In my world most of the refactorings are aimed to reduce complexity, not increase it.

[flippinburgers]

Until you have had to work with complexity guzzling junior developers who cannot help but chase the new sparkle, consider yourself lucky to be working on a stable codebase that is readable. It sounds to me like the team has turned down some of your ideas that you feel would make the codebase "better".

[grey-area]

> But a good developer is always tinkering and experimenting.

I strongly disagree. Developers build stuff, that's the job, not tinkering. Sure, everyone loves to tinker (most people love it far too much), and sometimes that is productive in the end, but it's the sort of thing you do in your spare time or quiet moments, not something you should see as central to the job - central to the job is turning ideas into reality, delivering.

> But if doing things in your code base is tedious, boring and eats up dev time

This is not what people mean by 'boring' software, they mean software they don't have to think about much, and when they do think about they understand instantly. Boring in a good way - as simple as it can be, hiding complexity with the right abstractions.

I'm afraid I don't know the sort of code-base you're talking about, but if velocity slows down, it's a sign of problems. If you're talking about a boring mess, you're probably talking about a code base I would call interesting (in a bad way). Boring is not a mess, boring is stuff that just works, with few hidden gotchas and abstractions and a simple call tree.