General
- How do you make an awesome team? • Julia Evans 📖
- Kind Engineering: How To Engineer Kindness • Evan Smith 📖
- A template for writing a team charter • Mike Crittenden 📖
Discussing & Deciding
- Planning vs prototyping
- Gate-keeping vs green-lighting
- I find mutual curiosity and green-lighting gets us to better decisions faster than exhausting debate and consensus (which may never come when trying to be too certain about outcomes in advance)
- Give people the benefit of the doubt that they are acting in good faith and are trying to do what they think is best for the team
- Just because I don’t immediately understand why someone is suggesting something doesn’t mean it’s a bad idea
- Instead of assuming their idea is bad or slowing them down with questions, give them some leeway to prototype their idea and take it from there
- A lot of meeting time gets wasted on people trying to convince each other of their ideas in the abstract
- Writing some code and demoing it is much more fun and efficient and mutually respectful and encouraging
- In the time it takes to debate an idea, you could have prototyped multiple options and learned a lot more
- I like the silent meeting pattern where team starts the meeting by reading a shared document and adding their thoughts and questions to it before starting the verbal discussion
- A tiny guide to Sprint Planning in Scrum – Mike Crittenden • Along with some common anti-patterns • Mike Crittenden 📖
- Leading Successful Product Teams • Ariel Salminen 📖
- Two approaches to win an argument as a software engineer • Nicholas C. Zakas 📖
- The Zero Bug Policy • Kevin Sookocheff 📖
Collaborating Asynchronously
- Managing your interrupt rate as a tech lead, part 1: You get more of what you reward • Nicholas C. Zakas 📖
Many of the interruptions that fill up your day aren’t necessary. Here’s how to start taming your interrupt rate.
- Managing your interrupt rate as a tech lead, part 2: Time blocking • Nicholas C. Zakas 📖
Your calendar is a place where you should be in control and not be at the whims of others who send you invites.
- Managing your interrupt rate as a tech lead, part 3: Office hours and appointment blocks • Nicholas C. Zakas 📖
You can more easily eliminate interruptions when you create a specific time for them.
- Fewer meetings means you have to show more impact • Mike Crittenden 📖
If you start declining more meetings, the onus is on you to prove that it’s worth it.
Collaborating Remotely
- Working remotely, 4 years in • Julia Evans 📖
Collaborating on Code
- Lean software development • Wikipedia 📖
- Swarming: One-Piece Continuous Flow • Old Published Patterns 📖
- 5 things that are typically confused for productivity • Jason Yip
Pull requests
Authoring well
- Write small PRs!
- Why?
- your teammates will review them far more quickly than they’ll review a large PR
- think of how you feel as a reviewer!
- large PRs are daunting and time-consuming
- everyone has lots of their own work to do and no one wants to switch contexts for long
- How?
- break what you’re doing into pieces
- use feature flags if the pieces don’t make sense until they’re all there
- resist the urge to include unrelated changes as you think of them (“while I’m in this file…”)
- Why?
- A Guide to Perfecting Pull Requests • Kara Luton 📖
- The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches) • Dev Interrupted 📖
Reviewing well
- Those pesky pull request reviews • Jessitron 📖
- Figure out a good workflow for reviewing locally via keyboard only with Lazygit and/or VS Code?
- To avoid all the mouse/trackpad use involved in using the GitHub UI
- sindrets/diffview.nvim • Neovim plugin for viewing diffs and resolving merge conflicts 🛠️
:DiffviewOpen origin/main…topic/branch
- [Question] Is there a way to track down the diffs only for a PR · Issue · sindrets/diffview.nvim • GitHub 📖
- STOP Nit Picking In Code Reviews • The Primeagen 📺
Teaching & Mentoring
- “Ask if you have questions” isn’t enough • Julia Evans 📖
- How to answer questions in a helpful way • Julia Evans 📖
Providing useful feedback
- be specific
- use SBI: situation, behavior, impact
- leverage the values
- be bold as a reviewer!
- show that I care
- help them learn so they can deliver
- be balanced (everyone can grow, your feedback helps with that)
- reference their leveling guide for ideas (if I can’t come up with any)
- spend < 15 mins writing
- result should take < 3 to read
- write just enough to land the point
- if any of this feedback will be a surprise, consider letting them know personally first
Links:
- How We Work: Feedback • Plex Engineering 📖
- Writing performance reviews with positive constructive feedback • Julia Evans 📖
- When your coworker does great work, tell their manager • Julia Evans 📖
- Good feedback is pokey • Mike Crittenden 📖
- 5 second feedback • Mike Crittenden 📖
Requesting useful feedback
- Who to ask for 360 feedback:
- Choose some people who will celebrate me
- Choose others who will uncover areas where I can grow
- How to ask:
- Provide context about why I’m requesting them (to help guide their feedback)
- How to take negative feedback well • Mike Crittenden 📖
Pair and Mob Programming
- Trying to understand the pros and cons of pairing and mobbing
- I’ve almost always written software on my own and then shared it with the team to be reviewed
- But I’m currently on a team with several members who really enjoy mobbing, so I’m exploring the idea
- My initial reservations:
- This can’t possibly be as productive as working asynchronously on different tasks
- I’m going to look silly if I’m asked to do something I’ve never done before without the chance to prepare a bit
- It will be draining to be “on” for hours at a time on a never-ending Zoom call instead of being able to switch tasks whenever a change would be refreshing
- Focus on WHY we’re pairing:
- To build a feature?
- To teach something?
- To debug something?
When to pair/mob
- To teach (i.e. explicitly transfer knowledge from one teammate to another)
- To debug an urgent issue
Other suggestions from teammates:
- To receive earlier feedback from future PR reviewers (to make those PR reviews easier)
- Supported by The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches)
- Should pairers really act as each others’ PR reviewers? Aren’t they coauthurs?
Other potential reasons to mob, specifically (not just pair):
- To minimize WIP at the team level by reducing the number of active workstreams to one:
- The hidden evils of high WIP • Mike Crittenden 📖
Limiting team WIP is just as important as limiting individual WIP.
- The five stages of team focus • Mike Crittenden 📖
- House painting and team focus • Mike Crittenden 📖
- The hidden evils of high WIP • Mike Crittenden 📖
- To eliminate PR reviews and all the coordination pain they bring:
- Those pesky pull request reviews • Jessitron 📖
Risks
- poor return on total engineer time
- e.g. if two engineers casually watch another engineer do something one engineer could have done just as (or more) quickly on their own, a task just cost 3x the engineering hours it needed to
- That may be true for the coding phase, but doesn’t account for the time saved by making the PR review phase faster (or eliminating it entirely)
- if both other engineers now know how to independently do that thing in the future, great
- but if they were passively observing, they may forget much of what they saw given that active doing leads to better learning retention than passive absorbing
- how to mitigate:
- observers should update team docs in real time
- if you notice you are likely going to be largely observing because this is a knowledge transfer pairing session where you are receiving the knowledge, plan to document what you learn as you go!
- start a new document for this workflow before the doer gets going
- add the doers steps to a numbered “how to” list
- if issues arise, add them to a “troubleshooting” section
- if solutions to those issues are discovered, record them
- have the doer review the doc before the session ends to confirm your instructions make sense and fill in any gaps (given that you’re new to the workflow and they understand it more deeply)
- how to mitigate:
- e.g. if two engineers casually watch another engineer do something one engineer could have done just as (or more) quickly on their own, a task just cost 3x the engineering hours it needed to
When not to pair/mob
- No knowledge needs to be transferred
- The work is not urgent
- Working asynchronously would be more efficient for this task
- A dependency on pairing is preventing a teammate from learning to navigate problems and complete tasks independently
- Conscious pairing often drifts into aimlessly hanging out
- Passive participants are using pairing as cover for not working
Regarding transferring knowledge, remember that knowledge transferred asynchronously (e.g. by writing a document or recording a screencast) can be shared with more people, will last longer, and can likely be consumed more quickly than knowledge transferred one-on-one in a pairing session.
The potential benefit of investing the time to transfer knowledge 1:1 is that the knowledge can be tailored for that person, who can ask questions immediately. But the cost in terms of time and knowledge erosion over time is high, so if effectiveness is the goal, always consider recording the knowledge and sharing it widely rather than verbally sharing it with one person in a private forum.
(See Scott Hanselman and Kelsey Hightower’s talks about scaling yourself.)
Links:
- Mob Programming: A Whole Team Approach • Woody Zuill 📺
- The five stages of team focus • Minimize waste by working together on the same thing • Mike Crittenden 📖
- House painting and team focus • Work together instead of splitting up • Mike Crittenden 📖
- Pair programming • Julia Evans 📖
- Pair programming is amazing! Except… when it’s not • Julia Evans 📖
A few people said that they like working together, but not for producing code. It’s totally okay to use pairing in specific ways (for teaching or for debugging), and not for other things.
- Tuple’s Pair Programming Guide • Tuple 📖
Planning
- 7 Challenges with Long-Term Projects and How to Manage Them
- Minimizing WIP:
- Dear Scrum teams, stop planning Mishmash Sprints • Work together on one clear goal • Mike Crittenden 📖
- Pull methodology, flow time, and WIP limits: visualized • Three videos • Mike Crittenden 📖
Inbox
-
A simple process beats a perfect process • The value of universal understanding outweighs the value of accounting for every possible edge case and gotcha • Mike Crittenden 📖
-
slack: appoint a meeting scribe of the week to post meeting takeaway summary for people who couldn’t attend (or who don’t attend but appreciate visibility, like a manager or director)
-
Conventional Comments - prefix PR review comments with labels that make their expectations obvious? e.g.
nitpick (non-blocking): ...
,suggestion: ...
-
The Five Dysfunctions of a Team - Audible
-
6 Software Engineering Templates I Wish I Had Sooner - really useful documentation templates that include headings and prompts to ensure common engineering docs cover the important stuff
-
diagramming: tldraw - another tool like excalidraw
-
chat etiquette: if you see someone else is currently typing, don’t race them! it makes them feel they need to speed up and the whole thread gets a bit hyper; let ‘em finish
-
When a 1-1 conversation with your direct report is drying up • Ideas: wrap early, select randomly from collections of work and non-work questions, or play a quick game • Mike Crittenden 📖
-
book: “team topologies”
-
How to review code effectively: A GitHub staff engineer’s philosophy - The GitHub Blog • GitHub Blog 📖
-
The OARB framework: Why you should appeal to self-interest when giving feedback • Wes Kao 📖
-
The 3 Motivational Forces of Developers - Ben Northrop • It helps for a team to have a mix of devs who prefer to focus on the business, the problem, or the technologies used • Ben Northrop 📖
-
Story Points are Pointless, Measure Queues | Brightball • Measure how many tasks are in your active queue and your rate of task completion instead; focus on breaking down problems into tasks and prioritizing them well; creating and managing queues is valuable; trying to predict time is not • Barry Jones 📖