I agree 100% with your first comment. The best developers care about the impact their work has above all else. Sure, they might prefer Ruby, or Golang, or whatever, but at the end of the day the results are what they are after.

However, somehow we’ve created a world where the tools and techniques matter more than the output. I have no idea why this is, but I see it every day where engineers want to refactor code and try every new trick or tool they can.

Keeping track of what is going on is generally good. Trying to apply every hot new thing to a production codebase is a recipe for disaster!

It's also wrong to say that tools don't matter. If you say try to shove async and multiprocessing python into a system because python is boring and tools don't matter you are going to get absolutely fucked in terms of maintainability. Maybe you can afford that (and many startups can) but there's going to be a lot of survivorship bias that is sourced from non-technical things like "founder had connections" that are not reproducible across to another startup

This.

In my experience, people that insist in never adding new things can only afford to do that because they push all of the flashy problems their "boring" options create onto somebody else. And that somebody else tends to be severely underrated because they lose all their time fixing the crazy problems that come from ignoring tool selection.

But also, people that insist on novelty all the time usually can only afford to to that because they abandon their code as soon as the complexity of joining all new pieces together starts to appear. Usually leaving it for somebody else to deal with.

As a rule, developers that always choose X, for almost any X create many more problems than they solve. But they do make great strawmen to fight against in HN comments. As soon as you see people equating them to the technique, you can know the comment is worthless.

I think it’s a combination of 4 things:

1. Everyone is trying to make a name for themselves,

2. everyone is trying to maximize their income,

3. most people want to focus on practicing the mechanics of their profession rather than exercise real understanding, and

4. Most people don’t understand the global problem space they’re in

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

This. I don't want to work with niche languages anymore, and artisanal, hand-crafted in-house libraries/frameworks.

I want to use boring shit like the JVM or the CLR (.NET) and the libraries with the most answers on Stackoverflow so that things "Just work", issues are debuggable, the authoring experience in my IDE is solid, and I can use what little braincells I have to focus on building features + solving problems.

Niche languages and wacky libraries are for my weekend projects + personal fun-time.

I agree, but would use Rust instead of Java. Imo Java is a horrendous language that’s basically legacy at this point.

JVM is very different than Java. Many Java devs use another JVM language such as scala, etc.

Rust is the future but not mainstream and still early. Can’t wait.

To be fair, they didn't say Java, they said JVM. That allows Kotlin, Scala, whatever.

Java is missing so much and has so many design errors (which are acknowledged as errors), I agree that it should be avoided.

I think Rust is a better language, but you can't exactly incrementally convert your Java codebase into Rust very easily. If you stay in the JVM, things like that are much easier.

Care to explain why? I get that there are some horrible Java projects and libraries that have really ballooned in complexity over the years but I still see Java itself as one of the better languages. Especially for corporate work.

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

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

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

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