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

61–70 of 87 posts

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

#61

Post by Arainach »

em-bee wrote: post #57
Arainach wrote: post #27

Earlier quoted context omitted.

Intense focus increases performance right up until the point where burnout or exhaustion causes performance to absolutely collapse.

research has shown that the longer work in one day the lower your performance gets. meaning that eg in the first 4 hours i get 60% of my work done and in the remaining 4 hours 40% simply because i get tired later in the day. (numbers made up for illustration purposes only) 4 hours of pair programming per day can therefore possibly be enough to make up for the increased loss of performance in the rest of the day.

The world is full of examples of companies that reward people who are more productive in a few hours by letting them go home instead of raising expectations and working them to death, I assume.

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

#63

Post by em-bee »

wpasc wrote: post #48
em-bee wrote: post #42

Earlier quoted context omitted.

how is the lego structure impossible? it is unstable because it's made only of 1-stud bricks. and there are some non existent multi colored bricks in use, but those could theoretically be produced. also while the wheels are not connected, you could stack pricks on top. so it's improbable, but not impossible. just drink a cup of NO and you'll be fine.

Look at the base of the structure on the right side, and you'll see that in the same plane there are the bumps present and bumps hidden by the same flat plane in a way they shouldn't be. then the left side, the bump visibility doesn't make lego sense (i agree that maybe OP pointing that out is nitpicking, but to steelman the case, such inaccuracies are what code review would find and are the subtle bugs that might pa…

you mean the white bump on top of the purple brick that should not be there? well, i saw that as a marking on the brick because if it was a bump it would be purple. and on the left side whether that looks right or not depends on the angle.

(we are nitpicking the nitpicking, it's nits all the way down. my last line in the previous comment was also based on the image. to shatter your steelman, picking on the illustration of the article that is just there to add some color is at best like a code review complaining about style or indenting. with endless bikeshedding opportunities, not something a code review should be focusing on. if the picture were of central importance then that would be different. btw, i am not complaining, i am having good natured fun here)

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

#64

Post by shalmanese »

stephenlf wrote: post #59
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.

Pair programming worked well for me in college because my peers had about the same level of background knowledge and the goal was well defined. At my day job, pair programming doesn’t work as well, since the knowledge gaps in different parts of the system are too great. We don’t have a cohesive skill set.

But that's the entire point. Pair programming isn't for producing more working code in this session faster. It's that it empirically is the fastest way to erase knowledge gaps because the two of you are working on a shared artifact.

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

#65

Post by em-bee »

Tanoc wrote: post #54
em-bee wrote: post #19

Earlier quoted context omitted.

AI may reduce the cost of code production, but it raises the cost of ownership.

Not just the cost of ownership, but the cost of disposal. Removing parts becomes much harder if you have to look through a lot more pieces to determine how they connect to everything else and what still relies on them. Programmers sometimes forget that they aren't just adding and making new things all the time, but that their job also requires digging through multiple older layers to excise obsolete unneeded things.

absolutely, for me that's included in the cost of ownership. just like the cost of ownership of physical items includes the cost of disposal of those items once they are no longer useful.

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

#66

Post by nomel »

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've never pair programmed. How can one achieve concentration for "deep focus" or "deep thought"? I'm only able to do that alone. Is it a me problem, or are some people able to focus deeply with others talking to them?

There have been (extensive) discussions on this topic here [1]. I don't seem to be alone in the inability to think clearly with interruptions.

[1] https://news.ycombinator.com/item?id=22059601

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

#67

Post by foundart »

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 did it full-time for 3 months and it was exhausting. I found it useful for learning a new framework (Ruby on Rails at that time) but in general I did not find it compatible with how I think and work.

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

#68

Post by nertzy »

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…

As someone who pair programmed 8 hours a day for 10+ years, it’s important to note that there is an ebb and flow. Sometimes we were collaborating fully. Sometimes one of us got up to make coffee and looked at Instagram on their phone for 20 minutes while the other tried to get tests to pass. Then we reunited and caught each other up. It’s easy to dwell on the intense part of pairing, but it’s just as important to purposefully acknowledge your humanity and expect to take real actual breaks and go sit in a comfy chair and zone out for a short while or go to a doctor appointment or chat up another person at the water cooler for a bit.

8 hours a day pairing means that pairing is the default, but it’s not the only thing that ever happens.

also: 8 hours/day pairing meant 16 hours/day not working at all in my case. Really really really not working. Not checking Slack. Not trying out some crazy idea. Not working at all.

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

#69

Post by nomel »

sciyoshi wrote: post #55
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…

Is this not what programming alongside or with an AI agent is these days? Brainstorming, reviewing, debugging. The only difference is there's no second human building a working knowledge of the code being written.

They're not human. When I interact with AI, it's an emotionless chat bot computer program. When I interact with a human, a whole other sections of my brain necessarily light up, because they do have emotions, they do judge me and I care about those opinions about me, and they have long term memory, all thanks to the millions of years of evolution around social interactions with other humans.

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

#70

Post by BalinKing »

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…

In the last company I worked at, when a project was major enough (read, long-running and full of tricky details) to require two devs' full-time attention, they'd hole up in a flex room for weeks at a time.[0] "The cave" basically became their temporary office until they'd re-emerge ~a month later.

I spent a few weeks in the cave and it was surprisingly chill, not nearly as oppressive as it sounds. (Although, I was much more energetic a decade ago and maybe it wouldn't be quite as fun these days :-P.) I still have a picture of my madness-induced, Git hook–infested scribblings....

[0] The team's usual room was an open floor plan, which was fine with good headphones, but naturally that solution doesn't work for pair programming.

Post reply on HN