"[1] Keep your customers happy" - It's hard to actually have a team that respects this lesson. Even if one or two people on the team believe in this rule, others won't, and if they have equal say in the final product, it means the customers will suffer. Dogfooding is really the only way to fight this. Become your own most demanding customer.
"[4] But realize that customers may not express what they really need; don’t take requirements at face-value, instead spend the time to understand their use case in detail. Read their code." - Yep - Users Are Liars. They will lie right to your face, about requirements, deadlines, use cases, functionality, costs, etc, for no reason at all. Never believe anything a user says. And obviously, never tell them you think this.
"[9] If you get good and/or aligned managers, be as understanding, supportive, and accommodating as you can. If you don’t get such managers…" - Become the shadow manager; Team Lead, Lead Developer, Delegate Architect, etc. Ask the manager if you can get "hands-on experience" with various tasks like: running ceremonies, taking meeting notes, coordinating work, planning, resolving blockers. Reach out to other teams in private to resolve problems without involving any management, and be careful that the people you reach out to don't widen scope to their managers. Hide problems and bubble up accomplishments to the bad manager. You'll get none of the credit, but the manager won't have the opportunity to make everyone's lives bad.
"[10] Make your project robust to re-orgs." - Of these, the most resilient I've seen are the ones that promise the moon, and then deftly delay everyone's realization that it doesn't live up to the hype until they're all deeply bought in. Don't make the mistake of trying to get an executive to buy in, because they'll be gone in 3 years and everyone will ditch your project.
"[15] Design APIs with migration to new implementations as a first-class consideration" - Yes, yes, yes!! Literally all technology is replaced eventually, most of it in 3-5 years. Plan the exit strategy at the outset.
"[21] Have the right number of abstractions" - The correct number of abstractions is the minimum possible. Every abstraction should be a solution to a problem. You have to define the problem that the abstraction was meant to solve, and then ask yourself if there is a simpler way to solve that problem.