recentpopularlog in

kme : agile   18

To Pair or Not to Pair: Pair Programming - YouTube | https://www.youtube.com/
Lady's from ThoughtWorks (https://www.thoughtworks.com/), and if that's sounds familiar, that's because they're the Selenium and GoCD people.

Benefits mentioned in the video:
1. knowledge sharing (1 + 1 > 2)
2. combines two modes of thinking: tactical (driver: local optimization), strategic (navigator: big picture)
3. reflection (on the story, value-added, effectiveness vs. # of LOC)
4. helps coder / team focus; discipline around structure of code, strategy, explain and justify choices, avoid rabbit holes
5. "I get more programming productivity" out of reducing time that I'm stuck than from increasing my speed when I'm not stuck."
6. helps practice "true" CI--code review on-the-go; more collective code ownership; >> trunk-based development

Tips:
1. don't do it for 8 hours a day
2. take breaks; it's exhausting
3. even skill levels
4. share feedback (I don't like it when ...), exchange READMEs
5. "the shame of pair programming"; requires vulnerability

Homogeneous teams feel easier, but easy is bad for performance. (ref: https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better)

The authors are saying that this idea goes against many people's intuition, and often if there's something counter-intuitive, there's a cognitive bias hidden away somewhere, right?

And the one that they're mentioning here is the "fluency heuristic," which says that we prefer information that is more easily processed, and if it's easily-processed, we think that it's more true, more right, more beautiful, and that serves us very well in a lot of situations in software development. We want readable code, easily-processable things. But I don't think that it serves us well if we think that's why we're not doing pair programming.

So, pairing feels hard, but that doesn't mean that it's not good for performance, and also it doesn't have to stay hard.

Ways to make it easier (reduce friction, conflict, anxiety):
1. get the talking going
2. active listening
3. friendly feedback
4. answer why

See also: https://www.youtube.com/watch?v=S92vVAEofes
agile  cs  programming  pairing  pairprogramming  teamwork  collaboration  communication  conference  talk  video 
december 2018 by kme
/ndy: The Failure of Agile
Agile has always, and I mean always, struck me as a naive reaction to BDUF by folks who couldn't do BD. They offered up the notion that no process could be thought through a priori, so coding from the first moment, fixing in the debugger, pestering the users to offer up changes to UI or data or ..., thence rinse and repeat, was the way to go. IOW, cowboy coding with a mantra.

Agile ignores what the earliest craftsmen learned millennia ago: measure twice, cut once. But that actually means thinking through what one wishes to do. Nobody in the agile movement wants to do that.
agile  development  fail  criticism  forthecomments 
may 2015 by kme

Copy this bookmark:





to read