Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

231–240 of 374 posts

Re: Choose Boring Technology (2015)

#231
post #224

Earlier quoted context omitted.

> When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort. There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services. No, I'm not kidding. This is literally what people do and…

And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql

Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.

Re: Choose Boring Technology (2015)

#232
post #97

Earlier quoted context omitted.

The language for one. There are decent choices of language for backend work. Why anyone would choose JavaScript is beyond me.

The thing is, if you have any sort of front-end that is not entirely server-side rendered, you're going to have to work in JS at least some of the time. If your back-end is also in JS, you now get the benefit of isomorphic code for things that you may want to do on both front-end and back-end. Then there is also the fact that JS is actually a pretty great language if you know how to avoid the footguns. Granted that's…

Yeah; even without frontend code, JS is surprisingly compelling. It's easy to hire for, easy to write reasonably performant IO code in, the footguns are pretty much all well documented and generally understood (rather than requiring knowledge of the deep magic to debug), library support is top notch, and as a language it supports both OO and FP, while being pretty small in scope, terse without encouraging too much code golf.

Re: Choose Boring Technology (2015)

#233

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…

How about “leaves the industry rather than have to use terrible things at dumb companies”, thus giving a survival bias that selects for shiny. I know I feel that way about a lot of stuff now.

You don't even have to go that drastic. I was also tired of the "new technology treadmill" in software development, so I just changed roles in the same industry. Did a little product management for a while then settled on project management--for those same software companies. The pay is much worse but at least I'm not spending my time re-writing working software into "non-working software, but hey, it's in Scala."

Re: Choose Boring Technology (2015)

#234

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…

I've been using React since 2014 or so.

I can't speak for Angular or Vue, but I'm 100% sold on Svelte. It cuts out all of the crap that React and Redux introduced (lifecycles, hooks, boilerplate, etc.) and boils it all down to fundamentals. You can read the entire docs in a day and fully understand how everything fits together. I dare say it, but Svelte's docs are a breath of fresh air. It's rare that I read documentation and want to keep reading it.

To me, that's what boring tech is about. It's about finding the simplest, cleanest way to do what you need to do. I hope Svelte takes the path of long-term stability over features and complexity and innovation for the sake of it. What they have right now is a solid foundation.

> convoluted bullshit like redux-saga

Wait until you meet saga's bigger brother RxJS/redux-observable. Someone on HN once mentioned JIRA was using RxJS and I realized "ah, that explains why JIRA is the slow pile of absolute shit it is." From just knowing a company is using RxJS I can already guess at the type of internal communication and politics at play in the company, as well as what their code base looks like.

Re: Choose Boring Technology (2015)

#235

Earlier quoted context omitted.

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.

The GP comment mentions the need for finding engineers with "a proven track record of delivering value", yet here we have a concern about "hiring random Java developers". Is the industry biased against great engineers who have been working with Java for the past 20 years, even if they "deliver value" (which is pretty much impossible to determine externally)?

No.

But I, personally, am biased against hiring people with only Java on their resume. Because 90% of the time what I've encountered are people who haven't examined their technology choices, questioned the status quo, tried to -improve- things.

That's not a sleight on Java, per se, but it is against anyone with only one language on their resume. It's just that if there is only one language on a resume in web dev land, it's almost always Java.

Re: Choose Boring Technology (2015)

#236
Technology is just a tool, or not ?

By a tool, i mean, we still use boring algorithms (which exist long before the tech is born to adapt it efficiently).

So, boring tech or not, it's not the point, as long as it serve your purpose.

Re: Choose Boring Technology (2015)

#237

Earlier quoted context omitted.

> A good Python dev will likely leave far more maintainable code than an average Java dev. And a GOOD Java dev will likely leave far more maintainable code than an AVERAGE Python dev.

I have yet to see this in an enterprise setting, maybe my standard for "average python dev" is too high.

I have yet to see a maintainable Java project of any reasonably large size, anywhere.

Java programs are larger than those in other mainstream languages, just by dint of the verbosity of the language (and research backs this up; studies showing errors per LOC are consistent regardless of the language).

Ergo...

Re: Choose Boring Technology (2015)

#238
post #5

The problem with the non-boring technology club is that programmers see what problem FAANG companies are solving and wanting to be on the edge on new technology too. But they don‘t have the same problems. Another problem is they want to show what they can do. If they tell in an interview they are working with rails/django and a postgresql database they fear they look incompetent using those old technologies. So they…

If you have a shitty job then it's really hard to get the experience you need for something better unless you invent problems. That's why making things way more complicated than they need to be is actually a good thing.

Re: Choose Boring Technology (2015)

#239
post #127
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…

> There aren't enough of the very best developers for a company to plan around hiring only those. I've seen no evidence that companies are even trying to hire developers who "avoid complexity". If anything, the interview processes are designed to select for engineers who bathe in complexity. There are so many interviews which consist of "How would you rewrite from scratch this thing that already exists?"

I'm doing technical interviews.

There is such a shortage of people that know the basics of programming, that selecting for such l33t skills is out of the question.

The hiring process right now is not about selecting the best, it's about selecting those that pass some low bar.

Re: Choose Boring Technology (2015)

#240
post #154
post #26

I can understand this from the perspective of a manager or company owner. "Happiness comes from shipping products" or "Choose boring technology" make a lot of sense if you are maximizing profit and don't need to work with the tech yourself. If you are an engineer and you want to try a new technology, go for it. Even if it doesn't make sense. Learn new things, don't stick with the boring tech. Maximize your own happin…

> "Choose boring technology" make a lot of sense if you are maximizing profit and don't need to work with the tech yourself. This view feels so strange to me. As an engineer, I find myself the happiest when I manage to build the simplest and the most maintainable thing for the business requirements. Extra happy, if it turns out we didn't paint ourselves into a corner when those requirements increase or change. I just…

Why do you care how successful the company you work for is?
Post reply on HN