Method
The perspective stays. The tools can change.
Software engineering, to me, is a way of thinking — not a fixed set of tools. I can pick up a language, framework, or platform when the problem needs it. What matters is how I look at the problem.
Give me an ambiguous problem. I'll understand it, break it into pieces, and find a way forward. I'm not waiting on a preferred stack to exist first.
- 01
Understand
What is actually happening?
- 02
Break down
Separate the pieces that matter.
- 03
Find a way forward
I can pick up the tools the problem needs. The stack is not the starting point.
- 04
Build
The simplest thing that solves the real requirement.
- 05
Test
Watch behavior, data, and failure modes.
- 06
Improve
Cut waiting. Make repeated work reusable.
That looks like this in practice
When the work is just tedious
Sending cold emails by hand was irritating. I built ApplyFlow so the repetitive part of outreach could run without sitting in the inbox. That problem used Go, AWS, PostgreSQL, React, and a worker. The next one might not. I can pick up what it needs.
When the same check keeps happening by hand
Data-sync was being tested with VBA and spreadsheets. I started with reusable templates, then built a more effective comparison tool, then templates for that process too. I didn't replace a whole system. I noticed repetition and made the improvement reusable.
When the problem isn't the code
Tasks coming from other teams were often unclear. The gap was the task description, not the implementation. I introduced a structured format so the required information showed up first. Sometimes the best engineering improvement is changing the process around the code.
Curious what I ship when the brief is mine?
Want the rest of the picture?