6 ms·
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
by rdoherty 6y ago
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.
- monkeydust 6y agoFrom 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).
- sukilot 6y agoIt'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.
- acdha 6y agoThe 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.
- Tarq0n 6y agoI suppose that could be an argument for microservices; use 'boring' tech in the places that necessitate it.
- acdha 6y agoYes – 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.
- hellofunk 6y ago> There are no solutions, just tradeoffs. Don't think there's a perfect tech stack. Wow I really love this perspective.
- ytdytvhxgydvhh 6y agoI 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.
- simondw 6y ago> 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?"?
- jcheng 6y agoI assumed OP meant that the answer to "what's the best X?" for any nontrivial X, is "it depends"!
- PeterisP 6y agoIt 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.
- smoe 6y agoWhat 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.
- lostcolony 6y agoI'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.
- kbrannigan 6y agoThe word you're looking for is: exaggerate
- peruvian 6y agoSome devs want to try the latest and greatest as resume fodder or out of boredom.
- lostcolony 6y agoWell, 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)
- wwright 6y agoI 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.
- tracerbulletx 6y agoReact is the boring tech now.
- wolco 6y agojQuery is boring. React only a short while ago introduced hooks.
- freyr 6y agoThat's when it became boring.
- murukesh_s 6y agoDepends 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?
- scns 6y agoRooting for Svelte
- stefantalpalaru 6y ago> Boring tech tends to be reliable. Things like PHP, Rails, Django, etc. Django will break backwards compatibility with every new minor version. You'll either spend a lot of time porting your code base, or stick with an old and vulnerable version.