Comment by drawkbox | Hacker News Reader

Comment by drawkbox | Hacker News Reader

Parent Full thread

Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.

There is a reason why nearly all good programming languages, standards, platforms and even games are usually started and prototyped by one developer. That is because programming is creative value creation and business/finance/project managers passionately want it to not be, they want it to be a factory and it never was, is or will be that until the initial versions are out. They want to value extract before the value creation, they also try their hardest to make sure no programmer has much power so they are "swappable" which again is not true in product creation, maybe maintenance or once the base is created, but not initially.

Programming is a creative skill and should always be seen that way. Most product developers, game developers and full stack to presentation developers know this and can make some of the best value creation because they can take it from start to finish. Once it is prototyped or first versions, it can be ramped up for value extraction.

This is so true, and it's why I passionately hate pair programming. Also: Scrum, which is another one of these attempts at turning software engineering into assembly line work. Partially successful in case of maintenance-heavy projects, but a disaster every time I witnessed it being applied to early-stage foundation building.

When prototyping some new idea that might result in a new product/platform/module/whatever, I tend to iterate faster than I could explain my iterations to any other person, even well-versed developers, let alone average-skilled ones. It is normal to refactor the entire codebase multiple times a day in such situations. The internal reasoning processes that guide these iterations, the probability assessments followed by quick trials followed by another iteration that ultimately lead to a solution are so manifold and dealing with so many particulate details (that are of utmost importance however at such an early stage of a new system) that it is impossible and impractical to discuss all of them with someone. You just have to follow your intuition. Having two intuitions in play at this stage is counterproductive, the friction losses are just way too big.

> Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.

This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.

I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.

> Hmm, i don't like this for subjective reasons, you should rewrite it to be different

That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".

> That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".

Agreed, yet you're implying that:

  - there must be a guidebook in the first place
  - that it must actively be followed

Sadly, that is not the case in many environments, where disagreeing with another developer might actually make you waste more time discussing (or rather) arguing things back and forth, rather than just doing the changes that they want.

Does not seem to be a good place to be in.

It can work both ways.

It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.

My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).

I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.

Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.

Reply on news.ycombinator.com