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

201–210 of 374 posts

Re: Choose Boring Technology (2015)

#201

Post by spmurrayzzz »

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 is often a struggle I've had as an engineering manager (though also as an active individual contributor). When I push back on adding new components roughshod to a stack, its often framed as "not invented here" dogma. I certainly can do a better job at communicating my sentiments, because I can and do predictably come off as a "grumpy old man" in these conversations.

But more often than not, this feedback comes from engineers that a) have never been (as you say) bitten by complexity, or b) they aren't in the position to deal with all the negative consequences for those decisions.

There's probably some wisdom in letting your direct reports experience the kinds of failure in making these decisions, so they develop that sort of empathy, but the cost of that failure is sometimes just unacceptable for the business; especially in periods of cash runway constraints.

Re: Choose Boring Technology (2015)

#202

Post by 11thEarlOfMar »

> New tech typically has more known unknowns, and many more unknown unknowns. And this is really important.

Isn't this true in many facets of life? Like.... taking a new job... having your first kid... visiting a new city...

Are there processes for engaging in any new experience that enable you to know the outcome is going to be net positive before commencing?

Re: Choose Boring Technology (2015)

#203

Post by XCSme »

muramira wrote: post #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.

I decided to use MongoDB for a pretty big online multiplayer game and it worked very well, not many issues and the development time was a lot faster than trying to use SQL.

Re: Choose Boring Technology (2015)

#204

Post by XCSme »

solanav wrote: 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…

> Learn new things, don't stick with the boring tech

If you had a choice, isn't it better to build cool stuff with boring technology instead of building boring stuff with cool technology?

I think his point was to focus more on the product not on technology, and by choosing a boring technology you will likely have more time and fewer problems shipping awesome products.

Re: Choose Boring Technology (2015)

#205

Post by XCSme »

sprkwd wrote: post #59
threeseed wrote: post #35

Earlier quoted context omitted.

Modern cars are far more efficient, performant and easier to drive than a 15 year one. Just like modern web apps are far more scalable, highly-available, secure and performant then they were 15 years ago.

It’s easier to fix 15+ Year old cars yourself.

It's easier to not have to fix new cars.

Re: Choose Boring Technology (2015)

#206

Post by zbuf »

corytheboyd wrote: post #163
wffurr wrote: post #113

Earlier quoted context omitted.

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.

Interesting idea! Maybe instead of preventing you from commenting entirely, it just tagged all comments you leave as “have not read article”. I think the shame approach would actually work, but too many people would vehemently reject it for it to ever work.

Perhaps just annotate each comment with how many minutes between clicking the link and making the comment (similar to the green usernames)

That way the reader can decide for themselves. I'm less inclined to object to hasty responses to discussion points than I am to top level comments, but that's just personal choice.

Re: Choose Boring Technology (2015)

#207

Post by theptip »

Buttons840 wrote: post #196
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…

> The engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies? Sounds like the bored engineers need to be allowed to go home early, or have some 20% projects. Also, as John Gall teaches us with his tounge-in-cheek, yet never-the-less true principles[1] -- a principle so obvious most never give it any thought: "New System, New Problems" Can someone please just ask "what…

> "what do we expect some of the new problems to be?"

A name for this I’ve heard (and use) is the “pre-mortem”; you can get folks in the right headspace for what you are suggesting by asking them to imagine they are writing a post-mortem after the proposed initiative failed.

A good way of surfacing failure modes / potential quagmires.

Re: Choose Boring Technology (2015)

#208

Post by onetom »

js4ever wrote: post #34
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…

What's wrong with Node.js? It's super mainstream now. We have it in production since years, I see a LOT of companies migrating from everything else to node since years and it's a growing trend from what I see at my level with startups and even enterprises

Recommended "literature":

1. 10 Things I Regret About Node.js - Ryan Dahl - JSConf EU (https://www.youtube.com/watch?v=M3BM9TB-8yA)

2. Brendan Eich: JavaScript, Firefox, Mozilla, and Brave | Lex Fridman Podcast #160 (https://youtu.be/krB0enBeSiE)

Re: Choose Boring Technology (2015)

#209

Post by jefftk »

nizmow wrote: post #31
tpetry wrote: 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…

Typically though, FAANGs still solve their problems with boring technologies.

Yes! I work at a FAANG and over my time here it's been C++, Java, Python, and JS. The least "boring tech" part of my work has probably been that were moving from JS to Typescript? Mostly, we want to use things that we're confident can do what we need, and that we're confident don't have hidden surprises.
Post reply on HN