I have collected a group of mentors over the years. I call on them frequently to talk through tough problems. I think I’m better at my job because of this regular, impartial outside feedback. I’d wish this for everyone! In this post, I’ll try to reverse-engineer the path I took to get here. ...

An engineering technique I recommend: when you sign up for any service, even on a side project that’s just getting off the ground, create an email group called dev@<your-domain.com> that forwards to you and any other technologists, and use that email to sign up. ...

Here’s my simple framework for answering questions on Stack Overflow that reach and help people and earn reputation. ...

Hard-coded test expectations have many benefits that I’ll explore in this post. ...

When possible, I prefer to use the presence of data to represent a boolean, rather than a boolean itself. ...

An idea I find useful as an individual contributor is starting my consulting with this phrase: “I think that…”. The idea is to let your arguments stand on their own, rather than appealing to your experience or other authorities. ...

Me: Hey, I’m experiencing an issue with your software. Here’s a detailed bug report. SAAS Engineer: What you’re describing isn’t possible. Narrator: But it was possible. This is a frustrating, unproductive snippet of a conversation I’ve had a few times in my career. What can we learn? Treat bug reports like gold. ...

What should you focus on at the beginning of your programming career? My unflashy answer is: being really good at programming. ...

The import statements at the top of a JavaScript component file can be a confusing, duplicative, churning mess. Is there a way to organize them that makes sense and scales? In this post, I’d like to share the way I handle this detail. ...

When I review code, I sometimes request that refactoring changes be removed. Even when I think the changes are are objective improvements, and even when they support my personal preferences. My reasoning? Refactors are not free. ...