That's what I had in mind! The whole post is a claim that evaluating knowledge work got more expensive because cheaper measures stopped correlating well with quality.
If someone was already evaluating the work output using a metric closer to the underlying quality then it might not have been a big shift for them (other than having much more work to evaluate).
You’re right, there are downsides like turbine you mention! We mitigate it by running a hot backup we can switch to in seconds and a box in which we test restoring backups every 24h, that’s necessary! But it requires 3x the number of big expensive boxes.
I still think it’s the right tradeoff for us, operating a distributed system is also very expensive in terms of dev and ops time, costs are more unpredictable etc.
At $WORK, we write ~100M rows per day and keep years of history, all in a single database. Sure, the box is big, but I have beautiful transactional workloads and no distributed systems to worry about!
Author here. I did not expect to see my post on HN!
It was a rant, I was venting, it’s not supposed to be an objective statement about the state of tech. It’s shouting into the void about the things I find unfair and unbearable, I don’t think it’s a great HN material.
I made up parts of the story because it didn’t happen to me and I didn’t want to share details of somebody else’s situation.
Learning Rust by building a simple database using it.
I’ve done my share of programming languages (PHP, C++, Python, Ruby, Haskell) and for the last 10 years I’ve been working in OCaml (which I love so much) but Rust would be a nice addition IMO.
And I never implemented LSM style database before! So that’s fun.
Funny, I spent the last decade working in a strongly typed natively compiled language (OCaml) and for fun I’m venturing into Ruby more and more, so kinda opposite of what you did :)
I’d agree that I wouldn’t like to support a large Ruby codebase commercially but in team of 1-4 devs and codebase not much larger than 10k lines it’s very productive (numbers pulled from thin air ofc).
1. A Philosophy of Software Design is very good. Not the whole of it but it’s short and to the point.
2. Fiction, as diverse as possible. I apologise for making assumptions but many software engineers are secretly lacking in understanding other people, what kind of of life experiences that have, how they think about the world, what is important for them. If you work with people it is going to be useful.
Also, it’ll enrich your life and you’ll have more to talk about during coffee breaks :)
If someone was already evaluating the work output using a metric closer to the underlying quality then it might not have been a big shift for them (other than having much more work to evaluate).