4,717 karma · joined September 16, 2022
Rapid7 -> Dropbox -> Grapl -> Datadog
This feels like at least two layers of special behaviors.
> so management has to step in to baby us.
An engineer wrote that post lol
I could just as easily say "webscale" is great because I can write a paragraph about how it will address all of our scaling problems and carry us into the new decade of infrastructure or whatever the hell.
These paragraphs of "it's good" all sound right in isolation but they're purely negative for actual conversations. Actual technical conversations require understanding what problems have to be solved, under what constraints, and then determining properties within the solution space. I am shocked at how controversial "map requirements to solutions" is, how desperately people seem to want to turn that into a one word conversation as if it's onerous.
I've exclusively seen it used as a thought terminating sentence.
This article is bad. It has led to bad things. It has a bad premise. It has bad ideas.
The correct solution to the problem it wants to address is that engineers should justify technical solutions by mapping product level issues to technical solutions.
That's it.
Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3?
> The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool.
I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation.
> Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk.
I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably.
The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one!
> Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.
I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve.
> In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework.
I don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation.
> “Boring” and “simple” are ways to convey that it’s good to be risk averse.
They are very bad at this.
> It’s a bit of rhetorical flourish
I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits.
> choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.
New technology may not be orthogonal to it, it may be critical.
I feel like I've been pretty clear.
1. "Boring" is a bad term that obfuscates things that do not merit obfuscation. It's like saying "brb" in person instead of "I'll be back in 5 minutes" - "brb" means nothing to me, 30 seconds, 5 minutes, 30? And it saved you like 2 words? Silly, unserious, and fine for casual conversations but not for technical decisions like "what database do we use?".
2. It lets people lean into a bias. I see massive bias away from "hyped" tech. People on HN constantly condemn projects for being "hype" tech with no merit behind their criticism, or at least no expressed merit. It sounds very smart to say "oh that's just hyped" - this is a known bias that extends outside of tech. Calling something "boring" makes you sound smart but it doesn't convey information and it leads to the exact same decisions that "hype" would.
Having a conversation about technology is not hard. It's the job. It's one of the most important parts of the job. It is not worth papering over with some biased wording that is guilty of the same exact failure modes of the approach it attempts to deride.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.
We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.
We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.
In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.
> Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
Or just encourage your team to have rational discussions about technical choices, how is this controversial?
That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.
> You have an objection to something. It's clearly not to the article's point, though.
It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.
Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
> People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"
Rule of thumb. And it's not a rule. It's a bias based on a vague term.
> More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution
It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today.
> around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
That is, if someone said two sentences, I would only care about the second one:
1. "We should use this because it is boring"
2. "We should use this because we understand the sharp edges"
I wouldn't care at all about (1) and I'd have a real conversation based on (2).
Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak.
For example, I may think "New" means untested, but is that true? What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I should just say "Choose well tested" instead of "Choose old" - lots of old software is very poorly tested.
Maybe I think that "Old" implies better documentation, but does it? Lots of older projects have insane cruft and weird edge cases that are undocumented and accumulated over years.
Why do we need a metaphor? Why is "innovation token" helpful?
If you're incapable of evaluating a technology in terms of these properties, you aren't a serious developer and "boring" will not save you.
Sit down, write our your requirements, determine candidate solutions, and choose them based on their fit. "Boring" means nothing, it's a vague proxy term. "Well tsted", "performant for our use case", "developers know it", etc mean something.
> MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
Literally every one of these has caused hilarious and disastrous failures for me in my career. But yep, boring.
> If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens.
What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?
I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.
> She has held a variety of academic positions at Temple University, Princeton, and the University of Pennsylvania – where she completed her PhD in Political Science and Government. Her Dissertation was titled “Small Talk: The Socialities of Speech in Liberal Democratic Life.”
This doesn't even feel relevant to ethics. It's adjacent, but like... I guess I'd expect a moral philosophy degree? Maybe even mathematics in there?
I find the position odd. Curious to hear what these people do and how you choose who to hire.