Tag: pair programming

  • Projects one at a time

    Projects one at a time

    The discussion about developer productivity (see: here) led me to following Paulo André, who recently posted:

    The secret to productivity hiding in plain sight:

    The fastest way to complete two projects that use the same resources is to do them one at a time.

    It’s 2023 and most still pretend otherwise.

    I initially read this incorrectly (use resources one at a time??) and I thought it was a criticism of pair programming. Then I read it correctly.

    First of all, I absolutely agree. As most of the comments say, multitasking is so last century. If someone tells me they’re great at multitasking, I’m more likely to offer them advice than applause.

    However, now I’m wondering if Paulo’s comment is or isn’t an endorsement of pair programming, regardless of whether Paulo had that in mind.

    Two owls on a branch
    A search for “pair programming” got me this, in round one. Photo by Michael Hoyt on Unsplash

    Clearly one brain trying to multitask on multiple pieces of work is using “the same resources,” but what about two brains with multiple pieces of work? From the perspective of the team, wouldn’t all of the developers on the team be considered “the same resources”?

    I’m leaning towards the analogy faltering as more brains are added. The limit on WIP (work in progress) isn’t always “one” nor is it necessarily “the same as the number of developers.”

    Maybe put another way: speed isn’t the only benefit of pair programming. Developers learn from each other, code review is inherent, knowledge of the code is shared.


    Originally posted 2 October 2023 on Medium.