>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?