How I think about engineering
The homepage has the short version. These are the principles I've shared with teams I've led.
Engineering is communication
Excellent software engineering depends on excellent communication. I believe in writing things down and in async cultures. A doc anyone can read later beats a conversation only the people in the room remember, and writing forces you to think the idea through.
This matters most for code. Someone will eventually need to know why a decision was made, and "ask whoever wrote it" doesn't scale. The reasoning belongs in the PR, the design doc, or a comment next to the code, where the next person can find it.
Build the right thing
The hard part of engineering is usually deciding what to build. The most technically complex solution is rarely the goal. Getting it right takes context: understanding what is actually needed, how you'll maintain it, and how you'll explain your decisions to the people who come after you.
Learn fast, and learn from every attempt
The best engineers are the ones who are best at learning. The faster you learn, the faster you improve and the more you can take on.
Learning fast depends on a good loop. More reps help, but I care more about getting as much as possible out of each attempt: know what you're trying to find out, see the result quickly, and understand why it came out that way before you try again.
Assume positive intent
I take people at their best. Part of my job is figuring out what each person is good at and how to work well with them. People make mistakes, and that's expected. We're all meatbags getting in the way of computers that would otherwise do exactly what we need.
Unblock yourself
Treat other people's time as expensive. I learned this early, working with a brilliant senior engineer who only had time for questions that were sharp and clearly worth it. When I'm stuck, I write the problem down, list what I could try, rank the options by effort and odds of success, and work through them. When I do ask for help, I bring what I tried, what I learned, and a specific question.
Some things deserve an immediate ask: a production outage, a hard block on someone else's work, or a real chance to learn from someone.
AI-native engineering
The profession is changing, and learning to build with AI is part of the job now. At ManageXR I pushed AI-native engineering across the company: introducing engineers to agentic tools, giving talks, pairing, and helping non-engineering teams use the same tools for their own work.
Agents need what people need, only more so: fast, reliable tests so they can check their own work, clear limits on what they're allowed to touch, and documentation the team updates when something goes wrong.