Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

211–220 of 374 posts

Re: Choose Boring Technology (2015)

#211

Earlier quoted context omitted.

I have been writing it full time about 13 years. I love writing in this language, and TypeScript even more. I am just frustrated by what appears to be some combination of insecurity, false expertise, and a vehement lack of passion in the work force. If I want to be happy I should move on to a different technology stack, but I really enjoy making products in this language.

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…

TypeScript is nice when you are working with data structures because everything can be defined as interfaces, including functions and methods. This allows you to identify errors as you are writing code instead of having to execute it. Of course this only works if you make use of strict type definitions. TypeScript is like steroids in that it only makes you more of what you already are, which could be quite negative. TypeScript is not a supplement for missing discipline.

> I'm surprised you haven't run into more of these people that just seem to use TS as a complexity multiplier for every bad engineering decision they make.

AngularJS claims to be TypeScript but most instances of Angular code rarely make use of type definitions, which then defeats the whole point of TypeScript and then only contributes to spaghetti and tech debt.

Re: Choose Boring Technology (2015)

#212
post #47

Really good presentation. Even in this form. These are the best arguments for choosing Boring Tech that I’ve seen yet. Almost gave me a sinking feeling: > If you behave that way you miss out on the part of the curve that we call “mastery.” That’s a state to the right on this curve, where there are still problems. Everything still sucks but it feels manageable. > The grim paradox of this law of software is that you sh…

The hypothesis fails because it assumes all curves are the same - and all tech has the same number of kinks; which is patently false.

Re: Choose Boring Technology (2015)

#213

Earlier quoted context omitted.

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

> imagine they are writing a post-mortem after the proposed initiative failed

I was thinking more along the lines of "imagine they are writing a post-mortem after the proposed initiative succeeds". Even if everything goes perfectly, what do we honestly expect to have at the end? A system without problems? Nonsense.

Re: Choose Boring Technology (2015)

#214
Having shiny cool tech to solve problems isn't all too different than having 1. a hip office to work at, WeWork-style 2. wearing the latest fashion or latest cool hoodie if you're in SV 3. latest mechanical keyboard design ... the list goes on and on. It makes everything easier, 1. you can hire easier because the hip engineers see new shiny thing and would love to work on it most likely even if there is a slight pay cut or even if the product doesn't appeal to them as much as working at another company, senior engineers tolerate shiny new tech because a. they know they were once awestruck by other technologies when they first came out b. there is always a non-zero probability the shiny new thing is actually fundamentally better not just a short lived fad.

It's not a great explanation because it's a human issue, which usually as its solution has a mixed bag of technical and emotional reasons.

Re: Choose Boring Technology (2015)

#215
This essay from David Perell touches on a similar concept: https://perell.com/note/lateral-thinking-with-withered-ideas...

> It led to the 20th century’s most successful game console: the Game Boy. One day, a gaming engineer named Gunpei Yokoi was commuting home on the train when he saw a man playing with an LCD calculator next to him. Unfortunately, Nintendo didn’t have the budget to push the technological frontier at the time, so they used old technology to innovate. So long as the gameplay was engaging, Yokoi believed that players didn’t care about technical details like colors or screen resolutions. Compared to its contemporaries, the Game Boy was durable and affordable, which removed barriers to entry for users and developers. People would play for hours because it used AA batteries that were cheap and easy to find. Today, the Game Boy has sold more than 118 million units.

Re: Choose Boring Technology (2015)

#216

Earlier quoted context omitted.

You absolutely can. React is the gold standard right now. It's already been king for 6 years and it's not going anywhere. The hype for angular died down. The hype for vue has started to die down. This little bit of hype svelte has at the moment will die down. React does have a ton of problems but they all come from the next level of dependencies down. Shit like Gatsby and Nextjs won't pass the test of time. Neither w…

Have you tried redux toolkit? createSlices? Redux has greatly improved workflow for integrating with React. The main issue with Redux is that it pretends to be generalized state management engine, with all the overhead, while it’s in a shotgun wedding with React. Will React team attempts another state management, aka Flux, when Redux does 95% of features and is slowly being absorbed into React eco system anyway? Gats…

Not sure what you mean by the "pretends" statement.

Both the Redux core and Redux Toolkit _are_ completely UI-agnostic, and can be used with _any_ UI layer or even standalone.

Yes, most Redux usage is with React, and we do orient our docs around the assumption that you're probably using Redux and React together, but there's many people who are using Redux separately.

Re: Choose Boring Technology (2015)

#217

Earlier quoted context omitted.

That's definitely part of it. I also think developer sometimes aren't sufficiently critical when picking technologies and solutions. They fall into the trap of looking at how bigger companies operate, without considering if they actually have the same requirement, budget or even problem. For example, you need a search feature. ElasticSearch is big in search, there's lots of article about people implementing ElasticSe…

Great point. I’m working with a client right now where 90% of the operational pain and low impact dev could be resolved by admitting that the project does not need to resemble a FAANG system.

One company I worked for went to great lengths to emulate FAANG.

But they were a medium sized company. They were absolutely crushed under the weight of FAANG "best practices" and technology. They lost time rewriting perfectly fine code. They chased the microservice fad. And they lost market share.

It's in the interest of FAANG to maintain this idea of needing k8s, this massive CI pipeline, certain processes, etc. etc. Because it slows down competition. It halts startups. It slows progress. They want to throw as much overhead as possible at smaller companies.

The thing people need to realize is that FAANG are entrenched. They are as risk-adverse as can be. They will happily write unit tests and maintain 100% test coverage and do all of this crap because they are more scared of losing market share than innovation. They are in full defense mode. Google is implementing all manner of protectionism to maintain their ad market, for example. Plus, they have the deep pockets to pull it off. Any company smaller than FAANG will sit there with their wheels spinning.

Re: Choose Boring Technology (2015)

#218
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…

> they fear they look incompetent using those old technologies

It sounds like you're saying the fear is unwarranted. It very much is a real fear as long as people interviewing them actually count that against them and value new tech.

Re: Choose Boring Technology (2015)

#219
Choose Boring Technology (but not the same article) - https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments)

Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments)

The boring technology behind a one-person Internet company (2018) - https://news.ycombinator.com/item?id=20985875 - Sept 2019 (451 comments)

Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments)

Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)

Also: current ongoing thread

Choose Exciting Technology - https://news.ycombinator.com/item?id=26212563

Re: Choose Boring Technology (2015)

#220
By committing to an technology early you are limiting your options! You are limiting the possible ways problems can be solved. You are limiting the talent pool/hiring options.
Post reply on HN