The Pull Request: Your Most Underutilized Career Growth Tool

I've reviewed over 3,000 pull requests in my career. The difference between engineers who grow quickly and those who plateau isn't their technical ability—it's how they use the PR as a communication tool. Most engineers write PRs like they're filing paperwork. Senior engineers write PRs like they're building a case, teaching a concept, and marketing their work simultaneously. Your PR is not just a code diff. It's your most frequent opportunity to demonstrate judgment, communication skills, and technical leadership.

The PR Description is Your Executive Summary

A PR description should answer three questions before anyone looks at the code: Why does this change matter? What approach did you take and why? What should reviewers focus on? Junior engineers write "Fixed bug in checkout flow." Senior engineers write context that makes reviewers smarter. Here's the template I use for every non-trivial PR:

## Problem
Users were experiencing checkout failures when applying multiple discount codes
simultaneously. Error rate spiked to 12% during our Black Friday sale.
Datadog trace: [link]

## Solution
Refactored discount calculation to use a transaction with row-level locking
instead of optimistic locking. This prevents race conditions when multiple
discount validations happen concurrently.

### Why not optimistic locking?
- Retry logic was causing UX issues (spinner hell)
- High contention during sales made conflicts frequent (40% retry rate)
- Transaction overhead is negligible for this code path (<5ms p99)

## Testing
- Added integration test simulating concurrent discount applications
- Load tested with 100 concurrent users applying discounts
- Verified in staging with production traffic replay

## Rollout Plan
Feature flag: `checkout_transactional_discounts`
- 10% for 24h, monitoring error rates
- 50% if metrics look good
- 100% after 72h

## Review Focus
- Transaction isolation level choice (line 145)
- Timeout handling in DiscountService (line 203)

Use PR Comments to Pre-empt Questions

The best PRs have inline comments from the author explaining non-obvious decisions. This isn't about apologizing for complexity—it's about teaching and building trust. When I see a complex algorithm or an unusual pattern, I add a comment before anyone asks. This demonstrates self-awareness and saves review cycles.

export class RateLimiter {
  private buckets = new Map<string, TokenBucket>();

  async checkLimit(userId: string): Promise<boolean> {
    const bucket = this.getBucket(userId);
    
    // Note: Using token bucket instead of sliding window here.
    // Sliding window would be more accurate, but token bucket
    // gives us burst tolerance which product wants for the
    // "rapid fire" feature. See RFC-024 for full analysis.
    if (bucket.tokens < 1) {
      await this.metrics.increment('rate_limit.exceeded', {
        user_id: userId
      });
      return false;
    }

    bucket.consume(1);
    return true;
  }

  private getBucket(userId: string): TokenBucket {
    if (!this.buckets.has(userId)) {
      // Buckets are never cleaned up in this implementation.
      // This is intentional: memory growth is ~50KB per 1000 users,
      // and we have a separate cleanup job that runs hourly.
      // Tried cleaning up inline but it caused p99 latency spikes.
      this.buckets.set(userId, new TokenBucket({
        capacity: 100,
        refillRate: 10 // tokens per second
      }));
    }
    return this.buckets.get(userId)!;
  }
}

Small PRs Are a Career Multiplier

I used to think big PRs demonstrated that I could handle complex work. They actually demonstrated that I couldn't break down problems. Now I aim for PRs under 400 lines. When I'm building a large feature, I break it into a sequence of small, independently reviewable PRs. Each PR should be complete, correct, and safe to merge—even if the full feature isn't done yet.

• PR 1: Add database schema and migrations (no application code)
• PR 2: Add data access layer with tests (feature flag returns early)
• PR 3: Add business logic layer (still behind feature flag)
• PR 4: Add API endpoints (feature flag controls exposure)
• PR 5: Add frontend UI (feature flag controls visibility)
• PR 6: Enable feature flag for 10% of users

Small PRs get reviewed faster, have fewer bugs, and are easier to revert. More importantly, they create a paper trail that shows you can execute. When promotion time comes, your manager can point to 30 merged PRs over two months instead of 3 giant ones. Velocity is visible.

Responding to Review Comments is a Test

How you respond to PR feedback reveals your maturity more than the code itself. I've seen brilliant engineers plateau because they get defensive in PR comments. When someone suggests a change, you have three options: accept it, discuss it, or explain why you're declining it. All three are valid. What's not valid is going silent or getting snippy.

// Reviewer: "Why not use a Set instead of an array here?"

// ❌ Defensive response:
// "It doesn't matter for this use case."

// ❌ Silent response:
// [Makes the change without commenting]

// ✅ Good response:
// "Good catch! Changed to Set since we're doing frequent lookups."

// ✅ Also good:
// "I considered Set, but we need to preserve insertion order for the
// audit log, and we're not doing lookups in this code path. The array
// is iterated exactly once. Happy to add a comment explaining this?"

// ✅ Also good:
// "Great question. I'm going to keep the array for now because this
// code is hot path and Set allocation showed up in profiling (see
// screenshot). But you're right that Set is more semantically correct.
// Filed TECH-456 to revisit this with a benchmark."

Your PR Velocity is Your Brand

In every company I've worked at, there are engineers who consistently get their PRs merged quickly, and engineers whose PRs sit for days. The difference is rarely the quality of the code—it's the quality of the PR itself. When you write clear descriptions, add helpful comments, keep the scope tight, and respond promptly to feedback, reviewers prioritize your PRs. They know reviewing your work will be easy and educational. This compounds over time. Fast PR velocity means you ship more, learn more, and become more visible. Slow PR velocity means you're always context-switching and fighting to get attention. Your PR habits determine which category you fall into. Treat every PR like it's a presentation to the entire engineering team, because it is.