A design doc before the hard-to-reverse change
Anything touching schema, auth, or a public interface gets written down first. Ten minutes of writing is cheaper than a migration.
[ 00 / 02 ] · Process
How I approach engineering work, from the first question to what ships and what happens to it after.
- 05
- 01 · Principles
- 04
- 02 · Practices
[ 01 / 02 ]Principles5 steps
I don't follow a rigid process. I follow the problem and let context shape the approach.
- Why
Understand the problem first
Before writing a single line of code, I make sure I actually understand what needs to happen and why. Talk to whoever owns the problem, dig into the data, map out the edges.
- Ask the questions nobody else is asking
- Identify constraints early. They shape the solution
- Separate the stated request from the actual requirement
- How
Research before building
I'm a researcher by nature. If I don't know something, I find the answer. I look at how others have solved similar problems, evaluate the tradeoffs, and pick the right tool.
- Evaluate existing solutions before inventing one
- Prototype the risky parts first
- Let the tech serve the goal, not the other way around
- Build
Build with intention
Every decision should be traceable to a reason. Architecture, stack choices, even naming. Intentionality compounds over time into systems that are easy to maintain and extend.
- Write code that explains itself
- Optimize for the team, not just the task
- Ship incrementally. Small wins build momentum
- Think
Think beyond the code
Understanding the business context changes everything. I translate technical complexity into clear direction and make sure the work connects to real outcomes.
- Bridge the gap between technical and non-technical
- Use data to inform decisions, not just validate them
- Keep the end user in the room, even when they're not
- Ship
Iterate and refine
Done is better than perfect, but done doesn't mean finished. Ship it, measure it, learn from it, and make it better. The best work comes from cycles, not sprints.
- Get feedback early and often
- Measure what matters, not everything
- Treat every system as a foundation for the next
[ 02 / 02 ]In practice
In practice
Small, reviewable pull requests
One concern per PR. Easier to review, easier to revert, and easier to understand when someone runs git blame on it a year from now.
Tests that ship with the change
Written alongside the code rather than bolted on afterward. They document what the code is supposed to do as much as they catch regressions.
Docs and runbooks that outlive me
READMEs, architecture decisions, and on-call notes, so the system keeps working when I am not the one holding it.
Have a problem worth
working through?