Naur's essay reminds us that programming is fundamentally a human intellectual activity. The real product of programming isn't the code--it's the theory, the understanding, the mental model that gives the system coherence.

***Appreciation is your best tool for getting people motivated and bringing the best version of themselves***. At Vine, I'd try to send at least one note each week focused on expressing my appreciation. We also let anyone send anyone else on the team "shmoney" -- aka props that the entire team would see, along with a $100 gift card.

It is impossible to reduce the probability of a fault to zero; therefore it is usually best to design fault-tolerance mechanisms that prevent faults from causing failures.

Good documentation helps everyone stay aligned: your team, new contributors, stakeholders, and yes, even AI coding agents (docs make great context for any AI model, after all). The clearer your docs, the more effective AI tools like Copilot can be when generating code, tests, or summaries that rely on understanding your project's structure.

A thoughtful pull request is a signal of craftsmanship. It builds trust with your team, strengthens your communication skills, and gives Copilot better context to support you going forward. That's a win for you, your team, and your future self.

In 1985, computer scientist Peter Naur wrote a prescient essay called *Programming as Theory Building* that feels more relevant today than ever. As we watch junior developers reflexively accept LLM-generated code they don't understand, and see codebases balloon with theoretically orphaned implementations, Naur's central thesis becomes crystal clear: **a program is not its source code**.

"Psychological safety allows for moderate risk-taking, speaking your mind, creativity, and sticking your neck out without fear of having it cut off--just the types of behavior that lead to market breakthroughs" (Laura Delizonna, Stanford University).

Clever engineers write clever code. Exceptional engineers write simple code. That's because most of the time, simple is enough. And simple is more maintainable than complex. Sometimes it *does* matter to get things right, but knowing the difference is what separates the best from the rest.