1. The best engineers are obsessed with solving user problems.

Ehh. Not sure I agree. I mean, I think that there is a valid insight that it's important to keep track of what problem you're actually trying to solve, and that that problem needs to translate to some real world, meaningful thing for a human.

But I also think that there are projects that are large enough that it's entirely reasonable to be a perfectly good engineer who isn't dealing with users much at all, where you're getting requirements that are solid that have been done by up someone else. If you're trying to, say, improve the speed at which Zip data decompression happens, you probably don't need to spend a lot of time going back to the original user problems. Maybe someone needs to do so, but that doesn't need to be the focus of every engineer.

3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.

I think I'd go with a more specific "It's generally better to iterate". Get something working, keep it working, and make incremental improvements.

There are exceptions out there, but I think that they are rare.

8. At scale, even your bugs have users.

With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.

This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.

This is one thing that I think that Microsoft has erred on in a number of cases. Like, a lot of the value in Windows to a user is a consistent workflow where they can use their existing expertise. People don't generally want their workflow changed. Even if you can slightly improve a workflow, the re-learning cost is high. And people want to change their workflow on their own schedule, not to have things change underfoot. People don't like being forced to change their workflow.

The fastest way to learn something better is to try teaching it.

I don't know if it's the fastest, but I do think that you often really discover how embarrassingly large the gaps in your own understanding are when you teach it.

A little kid asking "why" can be a humbling experience.