[LRUG] [Workflow] Getting a Pull Request from creation to merge

[Mark Burns]

It's a bit of an avoid the question type of answer, but we tend to have a
rule that pull requests are only
for work that hasn't been paired on.

Pairing mitigates the issues of context switching, blocking, interrupting,
etc.
It also improves team-wide communication, understanding of any of these
types of process ideas,
understanding of coding standards or evolving design patterns, sharing
nifty command-line tricks or
text-editor wizardry, and general camaraderie.
Design patterns, or even proposed or evolving design patterns are the
hardest ideas to communicate
via either the code itself or comments.
Something needing to be extracted into a new class, method, or whatever
type of re-factor or shift, is
quite an organic process. You could try your best to hint at these ideas,
mention them in a pull request
comment, or try and remember them tomorrow morning in a stand-up, but
really the best way to communicate
that you fully grok that this piece of code may be starting to accumulate
some type of design smell
or anti-pattern is with the type of conversation that occurs whilst you are
deeply involved in that
particular piece of code and its inner workings. Along with all the context
necessary to understand what
its issues are, you are often in the perfect situation to evaluate or
consider re-evaluating a particular section of
code, having a team member who both feels your pain, and can understand the
benefits and reasoning of a
shift to some change, even if it just results in creating a 'we need to
refactor X to Y' type of chore in a
ticket/bug tracker, it means that at least 2 people understand where the
code is heading and should be
going and at least 2 people know the direction of the codebase, and
understand its living, breathing essence.

The corollary, however, is taking this living organism and dissecting it
into diffs, laying it onto the operating
table that is a GitHub pull request, and coldly asking for hints and tips
on how to sew it back together nicely.
It takes a special type of mind to get back into the soul of a section of
code based purely on analysing a
sequence of diffs, and I'd suggest that most, if not all, completely miss
this context, only to later curse the
previous developer who worked on something, by pulling up the terribly
named tool 'git blame'.

All of my best code, repeat ALL, has been paired on. Does that make me a
terrible developer? Half as
efficient as anyone else? I'm not convinced. Certainly not if I can skip
steps 4 to 8, and get my code deployed
within the same kind of time frame as it took to write it, and with
confidence, and the investment and understanding
of the rest of the team, and leaving time to get rapid feedback from the
product manager, and the product itself,
sometimes the public. I can spend the time of steps 4 to 8 perfecting or
re-working, adapting and refactoring the code,
enhancing the feature itself, and mitigating unforeseen bugs and
consequences.

Anything anyone can do to tighten the feedback loops they get from any
process (faster test runs, constantly
present product manager, fast deploys, rapid customer feedback, and instant
feedback from a pair), will improve
their productivity as a developer.



On 20 August 2013 19:21, David Waller <david.a.waller at btinternet.com> wrote:

> A bit late to add my 2p, but anyway...
>
> Context switching cost is almost impossible to avoid, but I've found that
> you can mitigate it in small ways
> - keep changes small so that they're fast to review
> - the team needs a shared commitment to not blocking each other
> - 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.
>
> 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.
>
> David
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130821/ccdda603/attachment-0003.html>