I like problems that need some thought.
Especially the ones where the first solution turns out not to be the right one.
Start with what needs to happen
Before choosing tools or writing code, I want to understand the job. What is supposed to happen? What happens when it doesn't? Who notices? And how will we know we got it right?
Those questions sound basic. They also have a habit of uncovering the interesting parts.
Keep the design understandable
I'm not against complexity when it's earned. I am against adding it because a clever solution looked fun on a whiteboard. Somebody, including future me, will have to maintain this thing.
Expect systems to disagree
Integrations are where assumptions meet reality. Timeouts, retries, missing data, strange responses, partial failures: I've learned to give those details the attention they deserve.
Don't confuse “running” with “working”
A dashboard can be green while a customer still can't complete a transaction. That's part of what led me to build BRS: I wanted a practical way to verify the outcome, not just the infrastructure.
AI is a tool. Judgment is still the job.
I use AI-assisted engineering to explore approaches, implement ideas, test assumptions, and move faster. But generated code isn't the same thing as a sound design, and a convincing answer isn't the same thing as a verified result.
I like what these tools make possible. I also think an experienced engineer has to remain responsible for what ships.