There’s a habit in engineering culture of treating product sense as someone else’s department. You get a ticket, you implement the ticket, you move on. I’ve never believed that split serves anyone - least of all the person using the thing we build.
Software is for people
Every technical decision eventually reaches a human being. A slow query is someone waiting. A confusing form is someone giving up. An over-engineered abstraction is a teammate lost in your cleverness six months from now. When I build, I keep the person at the end of the line in view, because that’s who the work is actually for.
Ask “what is this really for” before “how do I build it”
The most expensive code is the code that perfectly solves the wrong problem. Before I design an API or a schema, I want to understand the job the user is trying to get done. Often the best engineering outcome is building less - a smaller surface that does the real job cleanly, instead of a big one that does an imagined job impressively.
The backend shapes the experience
People think of UX as a frontend concern. It isn’t. Latency, consistency, error messages, what happens when something’s offline - these are experience decisions made in the backend. A honest, fast, predictable system feels good to use even before anyone styles it. I design the data and services with that felt experience in mind.
Taste is a skill you can build
Caring how something feels isn’t a personality trait you’re born with. It’s attention, practiced. Use your own software. Notice friction. Ask why a flow annoyed you and whether your work does the same thing to someone else. Over time that attention compounds into judgment - the kind that makes the difference between software that works and software people actually like.
Engineering and product aren’t two jobs. They’re one job, seen from two sides. I try to hold both.