Engineering-Process on Jake Worth

On commenting and approving pull requests

Wed, 22 Apr 2026 11:06:20 -0400

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.

Catastrophic Mistakes Are a Team Failure

Mon, 20 Apr 2026 12:11:33 -0400

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

Things I Check Before Opening a PR

Sat, 07 Feb 2026 14:58:34 -0500

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.

Running Great Refinement Meetings

Mon, 01 Dec 2025 11:18:17 -0500

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

A Kaizen for Knowledge Work

Wed, 16 Jul 2025 09:00:30 -0400

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.

Decoupling Design From Engineering

Thu, 29 Aug 2024 11:55:49 -0400

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.

Find Every Debugging Trail Marker

Mon, 17 Jun 2024 00:00:00 +0000

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.

How I Review Code, Part 2

Thu, 06 Jun 2024 00:00:00 +0000

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.

Why Great PRs Are Great: Pull Requests Templates

Mon, 14 Aug 2023 00:00:00 +0000

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?

Don't Ask for Advice; Ask for a Code Review

Wed, 09 Aug 2023 00:00:00 +0000

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.

How to Run an Agile Retrospective for Leaders

Wed, 15 Mar 2023 00:00:00 +0000

Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros.

Deliver a Great Standup Report as an Engineer

Wed, 09 Nov 2022 00:00:00 +0000

I’ve been lucky to have worked with some great engineers, and one thing that they tend to do exceptionally well is reporting about their work at meetings. Today I’d like to summarize what I think makes a great standup report.

Retros Need Action Items

Tue, 19 Jul 2022 00:00:00 +0000

Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these.

How I Review Code

Sun, 06 Mar 2022 00:00:00 +0000

Code reviews are important on many teams. Do them well, and your code ships quickly and safely. Do them poorly, and your code ships slowly and riskily. I try to contribute good code reviews. In this post, I’ll share my process.

Why I Don't Point Agile Bug Tickets

Mon, 07 Feb 2022 00:00:00 +0000

When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate.

How and Why to Squash Your Pull Request

Sun, 03 Jul 2016 00:00:00 +0000

Many pull requests go through a cycle: programmer opens pull request, maintainer gives feedback, programmer makes changes, repeat until ready to merge, maintainer merges. Prior to the merge, the pull request can be messy, full of reverts, fixups, and WIP commits. In the end, those commits are noise. We can tell a better story by squashing the branch.