Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe we shouldn't be reviewing all this code

martinfowler.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Maybe we shouldn't be reviewing all this code

#31

Post by thisoneisreal »

BatchJob wrote: post #18
em-bee wrote: post #14

Earlier quoted context omitted.

my performance goes up when i pair program. even if the partner is a junior, simply because i am more focused.

Pair programming is one person coding, and one person watching.

The person "watching" should be actively engaging and helping to build the "theory of the program" (in the Naur sense) through questions and conversations. If they're just sitting there silently they aren't doing the practice. (Also, I prefer to work with both developers having a keyboard and mouse. You still should have one person driving, but the other person can jump in and directly make changes instead of having to use the other person as a puppet.)

Re: Maybe we shouldn't be reviewing all this code

#32

Post by humbleharbinger »

For a second I thought this was Fowler posting but it's actually the CTO. Look if not reviewing code works I'm sure we'll see startups and new companies pushing it to the max.

I'm at a startup myself and we make judicious decisions about what to review and what doesn't need review. Our core systems go through code review - alignment is always built up early anyways.

Re: Maybe we shouldn't be reviewing all this code

#33

Post by natbennett »

Arainach wrote: post #4

This approach doesn't scale. Pair programming once in a while can be incredibly valuable. I am glad to meet with anyone and talk over their code in person, brainstorm designs, run through a debugger together investigating it. But if you asked me to do that for most of an 8 hour day - much less most of the time in general - I would quit the job faster than you could fill out the paperwork. Constantly having someone lo…

“It doesn’t scale” and “it’s unreasonably difficult for many people” aren’t the same thing.

It scales fine to 400+ engineers. You do have to be willing to hire specifically for pairing tolerance.

Re: Maybe we shouldn't be reviewing all this code

#34

Post by makeitdouble »

Arainach wrote: post #4

This approach doesn't scale. Pair programming once in a while can be incredibly valuable. I am glad to meet with anyone and talk over their code in person, brainstorm designs, run through a debugger together investigating it. But if you asked me to do that for most of an 8 hour day - much less most of the time in general - I would quit the job faster than you could fill out the paperwork. Constantly having someone lo…

I imagine it would become a different job altogether, more in the style of buddy cop movies: you'll be spending all your work hours doing every project with your partner, sometimes they code, sometimes you do, but you become a single unit for all intents and purposes.

I'd also hate it with every cell of my body, but for some it's just another way of life.

Re: Maybe we shouldn't be reviewing all this code

#35

Post by [deleted] »

Arainach wrote: post #23
jameskilton wrote: post #12

Earlier quoted context omitted.

Then you've never actually Pair Programmed. It's not "someone looking over your shoulder", it's literally two people writing the code together, one person at the keyboard and the other person saying what's next. Two brains working in tandem on the same problem space. It works really well , but it is exhausting, and difficult to sell.

Physical placement isn't important. Psychologically, it's the same. What it means is that for the entire duration there is someone paying close attention to (and potentially judging) everything I do. No downtime, no zoning out, focus and performance for an extended period. IM notification from an old teammate pops up complaining about my boss? Seen. Switch to a window with my personal email and they can see that thin…

[deleted]

Re: Maybe we shouldn't be reviewing all this code

#36

Post by natbennett »

hungryhobbit wrote: post #2

>If we want to explore alternative solutions, I’d rather do that before implementing one of them. >If we want knowledge transfer, pair. Sitting next to someone, physically or virtually, while they reason through a problem teaches you far more than reading their completed solution afterwards. >If we want junior engineers to learn how experienced engineers think, let them work with experienced engineers while they’re t…

> The vast vast majority of shops are not going to adopt Extreme Programming

True!

> and cut their velocity in half

That’s not how pair programming works.

Re: Maybe we shouldn't be reviewing all this code

#37

Post by Conlectus »

bossyTeacher wrote: post #24
jameskilton wrote: post #12

Earlier quoted context omitted.

Then you've never actually Pair Programmed. It's not "someone looking over your shoulder", it's literally two people writing the code together, one person at the keyboard and the other person saying what's next. Two brains working in tandem on the same problem space. It works really well , but it is exhausting, and difficult to sell.

> one person at the keyboard and the other person saying what's next My understanding is that there is no one person saying what's next but what's next gets decided by both people. Otherwise, the other person is just a typist.

That’s the ideal, but if you have the person at the keyboard doing too much of the planning then it’s really easy for the other person to just check out mentally.

Re: Maybe we shouldn't be reviewing all this code

#38

Post by singpolyma3 »

> If we want to explore alternative solutions, I’d rather do that before implementing one of them.

Sounds cute. But you won't know what any of them really are until you've built at least one of them. You can write specs and have meetings for years and you'll still miss something fundamental about the approach that will be discovered in the first hour of building.

Re: Maybe we shouldn't be reviewing all this code

#39

Post by singpolyma3 »

Arainach wrote: post #23
jameskilton wrote: post #12

Earlier quoted context omitted.

Then you've never actually Pair Programmed. It's not "someone looking over your shoulder", it's literally two people writing the code together, one person at the keyboard and the other person saying what's next. Two brains working in tandem on the same problem space. It works really well , but it is exhausting, and difficult to sell.

Physical placement isn't important. Psychologically, it's the same. What it means is that for the entire duration there is someone paying close attention to (and potentially judging) everything I do. No downtime, no zoning out, focus and performance for an extended period. IM notification from an old teammate pops up complaining about my boss? Seen. Switch to a window with my personal email and they can see that thin…

Well you won't have IM or email open while pairing :) you'll be focured on the conversation you're having with your pair. They're not watching you you're collaborating

Re: Maybe we shouldn't be reviewing all this code

#40

Post by jashper »

jameskilton wrote: post #12
Arainach wrote: post #4

This approach doesn't scale. Pair programming once in a while can be incredibly valuable. I am glad to meet with anyone and talk over their code in person, brainstorm designs, run through a debugger together investigating it. But if you asked me to do that for most of an 8 hour day - much less most of the time in general - I would quit the job faster than you could fill out the paperwork. Constantly having someone lo…

Then you've never actually Pair Programmed. It's not "someone looking over your shoulder", it's literally two people writing the code together, one person at the keyboard and the other person saying what's next. Two brains working in tandem on the same problem space. It works really well , but it is exhausting, and difficult to sell.

I’m all for talking through things and getting a second opinion, but when it comes time to actually crafting things, I need my own space, maybe I’m just weird
Post reply on HN