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.

> Your good developers are often the ones who like to tinker with frameworks, patterns and complexity.

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.

> Boring code can be a hindrance to onboarding new features.

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.

There is certainly a place for novelty, particularly in a green-field development, but the tech stack is a tool in service of the developer/business, and should never be seen as the end goal or product.

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!

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.

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.

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.

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

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.

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?

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.

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.

Very much in agreement that the best developers love experimentation and tinkering. I think about this kind of balancing act quite a bit and I personally like very small teams of folks who are not afraid of a lot of spice as long as the tools either have decent community or are not impossible to hack.

In my experience that depends.

But the tinkering kind is often satisfied when they are able to tinker on their own code. Even (or especially!) if they're allowed to do it during working hours. But allowing engineers to literally hone their craft on the clock is something that is becoming rarer and rarer, unfortunately.

But I agree that a developer that refuses to admit failure of their experiments and wants to force their experiments on others is a problem, of course.

On the other hand, there's more to this job than coding, and a lot of people interested in "learning" will leave as soon as they find out there's nothing more about the problem-domain to learn.

It's not the 1970s where you can't afford a computer at home.

Programmers tend to be interested in cool new paradigms, tools, libraries, etc...

Software engineers tend to be interested in delivering robust and correct features. Consequently they are more conservative.

When companies hire, they should be clear what sort of developer they want. Programmer in a software engineering role will damage the code base and eventually leave in frustration.

If you push your own amusement as a priority at work, at the expense of the goal of the company, you literally make the working environment dysfunctional.

None of these simplified models reflect the real world. No employee is fully bought into the company's goals. Odds are you don't actually have enough money to beat all other offers. And the cost of turning employees into interchangeable cogs is that you need a lot more of them than if you're willing to let them be individuals.

The result is that while the company has its own goals, those goals are best served by making sure that the employees are at least happy enough that turnover is kept low. And a big part of keeping creatives happy (not just in software) is letting them try new things and experiment.

(This is aside from the tangible benefits that your organization gets from allowing people to be creative, which I think is not negligible.)

Codebases become boring because bad tools require a lot of repetition and meaningless boilerplate (which also encourages mistakes). Experience with bad tools is much less valuable because they can’t amplify my time and effort. If a job did not allow me to maintain valuable and marketable skills, they would have to compensate me a lot for creating a résumé gap and making future job searches harder.

Incidentally I also found this to be sort of a drawback with Google. Experience with completely proprietary platforms also has little value outside the one company where they’re available.

R&D or having a “lab” repo for developer experiments is a separate lane until it’s good enough for production. It’s a wonderful way to highlight what possibilities and capabilities are being explored.

Or, you can use the latest and risk having to constantly update it and let it take away time from experimenting.

This reminds me of Spolsky's "Smart, but doesn't get things done" anti-pattern.

Smart doesn't mean good productive team member.

Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development?

Why do people think they can "play with new technologies" at work, which is wasting not only company money, but other people's time as well? It's so incredibly unprofessional, maybe it's time for software developers to grow up and start acting like adults in the workplace?

The same reason software developer salaries are so high. Supply and demand. Companies will do back flips to attract and keep software engineering talent.

> which is wasting not only company money

Some of the best cost saving solutions I've come up with in my career have been thanks to "playing" with new technology. It's the opposite of wasting company money.

> maybe it's time for software developers to grow up and start acting like adults in the workplace

There is nothing childish about loving your work, having fun while doing it, and bringing that attitude to work. It's infectious and great for company morale. Maybe it's time for the negative nancies to grow up, seek therapy, and start acting positive at work and having some fun.

Expecting to love your work and have fun doing it, is incredibly naive, yes.

> bringing that attitude to work. It's infectious and great for company morale.

Exactly the opposite, relationships become incredibly strained with the rest of the company and there is a lot of frustration when dealing with the software department. Developers are disliked in the company because they are selfish unprofessional time wasters.

The users are just dumbfounded when they present their 8 month rewrite of perfectly working system, in trendy react framework, now with only 80% of the features and in a slower web page. It's really embarrassing.

Then I guess I've been naive for over three decades. And getting paid great for it too. I suppose I'll never learn this important lesson considering I'm close to retirement.

> Exactly the opposite, relationships become incredibly strained with the rest of the company and there is a lot of frustration when dealing with the software department. Developers are disliked in the company because they are selfish unprofessional time wasters.

I could imagine that happening with you. There are always a few envious types in any company who think the entire company feels the same way they do. These same folks are envious that the sales people get huge bonuses for "spending all their time on the golf course". Considering I have work relationships going back decades it's safe to say there are plenty of people in most companies who aren't like you.

> The users are just dumbfounded when they present their 8 month rewrite of perfectly working system, in trendy react framework, now with only 80% of the features and in a slower web page.

Of course they would be. That doesn't sound like fun at all. That sounds like a project that didn't take user requirements into consideration. Fun and poor requirements definition sometimes come together, but you are confusing correlation with causation. Loads of overly serious software engineers get the requirements wrong too.

