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:
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.
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
Document code review processes.
Team members should be aware of the expected size, scope and structure for each PR. Add automated checks for testing and approval. 3/8
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.
2. I understand that occasional PR churn is inevitable.
1-revision PRs won't always happen. Humans make mistakes. Peers have unique insights. That’s why code reviews exist.
Particularly, early-career developers at {BigCompany} often need coaching. Even the best programmers.