1. -5

The standard git workflow is inefficient.

Git was developed for open source contributors to the linux kernel. It was meant for distributed teams, working across the world. Most saliently, it was intended for asynchronous development.

It was never intended for developers who could sit down and work together.

Git’s Pull Request (PR) functionality makes developers wait.

Because developers are clever, they anticipate this and make smaller PRs. They think that this will get their changes approved quicker. It will make them more productive.

It has the opposite effect.

When everybody is making small changes, if thy work asynchronously, they spend /more/ time waiting. If you want me to approve a PR, I can finish the PR I’m working on, switch contexts, and then approve your PR.

When everyone works like this, smaller PRs take /longer/ to approve.

This is just because of the time you’ll spend waiting for approval. Paradoxically, when a PR gets too large, nobody bothers reading it. They just approved the whole damn thing.

And slowly the quality of your code base degrades.

Want to avoid this situation? Pair program instead.

That way, developers don’t wait to approve. They approve right away. The PRs can be small. As small as a single unit test.

Instead of working on half as much stuff, pair programming makes developers productive.

  1.  

  2. 5

    This just seems like twitter flamebait.

    Maybe there’s a seed of a future good article in there? I’d be interested to see an in-depth article about pros versus cons of “regular” vs “pair programming” of someone who has worked extensively in both, or a data-driven analysis of how long PRs take to be approved in repos.

    1. 2

      It seems like an unnecessary attack on the asyncness of PR:s to promote collaborative coding – a false dilemma.

      It assumes:

      • All PR:s requiring reviews are made by a solo developer.
      • All PR:s made through pair programming skips reviews.

      Which simply isn’t true. Instead:

      • Pair programming when used thoughtfully is excellent.
      • Async communication when used thoughtfully is excellent.

      (And in my opinion: In this day and age of Slack – we need more asyncness, not less)

      1. 1

        The weirdness of posting to Twitter with an image of text…

        Edit yet again I yearn for a flag reason like “no-content” or “useless” or similar… this is technically on-topic but as shallow as to be useless as a basis for discussion.

        Or just disallow Twitter as a submission source…

      2. 3

        Because developers are clever, they anticipate this and make smaller PRs. They think that this will get their changes approved quicker. It will make them more productive.

        Is there any empirical evidence for this? One could as well argue that small pull requests or patchsets are good, since they force people to break up changes into small, orthogonal, well-documented changes.

        Paradoxically, when a PR gets too large, nobody bothers reading it. They just approved the whole damn thing.

        My experience (at least with distributed projects) is that they never get approved and are stuck forever in limbo. I also had the same experience in some companies and organizations that I worked. Some people would work on something for weeks and then make a jumbo PR or patch set, no one wanted or dared to review it. Approving a review also introduces responsibility (since you vouched for the changes).

        1. 2

          Git’s pull Request (PR) functionality makes developers wait.

          Wait, what? MS Github and Gitlab have pull requests, not git.

          Want to avoid this situation? Pair program instead.

          Not all of us are comfortable with others in our space and looking over our shoulders while we work. And, well, not all of us are capable of looking over other peoples’ shoulders.

          In any case, it is possible for two people to do “synchronous” pair programming over an asynchronous communication medium. I’ve done it with an emailed patch ping-ponging back and forth with another person at a speed not much slower than real-time text chat. I’ve used IRC as an out-of-band signaling mechanism for collaborating with someone on a shared branch in a shared repo. For this to really work, both people need to be comfortable with letting the other modify their work.

          A buzzword artist might call it “computer-mediated iterative pair programming”. For some sorts of geek, it works well.

          1. 4

            Git has pull requests.

            git request-pull 12ab34cd https://example.com/linux.git
            
            1. 1

              That simply outputs a request that you can then copy into eg. an email?

              1. 2

                Indeed. A pull request, if you will.

            2. 2

              MS Github and Gitlab have pull requests, not git.

              I was going to make this point myself, but it seemed rather pedantic. You can consider the PR features of Git-based forges to a shiny version of git format-patch + mailman — the point of the article about workflow patterns stands.

              Pair programming is also possible remotely using Etherpad-esque collaborative editors. You don’t even need voice chat, text chat is sufficient. (I’ve done it, though not in a long time.)

              1. 2

                The assumption of the tweet is also that such PR:s needs a review / approval from another developer before getting merged – which isn’t true either.

                It can be merged by a bot or by the author itself – all depending on the principles one uses in the project.

                Some opens PR:s for every substantial change, leaves them open for eg. 48 hours or a week for people to be able to object and otherwise merges them as long as the tests passes.