Hacker News new | ask | show | jobs
by HandsAtTheReady 2692 days ago
I've been at places that do those too. But they weren't the environment that has enabled my best work.

In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.

1 comments

And it isn’t a context switch to have someone right next to you hovering while you are trying to develop? What context switch? You do a high level design before you start. Do you really need someone over your shoulder to make sure you can turn requirements into code?
> someone right next to you hovering while you are trying to develop

The pair is a collaboration. They develop together.

> Do you really need someone over your shoulder to make sure you can turn requirements into code?

I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.

I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.

Do you really need to “develop together” to do most features? Most work that developers do isn’t writing complex leetCode algorithms. Are you really saying you aren’t capable of turning requirements into software design by yourself?
You seem resistant to the idea of pair programming. I'm assuming you've done very little of it in your impressive career. As a fellow software engineer, I'm surprised you would be so resistant to something you have so little experience in. I'm not trying to convince you to pair program, I'm trying to convince you to read up on it and find out why others think it's great. 'Others' including some very skilled software engineers like Kent Beck. But from his own mouth, "pair programming works best with a large uncertain search space of problems and solutions. the closer to a solved problem, the less it helps" https://twitter.com/kentbeck/status/253532726714580992?lang=...
Most problems that developers face every day are solved problems just in a different domain or with changes around the edge based on requirements.

I have no problem with collaboration - ie I’m working side by side war room style with one person doing the front end, the other doing the back end, the QA person testing, etc.

Do you really need to pair to write yet another software as a service CRUD app?