Principles I Return To

These are not rules I have mastered. They are ideas I have gathered from mentors, colleagues, mistakes, and experience. I want to remember them when the right choice is not obvious.

Understand deeply, then make it tangible. Take time to understand the real problem, then test that understanding by turning it into something concrete. An early mentor taught me that thinking and building are not separate steps: each one makes the other clearer.
Measure what matters, but do not mistake measurement for meaning. Data can reveal patterns and challenge assumptions, but it cannot make every decision for us. Some of the things that matter most, such as trust, respect, love, and belonging, cannot be reduced to numbers.
Leave things better than you found them. Improve the code, documentation, process, or conversation so the next person has an easier path than you did.
Build for people as they are, not as you expect them to be. A mentor once reminded me that people are at different stages and bring different strengths. Clear expectations matter, but expecting everyone to think, work, or grow in the same way often leads to disappointment instead of understanding.
Prefer clarity over cleverness. Whether in code, writing, or conversation, something others can understand and build upon is usually more valuable than something designed to impress.
Optimize for learning, not merely output. Being busy can produce activity without producing progress. Reflection, experimentation, and adjustment help turn effort into understanding.
Question assumptions early. Many difficult problems become simpler once we examine what we have quietly accepted as true.

I expect these principles to change as I do. For now, they give me a place to return to: understand first, stay open to evidence, make room for people, and leave the next step a little clearer.