My philosophy of web engineering

For nearly two decades, I've developed a unique philosophy which drives my engineering practice and helps me to better serve my clients.

If at all possible, I devote my time and attention to one client at a time. This ensures you always get my best work, and you know I'm not spreading myself thin.

I start with asking why, way before I ever ask what or how. Software is built to serve its users, and understanding their needs ahead of building anything is imperative to building what they actually need. Often times, a more expensive, complicated solution can be replaced with a simpler one if all tradeoffs are considered.

When building a new software feature, I always work from the user's point of interaction inward. This ensures that the user—not the engineering—is the primary consideration. Often times, engineers will solve an internal problem first, which can lead to solving the wrong problem. Keeping the focus on the user's experience leads to better outcomes for everyone.

I remain humble. I don't pretend to know everything about technology, the users, or the product. I'm not afraid to ask for clarification, but only after exhausting my own inner resources in the pursuit of a solution. I enjoy surrounding myself with people who have different skillsets of my own, because that's how you build great things.

My philosophy of automated testing is pragmatic and targeted. Total test coverage is a false metric because it implies that every path of execution is equally as valuable to the end user. Instead, I focus on testing the most valuable paths first, and use testing as a catalyst for building new features and bolstering against regressions.

I document as I go. The beauty of working on a remote team is that it encourages consistent documentation in order to keep everyone up to date. I write self-documenting code, narrate my thought processes in tickets, and write concise commit messages which convey both what changed and why.

Solving problems creatively necessitates taking regular breaks and having time to recharge. Because of this, I rarely commit more than 25 hours per week to billable work. I've learned that any hours beyond that will be subject to diminishing returns. I want to give you my best, so I make sure to nourish myself so I can come back to your project with a clear mind and sharp skills.

Does my philosophy of engineering resonate with you? Contact me for a free fifteen minute consultation.

Go back to my engineering page