201–210 of 269 posts
Golang was supposed to be boring by design ( https://go.dev/talks/2012/splash.article ) and you can use it in a boring way. Even learning golang is relatively boring.
Counter-position: "choose most appropriate technology".
Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.
It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.
In one case, ten years later, the company is still struggling to maintain their Scala applications in an environment where there's barely any Scala developers (and who charge a premium because it's specialist work), while the main author(s) went on to work at the company behind Scala itself. I'm sure Scala is great for specific use cases (just like every other non-top-10 language out there) but please, think very carefully before trying to build your company on top of it.
Earlier quoted context omitted.
It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.
I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.
New energy crisis this year, the servers held, the company made a lot of money from new contracts via a combination of getting lucky with long-term buy-in contracts and the servers staying up unlike the competition. But there were no heroes, no praise to e.g. the developers putting in the extra hours, etc - it was business as usual, or business as it's supposed to be.
Earlier quoted context omitted.
I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.
I've been noticing this as a solo dev. I need to put lots of work into infra and security, and all I get for it is... the thing not blowing up (hopefully!). The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
It's why senior developers should end up in management or in positions of making decisions, but it's a completely different type of job to software development, where reason and objective truth and whatnot is barely relevant compared to social skills and connections. (this may be inaccurate, I'm not in that 'layer').
Counter-position: "choose most appropriate technology".
Does nobody ever think of trying more than one technology? It’s like people buying a car based on what everyone else is driving rather than actually driving different cars.
Does nobody ever think of trying more than one technology? It’s like people buying a car based on what everyone else is driving rather than actually driving different cars.
Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.
Earlier quoted context omitted.
I would say depends what you're trying to do? Is NodeJS the simple, solid and rugged way this has been done for a decade now? If not, then it is an innovation. Second it depends on what your or your teams experience level is. Have you ever built a serious thing with it and do you have multiple years of experience running and maintaining it? Yes? Then it is probably the boring choice. Would you be okay with leaving th…
> Second it depends on what your or your teams experience level is. +1. I work in a Skunkworks department inside a larger/older company and we recently decided to stop using Python in the future, the company's language. Node.js, Go, Rust, C#, etc, all of those are extremely boring for us . They're stable and we get things done in minutes. In Python it's like pulling teeth, with constant API changes and refactors from…
Earlier quoted context omitted.
How many times has the stable and established X surprised you with some unexpected behavior? Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return…
How many times have existing APIs made by experts in their fields had bugs. How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed? You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?
Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)
But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.
Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.
I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.
Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.
Remember Heartbleed? The old "battle tested" system turned out not to be.