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…
Choose Boring Technology
161–170 of 356 posts
Re: Choose Boring Technology
#162Earlier 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…
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
#163Always 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"
Re: Choose Boring Technology
#164Another 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!
Re: Choose Boring Technology
#165Earlier 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.
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
#166Earlier 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…
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
#167Earlier 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.
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
#168There’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.
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
#169Earlier 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.
Re: Choose Boring Technology
#170Earlier 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…
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.