After reviewing millions of PRs, we've found the 11 that are dragging down your engineering team.

DevInterrupted's platform is a central hub for software developers and engineering managers, offering insights into developer productivity, team collaboration, and software engineering best practices. Through articles, podcasts, and community discussions, DevInterrupted offers insights into overcoming common challenges in software development, such as burnout, distractions, and communication barriers. Developers and managers can learn about fostering a positive work environment, improving team dynamics, and achieving sustainable productivity in software projects.

Dev Interrupted

The average cycle time for a piece of work (first commit to deployment) is 7 days. Half of all PRs are idle (e.g., no one is actively working on them) for at least 50% of their lifespan. Poorly crafted or mismanaged pull requests can spell disaster for productivity.

The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches)

The 4 Root Problems in Engineering Workflows

How are you solving the pull-request problem?

How Have Elite Engineering Teams Solved Toxic PRs? Download “The Continuous Merge Guide to Merge Standards: A Free Guide To The Merge Standards That Empower Policy-As-Code In Elite Orgs.”

Real talk: do you add “estimated review time” to your PRs? I kinda like the idea, but I never did that. Somehow it feels undoable (in teams with different seniorities/experiences)…

The estimated review time, I would call a bit over the top. But in my last project we hat to add a Deep or Shallow flag to our PRs. To give a hint to the reviewer if we just fixed/add minor stuff or we worked on deep shit and the reviewer had to put on a extra pair of glasses.

Most of these are easy fixes is your lead dev is open to a tiny bit of automation.

Super article. Needs 10 million upvotes.