I hope things get better for you and you learn to have fun while still being highly professional. It's a great club to belong to.

>Why do people think they can "play with new technologies" at work

Because software dev is a step above code monkeying and people value being able to grow. Which requires experimentation.

It's unprofessional when there are higher priorities or you can't make a potential business case.

Two reasons. 1) Because devs generally have other employment options. 2) Management has no idea how to judge what devs do.

1 is important, because devs can often go work somewhere that lets them work on fun technologies. This is usually at a smaller company and often comes with lower pay, but not so low that anyone would consider it suffering (still easily into the 6 figures).

2 means that the manager only sees the following option: Tell the dev they can't play with fun tech, risk them leaving, and spend many thousands of dollars on recruiting a replacement (who may also leave). OR Tell the dev they can play with the fun tech, and nothing immediately breaks (and the manager can go back to worrying about their day to day problems).

Taking the second option is not necessarily an irrational choice for the manager. Especially if that manager is using an "up or out" strategy (their plan is to be promoted or leave before the long term effects of these decisions can bite them).

Such is the realpolitik of the business world.

Because that is where new ideas, new approaches, innovation and knowledge creation happen? In software, like many other knowledge-work professions, you can't just put in a few years at university and then stay on top of your game by simply showing up every day for 40 years. The daily challenges are too diverse and change too quickly. Continuing education is a significant part of staying in the game, mixed with daily application of this knowledge.

Think about it this way - if you're a high-value developer, you've already put in thousands of hours of R&D and practiced with numerous technologies. Much of it on your own time, much on a previous employer's time. This knowledge is the basis of your current skillset. It's why companies pay you a salary. It's how you adapt to novel challenges in daily work for which you, by definition, require a larger body of knowledge to draw from. You know best how to build that body of knowledge.

Some companies are apparently more than willing to reap the benefits of R&D that was done on someone else's watch. But when it comes time to allow R&D on their time, suddenly it's "wasted" and derided as "play". The only thing that's wasted here is the developer's talent. When the "adults in the workplace" behave like this, making arbitrary engineering decisions about what is legitimate work vs play time - despite lacking the engineering context or credentials to make such a bold determination - that reeks of unprofessional behavior.

It would be like me micromanaging a lawyer's document list in preparation for their case. Or me telling a doctor which medical journals they should/should not be keeping up with. I'm not qualified! So I shut up and let them work, and put my trust in their deep knowledge and hard-gained experience. That's professional.

Humans in general demand fun at work whenever they have the leverage to do so. That so many don't have fun is not an example to be emulated, it's a problem to be solved. People are more effective when they enjoy what they do. And software is far from the only profession where people are able to pick jobs because they enjoy them.

A few examples from my own immediate experience:

* In the last year our company hired a full-time designer whose express reason for switching jobs was that our project was more fun.

* My dad is a producer for a radio show. He got that job by twice switching away from jobs that he'd stopped enjoying and he now loves what he does.

* My brother-in-law went into law because he knew he'd enjoy it, and he has a blast every day. He's always telling a story about some crazy new legal edge case he ran into at work.

* My wife is a musician and music teacher and absolutely loves it. You should see her when she has her instrument out.

Instead of trying to rob the fun from the creative professions, we should be trying to find ways to help more people be able to enjoy their work. Even aside from the obvious humanitarian benefits, this would have a huge improvement on our economic output compared to the status quo where so many people are basically cogs in a machine.

This has been a thing for as long as humans have been working. It's because through experimentation you may discover something that increases productivity.

The guy who strapped a combustion engine to a field plow was probably playing with new technologies at work. And it no doubt cost a lot of money. But now the world is better off because of it.

Yeah, engines are more complex than horses. But productivity skyrocketed. These trade-offs are made every single day, every single year for as long as we've existed.

Everyone wants a job that they love, and that requires having fun at work. People leave jobs, any kind of jobs, because they're bored and not having fun.

I had a heated argument with a colleague who was fighting to use MongoDB for a new project, even though there was a company wide decision by upper management to NOT use MongoDB in the company. And his only justification was that "he took this job to play around with new technology". If I hade the power to, I would have fired him on the spot, because clearly he had misunderstood the very basics of the employment contract he had signed.

Two things:

1. Both my parents work in law, and both have changed jobs, taken in on new challenges, or focused in a specific area because they were interested in it and wanted to have "fun" at work. Eminent doctors will also frequently filter their patients to focus on cases they deem interesting.

2. You are saying that companies actively support non-optimal solutions just so that software engineers can have fun. It's not the case at all. Maybe bad engineers pushed bad technical choices because they wanted to have fun, and the company went along with it because the bosses didn't know better, but that's driven by the bad engineer, not by the company.

I’ve cultivated the ability to become excited about picking apart grody system failures. That never gets old, and unlike adding a hot new framework to the stack, the cumulative effect is always to make things work better.