Highlights

“People wait until they are not getting promoted to realize, ‘Oh, I’m not growing.’ That is a very lagging indicator. The way I could tell I was not growing was by asking myself, ‘What did I do this month that I couldn’t do last month?’”

And he keeps shortening the loop as the field speeds up: “Given how fast things are moving now, people should continue to compress that time frame.”

Do this instead: Look back at the last month and name one new skill or capability you picked up and can already put into practice. If nothing comes to mind, choose one thing this week that you will commit to learning and using before the month ends. Make it concrete enough to apply, for example, a technique or a workflow you can take into a real task.

learned the hard way: raw individual output has a ceiling, and the way up past it runs through other people.

Helping people is one of the few real win-win-wins in this job. The person you help levels up; the company ends up with a stronger engineer; and you get the credit for scaling past your own two hands.

The engineers wanted to expose the system’s real structure. Bezos wanted the complexity hidden so the customer never had to feel it.

Christopher calls what AWS sells “packaged engineering,” and that phrase is the tell. The best engineers treat the messy internals as their own problem to absorb, so the person on the other side of the interface gets something simple.

Smart and hardworking is the price of entry, and almost everyone in the building has paid that fee. If everybody, including you, is out-grinding everybody else, and if the people around you are every bit as capable as you are, that makes you average.

Separation from the average comes from working on something different.

The best engineers will find the non-consensus bet or the unglamorous problem that nobody else wants to tackle, and they will plant their flag there.

Do this instead: Name the one thing your most talented peers are all competing on, then find the valuable problem next to it that none of them have claimed. Kun Chen did exactly this at the start of his career at Bing. While everyone else worked the roadmap they were handed, he used his spare cycles to build a tool that let the search team see where users clicked on the results page. Nobody had asked for that tool, but that work carried his first promotions.

large software projects have never been limited only by how quickly an individual can produce code. They are limited by how well people can coordinate their understanding of the system they are changing.

The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. This language is rarely written down in one place. It lives partly in documentation and code, but also in code review, conversations, arguments, and the experience of having to explain a change to somebody else.

The best articulation of the “you have to understand your codebase” side is Peter Naur’s famous paper Programming as Theory Building. I like this paper, but I think it goes too far in that direction. Naur’s core point is that when programmers work on a program, the code is really just a by-product, and the main product they’re working on is their “theory of the program”. That’s made up of their intuitive sense of what’s happening and why, which can only be partially captured by code or documentation. If they lost the code, they could rewrite the program easily. If they lost their understanding (say, if the team experienced 100% turnover), they would struggle to make sense of the code.