Race Condition

A Blog by Josh Adams

Blog Speaking About

High-Quality Pull-Request Descriptions

Much Benefit 05 Oct 2025

One of the primary duties of a software developer is enhancing and fixing existing codebases. We do this by raising1 pull requests (PRs)2, getting them approved, and merging3 them to the codebase. I have been performing this duty for the entirety of my fifteen-year career as a software developer, and I’ve amassed a toolkit for this process. One tool is raising error-free PRs. I wrote about that here. The post you are reading is about another tool: writing a high-quality PR description.4 The tips in this post, if adopted, will help you get PRs approved more quickly, spark joy in your PR-reviewer coworkers, and facilitate debugging far into the future.

My target audience is primarily software developers. But non-developers who are curious about what we do might enjoy this post. Endnotes following it define terms that are likely unfamiliar to the developer-curious.

  1. When a software developer working on a team would like to add new code to a codebase or change code already in the codebase, the software developer proposes this change to other members of the team by “raising a pull request”. The pull request consists of the proposed changes and additions. Members of the team review the pull request and sometimes suggest changes. The raiser implements or responds to suggestions. Eventually, reviewers approve the changes, and they enter the codebase. The term “raiser” is present in my idiolect. “Author” is the usual term for the person who create a pull request. ↩

  2. “Pull request” is often abbreviated “PR”. ↩

  3. The act of incorporating changes in a PR into a codebase is called merging. ↩

  4. PR review typically happens in a UI provided by GitHub. Some code lives in “repositories” hosted by Microsoft in “public” GitHub. Some companies host their own GitHub instances. Some companies use similar solutions like GitLab. PRs almost always have descriptions written by PR-raisers. Those are the subject of this post. ↩

Continue…

Live-Coding Exercises

Non-Obvious Tips for Preparation and Execution 08 May 2025

One of the most-read posts on this blog is this one about typical iOS take-home coding exercises. The post has 3,797 views at time of writing, and several readers have privately thanked me for writing it. But, in my experience, the application process for many companies involves not a take-home coding exercise but rather a live-coding exercise. The candidate typically has forty-five minutes to implement an app from scratch that is similar to the app described in the post mentioned above but without unit tests or dependency injection.

The live-coding exercise is a different beast. Much of the knowledge required for a take-home coding exercise is applicable to a live-coding exercise, but the extreme time constraint of a live-coding exercise means that success is unlikely without extreme practice, preparation, and time-saving. Worse, the competitiveness of the job market means that, even if you complete 80% of the requirements of a live-coding exercise, you will be rejected in favor of another candidate who completes 100%.

In this post, I describe practice, preparation, and execution that make success in a live-coding exercise more likely. In an accompanying YouTube video, I apply this knowledge and complete a live-coding exercise within forty-five minutes.

This post is not about preparing for and succeeding in data-structure-and-algorithm interviews. Learning materials for those interviews are available elsewhere.

Continue…

Introducing iOSExpert

Don't just crack the iOS interview. Crush it! 05 Mar 2024

Loyal readers of this blog may have noticed a decrease in post frequency since January 2023. The reason for this decrease is that I spent most of 2023 creating a video course, iOSExpert. This post describes iOSExpert and presents some learnings from the creation process.

Continue…