Great engineers are in high demand and are always busy, but they always try to help. That's because they are naturally curious and their supportive mind is what made them great engineers in the first place. It's a sheer joy to have them on your team, because they are problem solvers.

"In the Face of Ambiguity, Refuse the Temptation to Guess". That is one of my favorite rules in PEP 20 - The Zen of Python (https://peps.python.org/pep-0020/).

I think there is a strong correlation between writing skills and programming. All the best engineers I know have good command over at least one human language - often more. Mastering the way you write is mastering the way you think and vice versa.

I am a designer who learned to code, then learned to encode accessibility, because *that makes me better at what I do*. Interfaces are made of code and there are accessible ways to organize that code. ***Organization is design***.

**Shipping builds momentum. Complaining creates distrust**. Whenever I saw engineers come to a team and start shipping from day zero, it created momentum for them. After observation, they got the trust to share improvements with the rest of the team. Often, these improvements were not just philosophical discussions but actual implementations, with small steps. On the other hand, when I saw engineers complain about how tech debt was not sustainable and how everything was broken without shipping on time, exploring and presenting alternatives, the team got averse to this person.

The only way to write complex software that won't fall on its face is to hold its global complexity down — to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole.

The quantity group has an advantage here! They've already become intimate with imperfection. They've learned that each attempt is data, not judgment. They've developed what psychologists call *"task orientation"* rather than *"ego orientation;"* they're focused on improving the work rather than protecting their self-image.

Jackie Stewart, a triple Formula 1 world champion (1969-93), described how, while he wasn't an engineer of the cars he drove, he still needed a sense of how they worked (https://www.carandclassic.com/magazine/mechanical-sympathy-understanding-our-classics/), how they responded to what the driver was trying to do, a sense he called mechanical sympathy. Martin Thompson brought this concept into software (https://mechanical-sympathy.blogspot.com/2011/07/why-mechanical-sympathy.html), by talking about how a similar knowledge of how computer hardware works is vital to writing high-performance software.