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

141–150 of 374 posts

Re: Choose Boring Technology (2015)

#141

Post by rossdavidh »

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…

All true, but I would like to add that their manager would like to say (when interviewing at FAANG) that they managed cool edgy new technology as well. So they are not motivated to stop these things because it sprinkles hot keywords on their resumes, as well.

Re: Choose Boring Technology (2015)

#142

Post by carapace »

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…

> trying to rewrite Etsy's backend in Scala and MongoDB.

The first Sid came in and wanted to rewrite in C++.

Then the second Sid wanted to rewrite in Java.

The whole time the HTML is 25% space chars, served, sent, received, discarded, because the PHP guy likes deep indentation, and the DB is constantly burning like the sun because all the business logic is in stored procedures.

(That was the problem, not which abstraction the servers are written in, since all they do is pass data back and forth to the fiery inferno of the database.)

Re: Choose Boring Technology (2015)

#143

Post by vvanders »

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

That's a really common pattern in gamedev too. Median career is something like ~3 years so those that stick around are okay with the crunch and other shitty parts of the industry.

Combine that with gatekeeping/I did my time you have to do yours and not much has changed there over the years.

Re: Choose Boring Technology (2015)

#144

Post by _qulr »

ChrisMarshallNY wrote: post #140
_qulr wrote: post #134

Earlier quoted context omitted.

> I don’t do “boring,” as much as I do “mature and robust.” > I’ve been writing in Swift since the day it was announced May I ask how you consider these to be compatible?

> May I ask how you consider these to be compatible? It was a calculated risk. Since the company I was working for, at the time, was never going to use Swift, my "bread and butter" was at no risk, whatsoever. We were a C++ shop. I just started working with it on nights and weekends. Being a C++ shop, however, we were quite familiar with Lattner and LLVM, so we were aware of his propensity for WIN. That gave me some c…

> 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 product roadmap.

I'm not quite sure what you mean by "a full system API", and does Apple ever announce a product roadmap? I would definitely be interested in this roadmap of which you speak. :-)

Re: Choose Boring Technology (2015)

#145

Post by mikewarot »

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…

>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 happiness and your own knowledge, not the profit of your higher-ups.

Yes, by all means, have fun, at HOME, not on company time.

Re: Choose Boring Technology (2015)

#146

Post by NomDePlum »

collyw wrote: post #95
code_duck wrote: post #13

Earlier quoted context omitted.

I had a small business depending on the Etsy API during the time they transitioned some storage to Mongo. The immediate effect for us was a downturn in functionality and reliability with no apparent advantages. In the midst of other serious concerns about their direction, we questioned why Etsy was doing this on the API mailing list and were told basically we didn't know what we were talking about and it wasn't out b…

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.

Re: Choose Boring Technology (2015)

#147

Post by sdfsfsf3kjdf »

collyw wrote: post #100
monsieurbanana wrote: post #92

Earlier quoted context omitted.

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

There is no hate in that comment, just criticism.

Extremely shallow criticism based off of little more than personal anecdotes.

Re: Choose Boring Technology (2015)

#148

Post by dukeyukey »

whimsicalism wrote: post #135
collyw wrote: 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.

Oh, but Python is an ideal backend language? Give me a break.

If you want something mature, with libraries for everything, solid backwards compatibility and basically the best "boring" choice, go with Java. And if your devs want to mess around a bit, mixing some Kotlin in is basically harmless and easy to reverse if needed.

Re: Choose Boring Technology (2015)

#149

Post by mortehu »

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.

Agreed. I once owned a 30 year old two stroke moped. It was very easy to fix. In fact I fixed it almost every week.

Re: Choose Boring Technology (2015)

#150

Post by ChrisMarshallNY »

_qulr wrote: post #144
ChrisMarshallNY wrote: post #140

Earlier quoted context omitted.

> May I ask how you consider these to be compatible? It was a calculated risk. Since the company I was working for, at the time, was never going to use Swift, my "bread and butter" was at no risk, whatsoever. We were a C++ shop. I just started working with it on nights and weekends. Being a C++ shop, however, we were quite familiar with Lattner and LLVM, so we were aware of his propensity for WIN. That gave me some c…

> 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. They knew it would be difficult to build momentum with.

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

When Swift was announced, they had APIs for most of that stuff. I was pleasantly surprised. I had a full app, working within a day or so (using beta Xcode, of course).

Post reply on HN