Hacker News Reader

Hacker News

Comment by pydry | Hacker News Reader

Parent Full thread

pydry

It's good for a number of things:

* Having multiple perspectives on design.

* Having an extra pair of eyes to catch things one person might miss.

* Being able to bounce ideas off each other.

* Redundancy (if you are on holiday or sick somebody else still knows the code deeply)

* Onboarding (it works better at getting me up to speed than any docs ever have)

* Motivation (i find it's kind of like having a gym buddy).

* Bonding (assuming you get along with whomever you're pairing with)

I get that not everybody likes it though.

I feel that it's somewhat irksome for introverts and companies try to use it as a means of making developers more replaceable, which some people hate.

View on HN

> Having multiple perspectives on design.

Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.

It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design.

If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from.

If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.

That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.

Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back.

Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.

"Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.

No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.

Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that.

Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.

Why not?

For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.

1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.

My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.

Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering.

Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.

> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply)

This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.

I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.

Reply on news.ycombinator.com