Engineering-Process

After reviewing a lot of pull requests, I’ve settled on a simple default: if my comments are all nitpicks, suggestions, questions, or non-blocking issues, I leave them and approve the PR at the same time. ...

If people can make catastrophic mistakes on your team, the process is broken. ...

What is a programmer but a series of PRs (pull requests)? I optimize PRs to introduce the best code I can, be easy to review, and document my work so I can make sense of it in the future. Here are some things I always check before opening a PR. ...

This year I’ve run over 25 Scrum refinement meetings; here’s what I’ve learned. ...

Confluence was messy. Our documentation felt outdated, hard to navigate, and unreliable. Rather than scrap everything and start over, I decided to try something different: a Kaizen. ...

Often, when you work as an engineer on a small team, you don’t have dedicated designers on staff. How can you deliver beautiful, intuitive software without designers? Here’s a trick that helps me: decoupling my design work from my engineering work. ...

If you’ve ever watched me debug, you might think I’m moving slowly. That’s because I try hard to find every marker on the debugging trail. I believe this is one of the most valuable skills in debugging. ...

Reviewing code is tricky. When I’m doing it, I’m trying to achieve a few things at once. In this post, I’d like to document the ways I try to add value via code reviews. ...

Have you ever seen a pull request that seems to completely explain itself? It’s a real artifact. I don’t know the project, yet I understand it. How can we get results like this on every pull request, from every developer on the team, every time? ...

Here’s some advice about programming I’ve found useful: “Don’t ask for advice; ask for a code review.” In this post, I’d like to explore what I think this adage means. ...