First do it, then do it right, then do it better. Get the ugly prototype in front of users.

I tend to agree with that one. I’ve heard it phrased “Don’t ask users what they want. They don’t know. Just give them something to work off of, because they most definitely know what they don’t want”.

But there’s a catch that I’ve seen twice now: If a feature doesn’t work correctly when you present it, users lose trust and avoid it. That could mean they use the ‘long way around’ when creating entities instead of just copy/pasting them, or that they unnecessarily refresh web pages instead of trusting the state that’s displayed to them.

Even when you tell them that their behaviour is … not optimal, they stick to it.

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.

That has some really insightful advice and even something I hadn’t considered. They mentioned that with enough users, even bugs become features that are used. People rely on the way a system works, whether it was intentional or not and maintenance could mean disruption.

I am not a dev but I am in IT and think quite a few of these ideas could be applied outside of code.

Lesson 1 to 21 from Google: Fascism means profit. Therefore, it’s good.