[jamghee]

I working in XP for a bit and the constant pair programming aspect was simply too fatiguing for me. I enjoy pairing every now and then on certain problems, but the constant presence of another person left me utterly drained at the end of every day.

[scrapheap]

I know some people really work well when pair programming, but I find that I either slip into Student Mode or Teacher Mode when I try it. Either the other person knows the environment we're working in (architecture, codebase, etc) a lot better than I do, and I'm using the session to gather as much information as I can, or I know the environment better and so I'm explaining why I'm doing things.

If the other person and I are on par with the environment then we're more likely to have a discussion about what we're wanting to achieve and how best to go about it, but then one of us will go away and knock out a first cut for the other person to review.

I do wonder what differs between groups of people who can actually do pair programming and those that (like me) that can't.

[JackMorgan]

I think slipping into student mode or teacher mode is a fantastic reason to pair: it's full time training. You quickly will all rise to the skill level of the best parts of every engineer on the team. Otherwise training is rare and slow.

[pydry]

My mode is either driving and listening to advice or watching and trying to spot things the driver missed.

Occasionally I do side-work if Im not driving - e.g. look something up, message devops, a very small PR etc. so the driver can maintain focus.

I find it to be much more effective that working alone simply because so much stuff that would take me 20 minutes to to go down a rabbit hole ends up being caught by an extra pair of eyes in 4 seconds.

[j4yav]

I always thought that student / teacher mode was the very best form of pair programming.

[kstenerud]

Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto)

But the article highlights the good points of agile, and I agree with them:

- Iterative development (smaller steps with faster feedback)

- Unit tests (and building with unit tests in mind)

- Code Refactoring (which you can do confidently when you have unit tests)

The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV

[azangru]

> if you don't do it entirely this way, you're not extreme programming

But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming.

It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.

[kstenerud]

The problem is that these kinds of things become shackles for the mind, denying the agency and mental suppleness required to navigate a changing and chaotic world for which we can never achieve perfect knowledge (or even anything remotely close to it).

There is no such thing as a perfect set of rules or practices - only things that are useful in certain contexts. It is the practitioner's task to decide which principles apply, and to what degree.

Saying "You're not doing [brand new popular thing] unless you do it this exact way" is a trap laid for neophytes who lack the experience to discern that this is just arrogant bullshit, denying them the exercise of their own brain to judge what applies where (and learn from their mistakes).

[pydry]

Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.

Scrum had some serious problems, too, but nobody wanted to admit to them.

[brightball]

Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts).

The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow.

Getting people at the top to understand that challenge is the hard part.

[bboygravity]

Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example).

My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies.

I find it hard to care about these trends.

[brightball]

The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe.

If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized.

It’s critical.

[bluGill]

Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.

[brightball]

It's not that they need accurate estimates is that often sales people want to share those estimates externally, so anything that takes longer due to unexpected complexity becomes an accountability issue.

[azangru]

> Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.

And if people mean different things by the word scrum, it is rather hard to tell whether they are doing it properly :-)

Scrum is pretty difficult to do properly (the famous "easy to understand, but difficult to master" formula; although I would argue that it isn't that easy to understand either, at least not something that someone unfamiliar with it can understand in a day or two). It requires certain changes within the organization, which few organizations are willing to adopt.

[pydry]

I find this to be a problem with agile, but not so much with Scrum. It's quite proscriptive and there is a set of quite specific rules and processes you can follow.

[azangru]

> I find this to be a problem with agile, but not so much with Scrum.

I am seeing problems left and right. Mostly because people often copy the activities (they would often even call them rituals or ceremonies, as if to make it even more obvious that they are treating them as mysterious quasi-religious practices) without understanding what they are intended to achieve.

For example:

    - Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
    - Lots of sprint reviews that are just demos
    - Lots of sprints without goals, that are just timeboxes to finish a certain number of tickets/stories
    - Lots of teams that remain hierarchical, and instead of a real product owner have some kind of a middle manager (who might also assume scrum master responsibility, because he is manager)
    - Lots of teams focusing on story points, velocity, and estimation
    - Lots of teams that don't adapt previously formed plans to the emerging reality 

And so on, and so forth.

[michaelcampbell]

> This is the way to do things, and if you don't do it entirely this way, you're not extreme programming!

Which is fine. They defined a set of practices, called it XP, and if you don't do these, you're not doing XP.

[somewhereoutth]

Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.

[willsmith72]

I actually loved it. I had never learned so much or shipped so quickly and reliably.

And then I moved teams... And realised it's all about the people and culture around you.

I probably wouldn't sign up for it again when joining a new company, because at its worst it's absolute torture, but I still believe that at its best there's nothing like it.

[michaelcampbell]

You both can be right. It can be the best way for you, and it can also be utterly exhausting for them.

Personally, I'm not willing to get rid of _all_ my comfort zone to get something out the door more efficiently, where shareholders and C-levels get rich off my labor, and if I'm very lucky, I get to keep doing that.

[willsmith72]

Well if I saw my work life like that, why improve any system or take any initiative on anything?

I like working in teams with ownership over their outcomes, and reward for their success

[michaelcampbell]

Sure, but I can only enjoy so many free pizzas.

[crabbone]

If I had to pair-program, I'd probably call in sick. And if this was a repeated demand, I'd eventually just quit.

To me, this is one of the worst ways to work. I very much prefer to communicate in writing, and at prearranged times. To me, the idea that there's another person working with me on the same problem at the same time is as absurd as having another person cooking in the same kitchen with me, or painting on the same canvas as me. Whatever result I can produce on my own, it will be ten times worse if I had to do it with someone else working on the same problem with me.

[pjmlp]

Same here, just the idea of forced XP is enough for me to start considering other positions.

[gramie]

I went through a period of a couple of months where I pair-programmed almost every day, and it was probably the most productive time of my career. My partner was very junior, and new to the project, and the process of explaining things to him definitely helped avoid some of my blind spots. He had several good insights and ideas, too, coming in with fresh eyes.

It was high-energy, though, and an extended period might well have been fatiguing.

[djtango]

first, there's a definitely a stamina to it - I worked in an XP team for best part of 3 years and have at other jobs done a lot of full-time pairing (sometimes months at a time).

Second, there's a chemistry element. When there's good chemistry it can be quite effortless and the chemistry can grow - as you start to develop an intuition for how the other person thinks there's less communication and mental jostling.

I've had remote pairing sessions that have felt almost as fun as online gaming.