Pull Request templates are useful: they set the expectation for how much context PR authors should provide in the description.

This simplifies code reviews and helps the team ship code faster.

Here's the one used on my current team, for example. Nice and simple: The WHAT should be a brief summary of the change at the *product* level.

The WHY should describe the problem, and why the change solves it. It can also be used to justify the chosen approach.

Each team is different, but generally, these two sections are essential.

Recently spent a week in Miami at Dev Writer's Retreat. Lead by @swyx (the legend!), ~40 developers came together to grow our writing and blogging skills.

🧵 of a few takeaways:

🔑 Illustrate your ideas
🔑 Leverage constraints for volume
🔑 Build trust with public narratives 🔑 Illustrate your ideas.

As the saying goes, a picture is worth a thousand words. Visuals stick in your brain, and are easier to digest and share.

A lot of code reviewers got immediate, actionable value from this image on Twitter and LinkedIn:

https://twitter.com/curtiseinsmann/status/1592621165457027072

Generally, you shouldn't make product decisions as a consequence of engineering decisions.

Business features and tech stacks don't always integrate smoothly. This creates constraints — and software engineering is about overcoming these constraints with creativity. Often, creative solutions result in added complexity.

This complexity makes systems more difficult to maintain. Good engineers use abstractions to hide complexity behind a simple interface.

https://twitter.com/curtiseinsmann/status/1429815497068056582

A common mistake of developers new to a "tech lead" role: trying to perform every code review. They're concerned that something will break if they don't.

But reviewing every pull request isn't feasible, and doesn't scale.

What to do instead? Here's what I've learned: 1/8 Enhance your delivery systems outside of code review.

Strengthen your release pipelines with tests, monitoring and rollback. This will help to prevent, detect and mitigate defects. 2/8

Software engineers engage in code reviews daily.

But most developers can’t recognize a bad code review process. Even when they're right in the middle of one.

Thread: 3 signs of bad code reviews, and how your team can ship faster. 🧵 🚩 If code reviews make you, or other developers, anxious.

Likely, reviewers aren't prioritizing kindness. Or they're on a power trip, gatekeeping over minutiae.

Result? Deteriorating relationships.

I’ve authored over 550 Pull Requests at Amazon Web Services.

In the past year, I shipped 90% of my PRs in 1 revision. 5 years ago, it often took me 6+ revisions to address peer feedback.

Here’s my step-by-step process to author and ship a quality Pull Request. A thread: 1. I understand why fast PR cycles matter.

PR churn can cause delayed delivery.

It can block my teammates from being effective. If they have to review my PR through several revisions, they have less time to focus on their own tasks.

In 2014 I did a software engineer internship at Amazon.

It was no joke.

The goal: to earn a full-time offer. They told me I’d find out on the last day.

I’m now a team lead. The internship experience laid the foundation for my career success.

Time for a story. And lessons! 📝 I went into the internship feeling like an impostor.

I had strong leadership experience. But my Computer Science fundamentals (data structures, algorithms) weren’t great.

My university focus at @virginia_tech was hardware/embedded systems. Challenging, yes. CS-specific, no.

I’ve diagnosed and resolved hundreds of bugs in my 5 years at Amazon.

As a junior engineer, bug diagnosis in large scale software systems was challenging.

I wasn’t aware of a good thought process.

Here’s how I’m doing it. 🧵 👇 1️⃣ I understand why accurate root cause diagnosis matters.

Half baked resolutions allow problems to linger. These discreet flaws are easy to overlook by future developers.

Diagnosis is the first step towards fixing bugs, and keeping them fixed.

👇

From an Amazon tech lead: soft skills I’d tell my younger, jr software engineer self. 🧵 👇 1️⃣ Exude kindness.

The tech world is full of strong opinions. You may perceive people as mean. They’re not. They just want the best outcome.

Resist the temptation to become an unpleasant person. Radiate kindness while holding a high standard. You’ll go far.

👇

I’ve reviewed over 750 PR’s at AWS. As my team’s tech lead I provide insightful feedback and enforce a high code quality bar.

But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment.

Here’s how I review PR’s. 🧵 👇 1️⃣ I understand why code reviews matter.

They're an excellent coaching opportunity. Insightful feedback accelerates learning and growth.

Quality code strengthens readability and system understanding. This is a force multiplier for the team’s long term feature velocity.

👇

When I was a jr engineer at AWS my PR’s went through 100+ comments and 7+ revisions due to poor code quality. The friendly, helpful feedback helped me improve.

Now as a mid-level I tend to ship code in <= 2 revisions with minimal comments.

Here’s how I’m doing it. 🧵👇 1️⃣ I understand why code quality matters.

We read code 10x more than we write it. Our code must be understandable so our team can maintain and add features.

Poorly written code causes PR churn, which results in delayed delivery and can block other team members.

👇

My first ever Medium story got 22.5k views in its first 3 weeks.

What I did right ✅ and wrong ❌.

THREAD. 🧵 👇🏽 ✅ I had a story to tell.

I did something cool in real life. This is important.

I had a unique journey at Amazon. I overcame my technical incompetency to achieve success.

I wanted to help people overcome similar challenges.