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

251–260 of 374 posts

Re: Choose Boring Technology (2015)

#251

Post by spion »

deckard1 wrote: post #241
BigJono wrote: post #184

Earlier quoted context omitted.

It's funny, I have about 13 years experience, have been senior in both enterprise, start-ups and everything in-between, and have basically the exact same view about front end dev as your original post. Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff. IME all the same people that overengineer everything with god awful dependencies are the s…

> some constant strings containing css breakpoints as the type 'string | int' yeah this really is the fundamental problem with TypeScript advocates. They seem to come in two different breeds: A) people that would rather be doing Haskell but are forced to use JavaScript because that's where the jobs are and see nothing at all wrong with type inference and error messages that are 10 lines long and completely indecipher…

This really isn't true, and TypeScript is fundamentally different from most other typed languages (except perhaps for typed Scheme / typed Racket) and as such is often used in different ways. You should look into the differences.

Re: Choose Boring Technology (2015)

#252

Post by tootie »

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've never witnessed rogue engineers. If the team has business-driven objectives how could they possibly have enough time to chase rainbows? Any time a rewrite or refactor has been done in my org, it was pitched up the chain of command and explained in terms of business value (ie performance, maintenance, retention).

Re: Choose Boring Technology (2015)

#253

Post by ZephyrBlu »

koonsolo wrote: post #239
_qulr wrote: post #127

Earlier quoted context omitted.

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

What do you classify as the basics of programming. for loops and if statements?

Re: Choose Boring Technology (2015)

#254

Post by ZephyrBlu »

vp8989 wrote: post #160
twic wrote: 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…

"The very best developers are capable, and avoid complexity. The next best developers are capable, and love complexity. The worst developers are not capable." It's not always in one's control to avoid complexity. The simplest solution to a problem in a lot of cases may be 2-3x the lift (simplicity tends to require more work, complexity is easy) and thus blocked by the business. A holistically simpler solution may be…

It seems like a lot of people are too lazy to simplify things though.

You see this a lot with writing as well. It's very easy to ramble on, it's very hard to concisely convey your point.

Re: Choose Boring Technology (2015)

#255

Post by chrisco255 »

gravypod wrote: post #170
Kwantuum wrote: post #155

Earlier quoted context omitted.

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.

Yeah Mongo is 10 years old or so at this point. This article was written in 2015 about decisions made years earlier. It's now reached maturity and stability. It's now "boring tech".

Re: Choose Boring Technology (2015)

#256

Post by nine_k »

The title of this article, which makes rounds on HN, bothers me.

It's not about choosing a "boring" tech. It's about choosing tools you understand well and a master of.

You can be totally excited about e.g. TypeScript or Elixir, but as long as you have a solid experience of working with them, and a good understanding of their internals, they are safe bets.

Choosing a perfectly boring thing like Cobol is not going to help if you have no solid mainframe experience.

Re: Choose Boring Technology (2015)

#257

Post by chrisco255 »

hackerfromthefu wrote: post #78
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

It's generally high maintenance, npm dependencies, deprecations, leftpad, javascript new shiny culture etc You can make it work with more maintenance, but you did ask the question what's wrong with it!

It's really not high maintenance at all. Leftpad issue was fixed in less than hours the same day it happened and since then the NPM tooling for package management has improved a great deal.

JS shiny new culture doesn't really exist on the back end (and even front end js has calmed down in recent years). Express.js, the go-to framework 7 years ago, is still the go-to framework on Node today.

Node and Mongo are at this point "boring tech". Their limitations and trade-offs are well known, their benefits are also well-established, and their APIs and tooling have matured.

Re: Choose Boring Technology (2015)

#258

Post by ZephyrBlu »

BigJono wrote: post #192
criddell wrote: post #181

Earlier quoted context omitted.

My instinct is to build a native front end and connect to the back end over a REST (or similar) API. To me, that feels like the boring technology route.

Yeah, that's totally legit, and what I would default to. The reason stuff like React exists isn't because it's some big generic library for doing "frontends" that everyone has to use (even though that's how people see it, how it's marketed, and how people use it). If you want to know what a library is good for it's easiest to look at what it was originally built for, the very first problem it solved. For libs like Re…

React has innovated somewhat with lifecycle methods and hooks, but the main value is not in it's API. It's the ecosystem and scheduler.

Preact is a good alternative if you have a small app, but the reason it's so small is because it doesn't have a scheduler which might cause issues with larger apps.

Re: Choose Boring Technology (2015)

#259

Post by jonahx »

nine_k wrote: post #256

The title of this article, which makes rounds on HN, bothers me. It's not about choosing a "boring" tech. It's about choosing tools you understand well and a master of . You can be totally excited about e.g. TypeScript or Elixir, but as long as you have a solid experience of working with them, and a good understanding of their internals, they are safe bets. Choosing a perfectly boring thing like Cobol is not going to…

From the article:

> I chose “boring technology” as the pithy SEO-friendly title for this content, and I regret it most days. It’s kind of distracting. “Boring sounds bad, why is he saying it’s good?” Et cetera. It’s a real shitshow.

> But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down.

> It’s important to master the tools that you do pick.

Re: Choose Boring Technology (2015)

#260

Post by koonsolo »

ryandrake wrote: post #246
koonsolo wrote: post #239

Earlier quoted context omitted.

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.

I don't know what your company is, but it may not have a reputation for paying well. I've worked both at well-paying FAANG companies and lots of BasicAverageTech companies, and the candidate flow is night and day different. There is no shortage of people that "know the basics." In fact, there is no shortage of really strong candidates. They are out there, looking around to job hop like everyone else. It's just that t…

This is europe, and as far as I can tell all companies here have that problem.

On the other hand, great for us who can code :D.

Post reply on HN