<div dir="ltr">It's a bit of an avoid the question type of answer, but we tend to have a rule that pull requests are only<div>for work that hasn't been paired on.</div><div><br></div><div>Pairing mitigates the issues of context switching, blocking, interrupting, etc.</div>
<div>It also improves team-wide communication, understanding of any of these types of process ideas,</div><div>understanding of coding standards or evolving design patterns, sharing nifty command-line tricks or</div><div>
text-editor wizardry, and general camaraderie.</div><div>Design patterns, or even proposed or evolving design patterns are the hardest ideas to communicate</div><div>via either the code itself or comments.</div><div>Something needing to be extracted into a new class, method, or whatever type of re-factor or shift, is </div>
<div>quite an organic process. You could try your best to hint at these ideas, mention them in a pull request</div><div>comment, or try and remember them tomorrow morning in a stand-up, but really the best way to communicate</div>
<div>that you fully grok that this piece of code may be starting to accumulate some type of design smell</div><div>or anti-pattern is with the type of conversation that occurs whilst you are deeply involved in that</div>
<div>
particular piece of code and its inner workings. Along with all the context necessary to understand what</div><div>its issues are, you are often in the perfect situation to evaluate or consider re-evaluating a particular section of</div>
<div>code, having a team member who both feels your pain, and can understand the benefits and reasoning of a</div><div>shift to some change, even if it just results in creating a 'we need to refactor X to Y' type of chore in a </div>
<div>ticket/bug tracker, it means that at least 2 people understand where the code is heading and should be </div><div>going and at least 2 people know the direction of the codebase, and understand its living, breathing essence.</div>
<div><br></div><div>The corollary, however, is taking this living organism and dissecting it into diffs, laying it onto the operating</div><div>table that is a GitHub pull request, and coldly asking for hints and tips on how to sew it back together nicely.</div>
<div>It takes a special type of mind to get back into the soul of a section of code based purely on analysing a </div><div>sequence of diffs, and I'd suggest that most, if not all, completely miss this context, only to later curse the</div>
<div>previous developer who worked on something, by pulling up the terribly named tool 'git blame'.</div><div><br></div><div>All of my best code, repeat ALL, has been paired on. Does that make me a terrible developer? Half as</div>
<div>efficient as anyone else? I'm not convinced. Certainly not if I can skip steps 4 to 8, and get my code deployed</div><div>within the same kind of time frame as it took to write it, and with confidence, and the investment and understanding</div>
<div>of the rest of the team, and leaving time to get rapid feedback from the product manager, and the product itself,</div><div>sometimes the public. I can spend the time of steps 4 to 8 perfecting or re-working, adapting and refactoring the code,</div>
<div>enhancing the feature itself, and mitigating unforeseen bugs and consequences.</div><div><br></div><div>Anything anyone can do to tighten the feedback loops they get from any process (faster test runs, constantly</div>
<div>present product manager, fast deploys, rapid customer feedback, and instant feedback from a pair), will improve</div><div>their productivity as a developer.</div><div><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On 20 August 2013 19:21, David Waller <span dir="ltr"><<a href="mailto:david.a.waller@btinternet.com" target="_blank">david.a.waller@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A bit late to add my 2p, but anyway...<br>
<br>
Context switching cost is almost impossible to avoid, but I've found that you can mitigate it in small ways<br>
- keep changes small so that they're fast to review<br>
- the team needs a shared commitment to not blocking each other<br>
- a reviewer shouldn't be pulling themselves out of a deep state of 'flow', but there are plenty of times when you're taking a lunch break, catching up on email, etc. when you can tack a code review onto the end.<br>
<br>
If you're doing continuous deployment or something along those lines, one of the key benefits is being able to turn round a fix in next to no time. If maintaining that sort of feature/bugfix velocity is a priority for your team then much of what I've suggested comes simply as a beneficial side effect of that.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div>