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

161–170 of 374 posts

Re: Choose Boring Technology (2015)

#161

Post by jmartrican »

koheripbal wrote: post #117
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. Mat…

> don't make a special niche process for every "opportunity" that comes by.

At my current job we call those snowflakes. "no snowflakes" is the motto of one of our senior architects.

Re: Choose Boring Technology (2015)

#162

Post by Kwantuum »

collyw wrote: post #97
js4ever wrote: post #34

Earlier quoted context omitted.

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

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 not always easy, but it's a language with lexical closures and easy and familiar syntax, it's also very expressive and has a vast ecosystem supporting it. And you can even add the typescript compiler on top if you want compile-time type-checking.

It's also async out of the box, and while that doesn't solve all problems, it scales surprisingly well with no performance tuning whatsoever, it even has decent asynchronous primitives that make it easier to write correct code.

Re: Choose Boring Technology (2015)

#163

Post by corytheboyd »

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

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.

Re: Choose Boring Technology (2015)

#164

Post by layoutIfNeeded »

madeofpalk wrote: post #118
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”

It’s not really about retaining talent, rather preventing them working for their competitors.

Re: Choose Boring Technology (2015)

#165

Post by _qulr »

ChrisMarshallNY wrote: post #150
_qulr wrote: post #144

Earlier quoted context omitted.

> I actually mentioned that. Like, immediately after the quoted phrase. I'm rereading your previous comment multiple times but unfortunately still failing to see what you're referring to. The only explanation I can see is "we were quite familiar with Lattner and LLVM, so we were quite aware of his propensity for WIN. That gave me some confidence, going forward." > They also announced a full system API, as well as a p…

You are correct. It was the next comment I made (so I removed that smartass line). I apologize. They have had a Swift roadmap forever. I think it's now kept on swift.org. I'll see if I can find it. I think it's a fairly sparse one. I really only cared about the evolution through ABI Stable. All I needed to hear, was that was a goal. You are right. They tend to eschew roadmaps, but they did a "hard-sell" with Swift. T…

> I really only cared about the evolution through ABI Stable.

Ok, but that came later and wasn't present in 2014.

> they did a "hard-sell" with Swift

I agree with that. :-)

> "Full System API" is the native frameworks; UIKit, AppKit, WatchKit, etc., as well as things like WebKit and MapKit.

Swift did of course have bridging to Objective-C and the preexisting Objective-C API. I find it strange to equate language bridging with announcing a full system API — an API originally announced around the turn of the century (can't believe I'm using that phrase now). Cocoa-Java, which no longer exists, also had such bridging, as does PyObjC and MacRuby/RubyCocoa. Still, most of the system API to this day are written by Apple in Objective-C.

Re: Choose Boring Technology (2015)

#167

Post by danjac »

koheripbal wrote: post #117
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. Mat…

The "opportunity" is often a dangling carrot from a big enterprise customer. It's very hard for a cash-strapped startup looking to make bank and reputation to turn these opportunities down, and they don't look at the TCO and long-term costs in terms of complexity and tech debt.

Re: Choose Boring Technology (2015)

#168

Post by bitwize »

NomDePlum wrote: post #146
collyw wrote: post #95

Earlier quoted context omitted.

I am left maintaining a mongo db from 7 years ago or so, when NoSQL was peak hype cycle. Like you say it´s crap.

Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. 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.

> 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 recommend.

Re: Choose Boring Technology (2015)

#169

Post by stepbeek »

NomDePlum wrote: post #146
collyw wrote: post #95

Earlier quoted context omitted.

I am left maintaining a mongo db from 7 years ago or so, when NoSQL was peak hype cycle. Like you say it´s crap.

Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need. If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. 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.

This is a good point. If we ignore obvious key-value examples, I’m curious about how much data really isn’t relational.

Re: Choose Boring Technology (2015)

#170

Post by gravypod »

Kwantuum wrote: post #155
b0afc375b5 wrote: post #38

Earlier quoted context omitted.

For anyone else curious, I found the postmortem here: https://mcfunley.com/why-mongodb-never-worked-out-at-etsy Which was compiled here: https://github.com/icy/w2w

That repo is interesting. A quick ctrl+F seems to indicate that pretty much every instance of "MongoDB" is "Moving from Mongo to Postrges or DynamoDB" (there is one single entry of moving to Mongo from MySQL). Almost as if Mongo is just not a good database (or people are too eager to use it for things which it does not do well).

Making efficient use if mongodb is very difficult but if you build your app and expectations correctly you can get something very performant. For example pre-4.x listing huge collections was unexpectedly extremely slow.
Post reply on HN