Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

181–190 of 374 posts

Re: Choose Boring Technology (2015)

#181

Earlier quoted context omitted.

And what about the front end? What's the best, most boring choice there? I was on a project for a bit using React and although it felt like an obvious way to write things, I can't help but feel you can't create something that will last for a decade with it.

You absolutely can. React is the gold standard right now. It's already been king for 6 years and it's not going anywhere. The hype for angular died down. The hype for vue has started to die down. This little bit of hype svelte has at the moment will die down. React does have a ton of problems but they all come from the next level of dependencies down. Shit like Gatsby and Nextjs won't pass the test of time. Neither w…

My instinct is to build a native front end and connect to the back end over a REST (or similar) API. To me, that feels like the boring technology route.

Re: Choose Boring Technology (2015)

#182
post #68

Earlier quoted context omitted.

I think it's helpful if it brings awareness to the situation. I've spoken with 70+ different devs working on 70+ different projects of all sizes on my Running in Production podcast[0] and the choose boring tech phrase came up a whole bunch of times, and especially the idea of using innovation tokens. If it helps folks build and ship their app in a quick and stable way, that seems like a big win to me. [0]: https://ru…

It must have been a weird coincidence but I listened to a few episodes for your podcast and I've actually heard about boring technology in 100% of episodes I listened to

Hah yeah, coincidence for sure. I don't have hard numbers in front of me but based on reference links to the boring tech site it's been mentioned at least half a dozen times. I know innovation tokens have been spoken about a few times outside of those linked episodes too.

Re: Choose Boring Technology (2015)

#183

Earlier quoted context omitted.

and Java?

The Java community has some great developers, but also a lot of Serious Software Engineers who will sabotage everything with extra complexity, and then everyone who learned Java in school and never felt like looking at another language (not even Kotlin). Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.

Yup - it's possible to build uncomplicated software in Java, especially in recent iterations of Java and more... restrained modern frameworks. However, there's no guarantee that you're actually going to either join a team or hire a Java expert with those tastes.

Re: Choose Boring Technology (2015)

#184
post #151

Earlier quoted context omitted.

How much experience do you have working with JS?

I have been writing it full time about 13 years. I love writing in this language, and TypeScript even more. I am just frustrated by what appears to be some combination of insecurity, false expertise, and a vehement lack of passion in the work force. If I want to be happy I should move on to a different technology stack, but I really enjoy making products in this language.

It's funny, I have about 13 years experience, have been senior in both enterprise, start-ups and everything in-between, and have basically the exact same view about front end dev as your original post.

Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff.

IME all the same people that overengineer everything with god awful dependencies are the same ones pushing super hard for typescript on every project I'm on. When they get their way (as always, since everything is decided democratically and everyone is dragged down to the level of the worst dev on the team), they write the worst typescript ever. On my last project, one of the people championing typescript defined some constant strings containing css breakpoints as the type 'string | int'. Rather than getting knocked back as one of the dumbest lines of code in the history of front-end, this somehow generated 3 pages of discussion in code review then got left in. I'd give the person a pass, assuming they'd never used a typed language before, except (a) they were senior and (b) they're the one that wanted types. These "seniors" lack even the most basic understanding of the shit they're using, but feel the need to impose their opinions about libraries, tooling and languages constantly.

I don't feel like I'd mind using TS at all on my personal projects, but on work projects with average devs it just adds another entire layer of complexity that they spend hours and days and weeks and months wrangling with instead of writing any code that might be remotely useful, by say, maybe implementing a business requirement, or doing anything that makes the company money instead of pissing away millions in salaries playing npm lego.

Plus, although I'm not familiar with any of it since I'm never the one pushing for TS, and so never the one setting it up, I've seen people spend absolutely ludicrous amounts of time tinkering with webpack and fussing over TS integration with 3rd party libraries and whatnot.

I'm surprised you haven't run into more of these people that just seem to use TS as a complexity multiplier for every bad engineering decision they make. Like spending 6 months setting up Gatsby or Next isn't costly enough for them, so they decide to tack on 3 months of TS integration and 'upskilling' for 3000 combo points, when they already (more or less, usually less) know how to write Javascript.

Re: Choose Boring Technology (2015)

#185
Two observations:

- The slide with the jeep together with the "use boring technologies" slogan paints an interesting picture of the challenges of E-mobility in this century. There are going to be a lot of things no one expected.

- How would you call this style of presentations? Zen-like? One catchy thing per slide? I find it pretty well done, and when I compare it to my own "wall of text" slides, I am a bit jealous.

Re: Choose Boring Technology (2015)

#186
Lots of people here are shitting on mongodb(maybe rightly so). But I think the biggest problem is that the developers making the decision on what kind of DB to use just do not understand these tools. I always recommend reading Designing Data Intensive Applications as soon as you have an inkling that you will be asked to make such decisions in the near future.

Re: Choose Boring Technology (2015)

#187
post #64

Earlier quoted context omitted.

> How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it? I think there is a tension between this kind of actively guiding anti-complexity management and hiring "top talent". The very best developers are capable, and avoid complexity. The next best…

Also it is almost never for "funsies," it is instead usually the "wrong solution" to a very real problem. The current system has bad performance, or doesn't support some new use case that is a major company initiative or whatever. But instead of fixing/augmenting the existing system the (probably multiple accumulated pain points by now) are used to justify an overly complex change. In fact the change probably becomes…

Yeah the key thing here is it's just so easy to spin anything as the solution to some problem the company has, and there's always problems around.

"for funsies" probably isn't that far off. Because the process is more like someone gets interested in something at some point. Then at that point +~1-6 months someone raises a problem and some senior dev gets stuck on the idea that the awesome thing they read about can solve it. Then before you know it whatever tool they want to use has more bells and whistles than the average mars lander and does everything short of curing cancer.

There's rarely any good correlation between the problem and the solution. That gap can just be bridged by buzzwords. The true correlation is usually between the solution and whatever the most senior dev on the team thinks is shiniest at the moment.

Re: Choose Boring Technology (2015)

#189

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

In the case of a lot of tech companies, the entire market is broken and leads to weird incentives rarely seen in any other industry: companies that aren’t profitable, don’t have a real product people pay for, don’t have a clear, plausible path to profitability and yet somehow stay in business because investors are happy to burn money. This completely reverses the typical market dynamics. The company is more focused o…

Damn, spot on.

Re: Choose Boring Technology (2015)

#190
I think what people sometimes fail to realize is that the software ecosystem has simply become more specialized. There is now a higher-bar due to the competition between entrenched technology companies with armies of engineers continuously optimizing everything. So, depending on the industry/domain - aside from a useful product you need to consider a lot more: apps that work across platforms, performance, security, compliance, SEO/marketing, analytics, speed of iteration/delivery, infrastructure reliability, etc. All these contribute requirements that add complication.

So if you want a company that can do all that you are going to need specialists which typically come wielding specialized technologies. You can probably get away with generalists wielding 'boring' technologies for some period of time combined with SaaS solutions but it's hard to avoid the fast-moving increasingly specialized ecosystem forever.

Post reply on HN