[Philip-J-Fry]

There's never a simple answer to this.

Here's some of the things we encounter:

* A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them.

* Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases.

* Complex code can be a hindrance to onboarding new developers. Boring code can be a hindrance to onboarding new features.

* You often end up in a situation where you're reinventing the wheel and you're spending increasing amounts of development time on keeping the wheel round. At some point you've got to consider a ready-made solution to your problem or consider hiring more people to deal with it.

* Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high.

Creating a company off the back of a flavour-of-the-month tech stack isn't a good idea. But I can't see how any large software company can scale without having a bit of spice somewhere.

[grey-area]

> A bored developer is an unhappy developer

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.

[malyk]

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!

[throwawaymaths]

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

[marcosdumay]

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.

[vegetablepotpie]

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

[gavinray]

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

[baby]

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

[j45]

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.

[kaashif]

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.

[Cwizard]

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.

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

[jderiksen]

> Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high.

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.

[ratww]

> Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases.

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.

[lupire]

Why does tinkering on the clock matter? Why not just hire people for 30hrs/week if that's what they want?

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

[sorokod]

Developer can be a programmer or a software engineer ( my definitions).

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.

[thow232329]

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

Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.

[lolinder]

This is nonsense. A company that doesn't care one iota about how its employees feel about their job ends up with high turnover, which dramatically increases costs in the long run. Good companies strike a balance between the needs of the employees, the needs of customers, and the bottom line. Any company that fails to strike that balance will lose in the long term.

[thow232329]

The definition of a company and its goals and motivations, is clear, and it does not have any consideration for employee amusement. That's what the christmas party and company picnic is for, and they happen outside of working hours.

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.

[lolinder]

This philosophy only works if you live in one of three simplified universes: either your employees are fully bought in to the company's goals, or you can always pay them enough money for them to keep working for you without any intrinsic motivation, or your employees really are interchangeable cogs and retention doesn't matter.

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

[erik_seaberg]

Boring codebases should be generated, not maintained.

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.

[sorokod]

That makes no sense, it's just a question of role-candidate fit. Why would a company not care?

[j45]

If the boring code is working it’s easier from a time and reliability perspective to go play and experiment in an other repo.

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.

[lupire]

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

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

Smart doesn't mean good productive team member.

[thow232329]

> A bored developer is an unhappy developer. Unhappy developers leave.

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?

[tchaffee]

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

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.

[thow232329]

> There is nothing childish about loving your work, having fun while doing it

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.

[tchaffee]

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

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.

[throwaway5959]

There are a lot of reasons to rewrite an existing system. Maybe the existing system is built in a language that is impossible to hire for in the area you’re in. Maybe the test coverage is awful and the code makes it very difficult to write tests. Your tone is frankly pretty condescending and the only reasonable answer to when it makes sense to do a rewrite is “it depends”.

[BlargMcLarg]

Dunno where you're from, but where I'm from, it is pretty much the opposite world. You're a red flag if you don't see yourself as having fun. Yes, this includes most webdev shoves where one does the equivalent of shoveling virtual manure. (No, I don't agree with this, either).

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

[Kamq]

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

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.

[perrygeo]

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

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.

[lolinder]

> Software development is the only profession where people expect (and demand) to have fun at work.

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.

[Philip-J-Fry]

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

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.

[iLoveOncall]

You must have only ever done minimum-wage unqualified work to be saying that.

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.

[thow232329]

Do you really think they take into account in other fields, that their doctors, lawyers, finance people etc should "Have fun" and change their decisions away from what is straight forward solutions, because of that? They don't. Only in software.

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.

[listenallyall]

This isn't true. Developers like tinkering with new frameworks. Doctors like experimenting with new treatments or procedures or drugs, often very immature and untested. Lawyers will seek opportunities to flex a new legal strategy or argument in order to make a name for themselves or to impress a judge, even if it may not be the safest strategy for the client. Finance people do just about anything to avoid simple, straightforward, time-tested investment strategies.

[iLoveOncall]

> Do you really think they take into account in other fields, that their doctors, lawyers, finance people etc should "Have fun" and change their decisions away from what is straight forward solutions, because of that? They don't. Only in software.

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.

[fshbbdssbbgdd]

Humans didn’t evolve to sit at a desk all day. We can adapt to it, but some sort of feeling of adventure helps motivate. Interest in the work engages more of the brain and can make one more productive.

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.