Comments by "" (@JinnGuild) on "Git Flow Is A Bad Idea" video.

@unduloid If testing is giving a false sense of security, you are writing bad tests. Or, you are only focused on one type of test (acceptance, unit, regression, integration, system, performance, etc). Testing does nothing but give a proper sense of security, if you know how to test. There is no place in the Software Engineering industry for arguments based on the assumption that "the professionals" suck at their job. The only answer is; "Professionals" should learn how to do their job.
1
@k8s347 You think the "point of [this] approach" -- Do you mean the approach of GitFlow, or the approach that this video and the comments above espouse. Your contextual branching may have diverged. The point of [this] approach (the conversation against gitflow) is to NOT Do Pull Requests. PRs hinder CI, if not break it. But the point of GitFlow, at least one "benefit" is that there is a gatekeeper which, of course, makes it not continuous.
1
@Quenjii You are mis-defining async. Neither approach is async. Async means actions can happen irrespective of the other's schedule, including both "At the same time" as well as "at any separate time". Pull Requests are purely Serial, they happen in an order, definitely not async. Pair Programming happens only in parallel, never in serial. So PP isn't async, but most people agree that Parallel is closer to async than Serial is. So if anything, your definition is close to backward.
1
@scatterarrow The speaker absolutely does not pretend that. His stance is to do Pair Programming. While I'm a fan of PRs for some reasoning, I'm a fan of Pair Programming for others. Pairs working on something means it is not "un-reviewed". It absolutely is. Also, you CAN check in half-finished code, or even code with blatant errors in it, and have it delivered all the way to production. As long as part of your CICD process includes Feature Gating and your changes are behind such a gate.
1
@OrcusMaximus I had the same stance you did (and I still value that stance) for a long time. I even try to get clients to that point as an interim so I don't blow their minds with culture shock. But if you commit to Pair Programming and erase from your mind the thought that two people working on one thing is a waste, then it becomes your life, in a good way. It is so amazing.
1
@justusschwabedal5924 I agree with @arch126, but I also find this scenario silly. 8-hour workdays not overlapping means you only have 3 developers exactly perfectly distributed around the globe. Or, if you want at least half of your work day focused on pair programming, you have 6 developers EXACTLY Perfectly separated around the globe. Okay, maybe pair programming isn't right for that scenario. But also, c'mon, lol. Also also, like I said, it is agreed that Pair Programming isn't meant for 100% of projects. But the percent it would work for is higher than people imagine.
1
@Quenjii You're once again mis-quoting (selectively). The second half of the sentence you referenced said: including both "At the same time" as well as "at any separate time". But your method only works "at any separate time". And it requires your part to be complete first, then their part to be complete afterward. That's literally synchronous, the opposite of Asyncronous.
1