Love to see your articles Jordan! Awesome to see the continuation of "Communicate like a senior" series.
I had a few questions/thoughts:
1. I liked how the ending of the article wrapped up the "linked list update" point by linking to the previous articles in the series! Clever transition here and I should try that technique for my projects at work.
2. I'm definitely guilty of the "tag a staff engineer in a long oncall thread during incident" mistake at times. From your experience, where do you draw a balance between keeping the 50+ reply thread going vs. starting a slack huddle as a forcing function to discuss the question and then post an update with the alignment/summary in case others want to catch up?
3. I've noticed that pull request communication process can vary between teams and types of companies and reading the room on what the norms are can be very helpful. For example, in company/team A, maybe it's ok to spend the extra time on polishing/refining your PR even if it means sending out for review 2-3 days later, but maybe in company/team B, the norms might be "send out the PR when you have it working to get feedback sooner and the minor cleanups/refinements can happen while the review is happening". I find myself sometimes sending out a PR to get early feedback on direction/strategy to save hours of cleanup later. Have you noticed a similar pattern from your experience?
I would also add on top of having a good PR description with links to the relevant artifacts, add a Test Plan to your PR (eg: unit tests, loom videos to demo your PR). I find as a reviewer, I tend to jump to the test plan after reading the high level description to piece the intent of the PR together quicker.
The PR reviewer in my opinion can also help accelerate a PR getting merged faster by also indicating which comments are must address vs. what can wait later (eg: "[nit] my comment" vs. "[blocking] why did we do this change?")
Thanks so much for your detailed comment and thoughts, Karthik!
To answer your questions:
1. Thanks so much! Credit to Rahul. I never thought of that until he pointed it out in one of his lessons on Taro.
2. Great question! Mainly a balance of "which will get to a resolution faster", "what is the value of seeing the whole process in the thread", and "can I even huddle." It's definitely situation dependent and takes time to find a good balance, and I'm sure I don't get it perfect.
3. Definitely. Sometimes it will be good to get a PR out there for quick thoughts if the intent is already clear or defined elsewhere, like when you send it in Slack. Still, most of the time, to write a description + comment/review my code takes about 15min, which gives high confidence I can remove a feedback loop of review cycles, which is often at minimum an hour. I think it helps me ship PRs a lot faster.
Actionable steps. Thank you!
You got it, Suchi!
Great post!
Thank you so much, Daniela!
Love the first one! Definitely important for large group threads.
Thanks a bunch, Sidwyn!
Love to see your articles Jordan! Awesome to see the continuation of "Communicate like a senior" series.
I had a few questions/thoughts:
1. I liked how the ending of the article wrapped up the "linked list update" point by linking to the previous articles in the series! Clever transition here and I should try that technique for my projects at work.
2. I'm definitely guilty of the "tag a staff engineer in a long oncall thread during incident" mistake at times. From your experience, where do you draw a balance between keeping the 50+ reply thread going vs. starting a slack huddle as a forcing function to discuss the question and then post an update with the alignment/summary in case others want to catch up?
3. I've noticed that pull request communication process can vary between teams and types of companies and reading the room on what the norms are can be very helpful. For example, in company/team A, maybe it's ok to spend the extra time on polishing/refining your PR even if it means sending out for review 2-3 days later, but maybe in company/team B, the norms might be "send out the PR when you have it working to get feedback sooner and the minor cleanups/refinements can happen while the review is happening". I find myself sometimes sending out a PR to get early feedback on direction/strategy to save hours of cleanup later. Have you noticed a similar pattern from your experience?
I would also add on top of having a good PR description with links to the relevant artifacts, add a Test Plan to your PR (eg: unit tests, loom videos to demo your PR). I find as a reviewer, I tend to jump to the test plan after reading the high level description to piece the intent of the PR together quicker.
The PR reviewer in my opinion can also help accelerate a PR getting merged faster by also indicating which comments are must address vs. what can wait later (eg: "[nit] my comment" vs. "[blocking] why did we do this change?")
Thanks so much for your detailed comment and thoughts, Karthik!
To answer your questions:
1. Thanks so much! Credit to Rahul. I never thought of that until he pointed it out in one of his lessons on Taro.
2. Great question! Mainly a balance of "which will get to a resolution faster", "what is the value of seeing the whole process in the thread", and "can I even huddle." It's definitely situation dependent and takes time to find a good balance, and I'm sure I don't get it perfect.
3. Definitely. Sometimes it will be good to get a PR out there for quick thoughts if the intent is already clear or defined elsewhere, like when you send it in Slack. Still, most of the time, to write a description + comment/review my code takes about 15min, which gives high confidence I can remove a feedback loop of review cycles, which is often at minimum an hour. I think it helps me ship PRs a lot faster.