Pair Programming Economics

My experience with pair programming in ML modeling:

- ML involves making lot of assumptions. That created some fatigue in me, and it helped to have someone giving out their thoughts actively. Even when not aligned on a common view point, simply going by one's approach first based on ease-of-implementation sounds practical. we could try other ideas always right..

- Creating bugs became more apparent. i.e., every software bug is someone's creation, and pair programmer would actively think about what's going on, makes the code less buggy

- Software architectures and designs are easy to justify at the end, because you've one more already on board, at least to some extent. If the person isn't aligned with the other's thinking, its very easy to pin point the item. Usual management style is, someone with different eyes (managers, tech leads) review once its gotten to some place.

- What was mild inconvenience was: my pair programmer was Vim guy, I'd like sublime text. Our style of thinking was also different. It made few things better, but ultimately you are asking someone to push their approach onto you. Some adjustment needed.. but okay. I'd prefer reading papers in depth before finding a common theme to implement, they'd prefer jumping into code, and then tweaking and hacking. My motivation/internal agenda is to write novel work, they'd want to simply get best numbers out. Aligning on something at this high level I thought has pros and cons..

- Overall, pair programming really helped me see myself. Its like getting active feedback, but not in the formal feedbacks designed in companies. If both like to some extent doing it together, its a good way to grow as a person and engineer.

- In workplaces there persons would not say I don't like pair programming with this person, unless do/die situation, at least in small companies. This pushes everyone to learn some people skills to see how things are going on.. I felt some discomfort at this aspect, but okay.

- I always had some insecurity about whether I am good enough for my goals or current project. I admired how many things are done by my pair programmer, and that made me feel whether they like working with me. It was always running on the back of my head. I think this dragged my personal contributions..

I'd always suggest someone try pair programming, see how it goes.

Sometimes I wish I was a salesperson. My performance is clear as day and I automatically get compensated accordingly

I'm pretty sure it's not that nobody bothers, it's just that there is well over a decade of research and literature strongly suggesting that it's either (a) impossible to do this kind of direct productivity measurement accurately, or (b) gives the wrong idea, creating wrong incentives that generally fail to improve outcomes (or worse, that the measuring directly hinders many positive outcomes.)

https://martinfowler.com/bliki/CannotMeasureProductivity.htm...

Outcomes are hard to measure, so we measure productivity instead. At least that's how it goes in my organization (and it does not turn out well, as suggested by the literature.)

Edit: but we are for the most part not developing software as our core competency in this company, so it turns out that fixing this is a pretty low priority...

Is PP "trendy"?

The "extreme programming explained" book that (afaik) popularized it came out more than 20 years ago.

For no apparent reason. Five years ago it was part of the world-wide web and open to mashups and automation, now everyone needs a custom deobfuscator (albeit a simple one).

https://news.ycombinator.com/item?id=8983158