In the true HN spirit, I have a little script goes through the Hacker News API and shows them as an RSS feed. But if you'd rather use something off-the-shelf there's https://hnrss.org/submitted?id=synergy20
Simplicity bias, kind of like "bikeshedding". A large number of people can read this quickly, agree with it, and upvote it. Whereas articles about optimising machine code for the Apple Silicon CPU, or "Risks to the Glen Canyon Dam" are a lot more niche.
Personally, I follow specific people who regularly submit interesting content, and pay less attention to the homepage.
I’ve seen first hand people hired who’ve aced the system design interview but then fail to get much done. Building systems in the real world is much more than a few high-level components and algorithms - it’s about all the edge edge cases, tricky stakeholders, ambiguous and changing requirements, sequencing and coordinating small pieces of work.
It’s hard to tell between those who know their stuff, and those who are good at memorising all the various courses that tell you what to say. By telling the candidate what system to design you make the latter’s job easier.
It’s a bit like Schneier’s Law. You can put in place protections that you personally cannot workaround, but that doesn’t mean someone with sufficient means and motivation would also be blocked.
There are three volumes of "The Data Model Resource Book" by Len Silverston, and despite being about 20 years old they remain industry best practices. All sorts of data model design patterns - insurance, ecommerce, data warehouses, party, finance, etc. David Hay's "Data Model Patterns" is also excellent, although less concrete.
Because managers also have managers. If the managers at the highest level think developing software is pretty similar to packing widgets in a factory, they understand and want to see the Frederick Windsor Taylor school of management in the engineering department.
For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.
But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.
Excellent writing, I really enjoyed the content of the post and the way it’s written.
This phrase particularly stood out to me:
> We are stronger by considering the opposite first.
That’s something I’m not very good at, but work hard to do. In many situations I have a tendency to assume I’m right, and that as soon as my interlocutor understands my argument, they will see I’m right. “I’m a rational person and I believe X, so if you don’t believe X you must be irrational.” So I spend lots of time clarifying my argument, and it gets nowhere.
By genuinely spending a larger proportion of my time thinking about others’ points of view, I arrive at better solutions.