“What did you do this week?” I’ve written a weekly summary for myself and my teams for years. It helps me think through my work and shows people what I’m working on. In this post, I’ll explain how I use this tool. ...

Here’s a technique I’ve used on launches: instead of a big scary waterfall, or, in tandem with a phased release, let customers opt into a new feature. ...

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. ...