Live data from Hacker News

Choose Boring Technology

boringtechnology.club

161–170 of 356 posts

Re: Choose Boring Technology

#161
post #86

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to…

The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

Re: Choose Boring Technology

#162
post #92
post #84

Earlier quoted context omitted.

But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features

I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real product…

As a counterpoint, I have had a developer who had wrote production ClojureScript tell me it was the worst of all worlds - it doesn't abstract away issues of the DOM and yet you still have to debug what was happening in JS and translate it over to Clojure.

Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.

Re: Choose Boring Technology

#163
post #79

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprise…

> "Happiness comes from shipping stuff" Actually, the rest of your comments points to: "Happiness comes from shipping good stuff"

"The way to ship good stuff is to ship lots of stuff and keep the good bits" - apologies to Linus Pauling

Re: Choose Boring Technology

#164
post #156
post #3

Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume. Great that he's spreading the word!

> you're supposed to solve problems instead of chasing trends and padding the resume Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!

Agree, commenter above you might have thought resumes and interviews are related to the job we ought to be doing and they aren’t.

Re: Choose Boring Technology

#165
post #115

Earlier quoted context omitted.

Part of the point of the article is that you probably don't need new technology to create a new _product_.

Right, for an incremental product for sure. Slack is an incremental product but now is worth billions. Point taken but Slack is not SpaceX.

Your example of a sector where we can’t use conservative technology to make progress is space travel? ;-)

But look, I see your point, but the “counterpoint” doesn’t actually disagree: the point is that a lot of incremental improvements in infrastructure feel transformative, but you get to pay the full cost regardless.

Re: Choose Boring Technology

#166
post #47

Earlier quoted context omitted.

> For example, in 1974 when the new Altair 8800 made the cover of Popular Electronics[2], an excited Paul Allen showed the magazine to a 19-year old Bill Gates. The "boring tech" advocates would tell them they're wasting their time with the "new fad of microcomputers" and they should look at boring IBM 360 mainframes instead. I remember reading a book around the late 90s (the book was written in the early 90s) about…

That's a false analogy, because the micro was a category changer. It was literally the basis of entire new markets. A lot of people saw that coming. A lot of other people - like DEC and DG - didn't. IBM mostly didn't, but was lucky enough to have a small division that did in spite of the culture around it. (And they lost it. Too bad.) Node, Mongo, Clojure, etc were never category changers - they were solutions made b…

> But for most applications they don't cut development time, minimise bugs, simplify maintenance and bug fixes, de-complexify system architecture, [...] scale with minimum effort

I honestly have yet to see a Java or C++ codebase that is better on any of these fronts than a Clojure one.

> they were solutions made by people who like to tinker for other people to tinker with. For the sake of tinkering. Hyped into orbit with industrial quantities of hypeology.

This seems to lack context of how we were doing development at the time these technologies picked up.

One should be careful not to apply the "just keep doing what we did in the 90s/80s" argument to every piece of technology not taught in academia. I've used NoSQL databases in cases where traditional RDBMS would have fallen over and exploded.

Re: Choose Boring Technology

#167
post #92

Earlier quoted context omitted.

I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real product…

As a counterpoint, I have had a developer who had wrote production ClojureScript tell me it was the worst of all worlds - it doesn't abstract away issues of the DOM and yet you still have to debug what was happening in JS and translate it over to Clojure. Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.

ClojureScript compiles down to JavaScript, so yes, it is entirely possible to spell the same buggy jQuery site you would in regular JavaScript but with the parentheses on the outside and it will solve no problems for you. I don’t think it’s reasonable to say eg reagent does not solve any DOM problems. Similarly, CLJS uses the same source map standard as every other JS targeting language, so you can debug in CLJS with the tools you already use just fine.

Their negative experience is based on facts not in evidence so I can’t really comment specifically. The StackOverflow community survey results suggest their experience is at least unusual.

Re: Choose Boring Technology

#168
post #86

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to…

The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

> The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

Sure, if your interests are closely aligned with the company. But as you noted, the junior engineer jumped ships 3 times already, probably with significant salary increase each time, and in part due to a CV that includes the use of exciting modern tech, which shows he's eager to learn and is passionate etc. Why would he care how the old company is doing?

People often don't stay at the same place long enough to feel the long-term consequences.

People will do whatever the (job) market rewards and is fun.

It's a bit different when you wear multiple hats. Then it may be best to focus on one specialization and keep things boring for the rest. For example at a small company, as a single-person data scientist/engineer/developer you may want to focus less on the IT fads and more on the modeling, because your CV is best padded by fancy new ML models, not by fancy new database engines. Or vice versa.

Re: Choose Boring Technology

#169

Earlier quoted context omitted.

No, reinventing the wheel is alright; at best you may find a new and better kind of wheel, at worst you'll still learn something. This is forgetting that wheels can be round.

Our lifetime is finite. Given the choice, I'd rather invent the car than reinvent the wheel.

It's nice that different people have different interests. I, for one, find materials science fascinating and car engineering rather bland.

Re: Choose Boring Technology

#170
post #47

Earlier quoted context omitted.

> For example, in 1974 when the new Altair 8800 made the cover of Popular Electronics[2], an excited Paul Allen showed the magazine to a 19-year old Bill Gates. The "boring tech" advocates would tell them they're wasting their time with the "new fad of microcomputers" and they should look at boring IBM 360 mainframes instead. I remember reading a book around the late 90s (the book was written in the early 90s) about…

That's a false analogy, because the micro was a category changer. It was literally the basis of entire new markets. A lot of people saw that coming. A lot of other people - like DEC and DG - didn't. IBM mostly didn't, but was lucky enough to have a small division that did in spite of the culture around it. (And they lost it. Too bad.) Node, Mongo, Clojure, etc were never category changers - they were solutions made b…

If you're trying to Get Shit Done, they're mostly a disaster. (Clojure less than the others - but it's still not solving the problems that actually matter in a production context. Not really.)

Hrm, as someone that has written lots of Clojure code over the years, including a few business critical systems, I'm wondering what leads you to believe it's not a language for getting shit done.

I can spin up a web service in just a few minutes, drop in the middleware I need, route requests, spit out JSON, talk to DBs, and in a pinch, leverage libraries from the Java ecosystem for any missing pieces to the puzzle.

Deployment, dependency management, testing, etc... are all fully solved problems, and very mature technologies underpin the pieces that matter regarding battle tested services (jetty, jdbc adapters, etc).

Not trying to be a zealot here, but I also hate to see misinformation permeating the thread.

Post reply on HN