Hacker News Reader

Comment by rdoherty | Hacker News Reader

A few mantras I try to use for this type of problem:

* There are no solutions, just tradeoffs. Don't think there's a perfect tech stack.

* Done is better than perfect. Velocity matters. This generally means pick something you know if delivery is important.

* Boring tech tends to be reliable. Things like PHP, Rails, Django, etc. These tools have been around a long time and ironed out the kinks. Lots of documentation and tooling to make your life easier. Odds are very low your new fancy idea has any requirements that boring tech can't deliver on. This counts for every layer of the stack (frontend, DB, OS, etc).

I think the most important thing to keep in mind is you'll never have a perfect solution and that's ok! Don't get fooled by all the hype from new technologies that try to make you feel inferior for using other tech.

View on HN

I've noticed that managers tend to over-emphasize the benefits of boring (solved problems, consistency, easy to hire for), and devs tend to over-emphasize the downsides (verbosity, cruft, harder to attract top tier talent, harder to keep top tier talent). Few people recognize the need to strike a balance.

The word you're looking for is: exaggerate

Some devs want to try the latest and greatest as resume fodder or out of boredom.

Well, sure. I mean, a valid reason to not use boring technologies is because you're bored with them. Devs need to grow and be challenged, or you're going to lose them. That's where management makes its error; they'll pick technologies based on what is popular ('easy to hire for'), or currently in use, or they used in a former life, and miss that none of those equate to good problem domain fit, dev engagement/challenge/growth, ability to attract talent (i.e., jobs offering Java vs Kotlin vs Scala vs Clojure, will attract different types of people, despite all being JVM languages), etc

Where devs make their error is, if they're junior, likely missing the technical tradeoffs (yes, other tech may be better for X, but it's also worse for Y), and if they're senior, likely missing the organizational ones (i.e., do other teams want to learn it, does devops/QA/etc have to do anything, what's the ramp up time, will the proposed productivity gains offset that, etc)

I think there is value in looking for boring solutions, but I think that's really a secondary type of problem ("how do we do this well?") versus the primary type of problem ("what are we trying to do?").

There are some types of tools (such as React, Rust, or Kubernetes) that are new and fancy, and which may often be unneeded vs a boring tech, but are also actually solving a different problem than their competition might be. Using Rust is genuinely not the same category of work as using C++, for example, and writing React is very different than writing JQuery. That doesn't mean Rust or React is always the right solution, but it's worth considering if a "fancy" tool actually does help you work on the problem you are actually interested in.

Of course, tech that actually makes a big step like that is pretty rare and still has costs. There will almost always be some costs to go with benefits. But matching your solution to your problem well can go a long, long way.

React is the boring tech now.

jQuery is boring. React only a short while ago introduced hooks.

That's when it became boring.

Depends on which part of the world. haha. May be in SF React is boring, but in certain parts of the world, it's still the hottest thing.

Wondering what would be the hottest frontend framework if React is boring?

Rooting for Svelte

To reiterate the point of my comment above: how big is the difference when using Svelte, really? Is it simpler nicer, or does it let you model the problem more closely?

I don’t have enough experience with it to say (though I do like to see it leveraging compiler tech to optimize rendering flows), but I think that is the question to ask. If it’s basically the same model as React, we really don’t lose much by using React, even if Svelte is nicer. If it’s a new model, it may be worth fighting.

The boring tech part is especially worth considering what environment you're really working in: if you need to interact with things like enterprise SSO systems or web services, meet regulatory requirements, etc. there can be a lot to be said for being able to install something like a SAML authentication, obscure database or file format library without having to write or significantly contribute to one if that's not your core business goal.

I suppose that could be an argument for microservices; use 'boring' tech in the places that necessitate it.

Yes – although even “microservice” might be slightly skewing that. I generally like to refer to it as “easily replaced” — i.e. if you have a monolith but it's well organized without broad cross-dependencies, you can swap things out pretty quickly without otherwise changing your deployment model. Maybe that's getting somewhere on the microservice spectrum, maybe not but the key part is really just that you have a well-understood contract for what a component provides and what it depends on.

What I like about boring tech is, that in my experience it results in that these kind of decisions just becoming less important. It makes it harder to shoot yourself in the foot with when trying to predict the future.

Especially in early stages of a company, where I don't yet know what the product that sticks will look like, I'd rather have a Postgres that I can pivot on in pretty much any direction and I'm hardly ever the first one to run into a problem, than a hyper specialized novel database that might have been strictly speaking the famous "better tool for the job" when I started.

> There are no solutions, just tradeoffs. Don't think there's a perfect tech stack

I completely agree with your point, but the absence of a "perfect" solution doesn't mean there isn't a global maximum. I think people already understand that too -- how many "what's the best X?" searches do you think people perform compared to "what's the perfect X?"?

I assumed OP meant that the answer to "what's the best X?" for any nontrivial X, is "it depends"!

It is an assertion that there isn't a unique global maximum for all needs, as slight variations in how important each part of the tradoff is for you will determine whether A or B is better; and the only reasonable answer to "what's the best X" is "it depends".

However, I would also assert that for many somewhat mature technologies the value of determining the global maximum for your particular needs does not outweigh the effort required to do determine what it is - in general, a reasonable local maximum will be almost as good as the global maximum; you want satisficing instead of optimizing.

I generally prefer boring, mature technologies or things I already know over resume-driven development as well. One potential gotcha though — today’s uncool thing that you know might be tomorrow’s thing that no one else knows

The last project I worked on still used JSF for the UI, because they guy who created the core of it knew and loved JSF. Then he retired a couple years back, and it’s been a real struggle to find anyone able and willing to do JSF development.

From a product managers perspective - very wise words! Not many engineers get this (or they do but would still rather work on bleeding edge tech for $/CV kudos).

It's hard for an engineer to focus on getting the job done when employers require knowledge of a certain fad tech stack. For all the hate the "whiteboard interview" gets, it's far better than the alternative which is how familiar you are with the interviewer's tech stack so you code up example projects in a race against the clock.

> There are no solutions, just tradeoffs. Don't think there's a perfect tech stack.

Wow I really love this perspective.

Reply on news.ycombinator.com