Early in my career, I wrote a blog post about how I saw myself as a technician.

My job, I thought, was to build what I was asked to build. I didn’t need to worry too much about why something was being built or what problem it was really solving. That wasn’t my role; rather, I was there to implement, not to ask questions.

Someone commented on that post and challenged the idea directly. He suggested that it actually was my responsibility to ask why. That understanding the purpose behind the work would make me a better developer, make the systems I built more useful, and ultimately serve the people relying on them more effectively.

He was right.

That moment reshaped how I’ve approached my work ever since. It shifted me from seeing myself as someone who simply executes tasks to someone who takes responsibility for outcomes. Not just whether something works, but whether it makes sense for the people who have to use it, maintain it, and live with it over time.

That way of thinking now shows up everywhere in how I build: the tools that I use, how I structure systems, how I design editing experiences, how I think about accessibility, and how I approach long-term maintainability for the projects I build.

More specifically, it shapes how I interact with my clients - even before they become my clients. Knowing the why behind the project dictates everything that follows.

So I wonder: when was the last time you asked why a system you’re building (or using) exists in its current form. What would you do differently, if you had the opportunity?