Developers spend most of their time figuring the system out

Post by Gravityloss » Wed, Mar 30, 2022, 9:23 PM UTC

kayodelycaon wrote: post #55

gleenn wrote: post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out. Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues. This causes me to work by feel on some tasks because I don’t…

Post by cloogshicer » Wed, Mar 30, 2022, 9:24 PM UTC

ilovecaching wrote: post #46

cloogshicer wrote: post #27

Earlier quoted context omitted.

That paper is amazing. Completely changed my view on programming. For those who find it a bit inaccessible (as I did on my first read), I wrote an article about it a while back, explaining it further and giving real-life examples: https://hiringengineersbook.com/post/autonomy/

Nice article, I enjoyed reading it.

Post by caseyohara » Wed, Mar 30, 2022, 9:24 PM UTC

depr wrote: post #59

WindyCityBrew wrote: post #39

Earlier quoted context omitted.

There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. My guess as to why we don't see more adoption is 1) most developers aren't…

Can you provide this evidence?

Post by mikewarot » Wed, Mar 30, 2022, 9:29 PM UTC

cloogshicer wrote: post #27

bcbrown wrote: post #4

Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and…

That paper is amazing. Completely changed my view on programming. For those who find it a bit inaccessible (as I did on my first read), I wrote an article about it a while back, explaining it further and giving real-life examples: https://hiringengineersbook.com/post/autonomy/

Post by teknopaul » Wed, Mar 30, 2022, 9:31 PM UTC

azemetre wrote: post #60

WindyCityBrew wrote: post #39

Earlier quoted context omitted.

There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. My guess as to why we don't see more adoption is 1) most developers aren't…

I don't mind pair programming but I don't have the physical/mental capacity to do it for a full work day. I can only imagine how exhausted I'd get after several weeks of it. When I do pair, I only work for 3 or 4 hours that day total.