Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

Post reply on HN
Print view View original

111–120 of 374 posts

Re: Choose Boring Technology (2015)

#111

Post by jacobr1 »

twic wrote: post #64
phendrenad2 wrote: post #2

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 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 known internally at the company as some silver bullet that will fix all woes further reinforcing the drive to do it.

Even the best developers get ignored if they try to justify pure-tech-debt fixes. So they learn to include fixing tech-debt as part of a fixing a problem that has some _direct_ business relevance if addressed. This gets clearly observed and taught to the all tiers of developers further obscuring the rationale for architectural changes from more senior management.

Re: Choose Boring Technology (2015)

#112

Post by gurkendoktor »

laurent92 wrote: post #48
Mikushi wrote: post #11

Earlier quoted context omitted.

> The last line of defense against a rogue engineering team is managers who have studied this stuff. If your engineering team is the one pushing in that direction I'd reckon the company was in a bad spot to begin with to have hired that team because it strongly indicates that the management layer (head of tech/CTO) has no technical clue. Hire strong Lead Developers with a proven track record of delivering value to co…

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.

Re: Choose Boring Technology (2015)

#113

Post by wffurr »

trestenhortz wrote: post #3

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies. When someone comes at your approach wielding a slogan, be ske…

Thanks for summarizing the talk so concisely.

Maybe read it before commenting next time.

I wish HN had a feature where it could detect that you clicked the link and disallowed commenting before that. At the very least you’d have to click the link, even if you just immediately click back without reading, and you’d know what you were doing was circumventing the spirit of the place.

Re: Choose Boring Technology (2015)

#114

Post by austincheney »

monsieurbanana wrote: post #92
austincheney wrote: post #76

Earlier quoted context omitted.

You are clearly not a JavaScript developer. It really feels like everybody has just given up and thrown in the towel. There are no good developers, let some giant monster framework make all your decisions, and frequently chase shiny shit. Of course this means starting over, from scratch, in small sections of the product every couple of years. > The industry constantly mints senior engineers who have been bitten by co…

I'm not used to see that amount of hate directed to fellow programmers in a hn comment.

There was no hate intended in my comment, but I can understand how you came to that conclusion. My experience posting on r/javascript of Reddit has taught me some developers are insecure, extreme conspiracy-theory paranoid insecure, about working without their favorite framework.

Re: Choose Boring Technology (2015)

#115

Post by cutler »

gurkendoktor wrote: post #112
laurent92 wrote: post #48

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.

Although still new I'm wondering whether Kotlin could be admitted to the boring technology category given that it was built to dovetail with Java and has first class Spring support?

Re: Choose Boring Technology (2015)

#116

Post by thedevelopnik »

gaogao wrote: post #102
satyrnein wrote: post #88

Earlier quoted context omitted.

It seems like you're assuming the data you need is all in one microservice. (In which case, why did you need microservices?) Let's say the report needs data from across two microservices, one is backed by mongodb and one is mysql, and both services have been crud endpoints but not ones that will give you the full data you need. This is a pretty typical scenario! So you could make new endpoints, but then you still nee…

Still a 5 second SQL query with Presto or similar and a warehouse.

But now you need to build an ETL system and run a data warehouse. And you need a team of people who know how to build and maintain those.

Re: Choose Boring Technology (2015)

#117

Post by koheripbal »

jmartrican wrote: post #91

The way I see it is that one should master their stack. If you work over and over again with the same stack you will know it well. You will be able to move mountains with it. But it takes years to arrive to that. It takes implementing multiple projects the same way over and over again. You need the wherewithal to stick with your stack and not get lured away. Maybe this is what boring means. Maybe boring is different…

This equally applies to a company's business process. Focus on a specific scalable business model that scales - don't make a special niche process for every "opportunity" that comes by.

It also applies to managing your life, personally. Know what things you do, what your personal goals are, and don't let yourself get distracted by the latest and greatest social media trends or stuff your friends are doing.

Focus. Mature. Achieve.

Re: Choose Boring Technology (2015)

#118

Post by madeofpalk »

phendrenad2 wrote: post #2

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…

This reminds me of Google’s mysterious new operating system “Fuchsia” that they’ve been developing semi-publicly, which was said to mainly be a “senior talent retention program”

Re: Choose Boring Technology (2015)

#119

Post by cutler »

ChrisMarshallNY wrote: post #60
phendrenad2 wrote: post #2

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…

I don’t do “boring,” as much as I do “mature and robust.” I like shipping products, as opposed to just “writing” them, and shipping is boring. Lots of annoying intricacies and processes. I’m writing a fairly large-scale app, right now. It’s written in Swift (frontend), using IB (classic UIKit), and PHP/MySQL/Postgres (backend). It does not use SwiftUI (shiny), or Rust (shiny, but a bit more dusty), or some form of No…

Isn't all this planning for future redundancy what the article is arguing against?
Post reply on HN