Career

After more than a decade in the field as an engineering leader and hands-on practitioner, I’m thrilled to be offering a consulting service. I am a strong contributor in three areas: technical consulting, mentorship, and workshops & teaching. Technical consulting I love digging into tough problems in greenfield and legacy code. A few things I’m good at: Raising code quality (tooling, testing, monitoring & observability, building CI/CD pipelines) Big scary bugs Process improvement Internal/external communication and meeting/ceremony refinement Refactoring Complex feature building Requirements gathering and story-carding Pair programming, code reviews, and hands-on coaching Technical writing and documentation modernization Mentorship I have mentored dozens of software engineers. I love listening and helping people get better! My mentees are successful software engineers across the industry. I can meet on your schedule and cadence. ...

Perhaps you’ve heard that career adage: “It’s not what you know, it’s who you know.” I’ve found this to be true: most of my software engineering opportunities came from a referral inside the company. But what if you don’t know anybody? I’ll start by challenging the premise: you probably know somebody. An acquaintance who works at a company with programmers. A local business owner with a website. A cousin in tech. Think hard! When I do this, I usually discover someone I can lean on. ...

Always leave something behind. If you find something interesting, leave a trace that you were there. This is a little thing that over time leads to a friendlier, more humane internet. Here are a few examples. Blog post that helped you Imagine you’re reading a blog post and you find it helpful. Or, you agree with it, but find one part of the argument lacking. Before moving on, leave a comment! ...

How do I “get up to speed” in a new codebase? Changing it. After trying almost every alternative— reading code, docs, tickets, metrics— I’ve found nothing that teaches a system faster than shipping a small change. Note: I wrote something similar to this a few years ago, which you can read here: Stop Studying, Start Building. That advice was for people learning to code; this is for starting on a new project, which is something you’ll do again and again a programmer. It’s worth trying to do well. ...

If I had to start over as a person who wanted to become a professional programmer, in 2026, what would I do? I wrote about this before, in 2015, and am here in the present to report: a lot has changed. I’d skip my old post, and read this one instead. It’s the simplest, most viable advice I can give today. I’m writing for someone who was like me a decade ago. You are interested in programming as a profession, have little or no programming experience, and you aren’t sure what direction to go. ...

Eight years ago I wrote a post called You Should Blog. In it, I made an argument that I still believe in: public, professional writing is something every engineer should try. Today, I want to share why I write, and have for over a decade. It’s made me better The first reason is that over time, I think it’s made me a better programmer. To give you an example, here’s an opinion I hold, and how writing helped me solidify it: ...

Here’s my annual review covering 2024. Work Big news: the software portal I’d been building for over a year launched! It was a ton of work: ups, downs, and updating caniuse-lite. We defied escape velocity and launched. I was proud of my team and my growth in achieving this milestone. Soon afterward, I got a new job and got promoted! I’m enjoying the challenge. I’ve learned that I’m happiest when being pushed and working on tough problems. I’m grateful for James Stanier’s book Become an Effective Software Engineering Manager, which I bookmarked liberally. ...

This post is about how to write software well. It was inspired by this post with a similar title. Read it and write yours. These ideas aren’t advice but rather notes about how I do my best work. If you’re new, some of these ideas might seem obvious, but they get harder as you progress, or your understanding of them deepens, or you’ll encounter engineers who embody them in surprising ways. ...

I was the third engineer hired by my company, not counting our technical co-founder. I like that position, and it seems to play to my strengths. Who Is the Third Engineer? Who is the third engineer? Looking at the startup hiring process, I’ve noticed a pattern. The first engineer is usually a trusted senior that the founders know. The second engineer is the same, or a referral from the first engineer. ...

Our industry has a concept of “10x engineers”, individual contributors who have the impact of ten colleagues. How can you become one? I’ll try to answer that in this post. But first, here’s the price of admission: you first have to be both fast and competent. And that’s not enough. What’s fast? Reducing waste in every part of your development process. Cutting to the bone the time it takes to type, save and share your work, communicate, and hack your way to something good enough to ship. “Fast” and “great” are tightly correlated in this field. ...