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

51–60 of 87 posts

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

#51

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

#52

Post by em-bee »

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.

the other person is a typist that thinks through the ideas they hear and critiques them while they are typing.

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

#53

Post by ramshanker »

an0malous wrote: post #44
ramshanker wrote: post #13

At this point, I haven't even read around 30% of the code base in my open source project. I know our works by my manual testing. AI keeps writing tests for itself, even though I don't explicity ask for it, and I am not complaining.

Care to share a link?

https://github.com/ramshankerji/Vishwakarma

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

#54

Post by Tanoc »

em-bee wrote: post #19
synalx wrote: post #10

Imo, the article misses the main point of code review. It's not about finding bugs or spreading around knowledge, but about maximizing value vs maintenance costs. Code is expensive, not to produce but to maintain. Every line of code added to a codebase must be read and understood many times over its lifetime, and therefore imposes a burden on future maintainers. We review code in order to weigh its value against that…

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.

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

#55

Post by sciyoshi »

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.

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

#57

Post by em-bee »

Arainach wrote: post #27
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.

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.

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

#59

Post by stephenlf »

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.

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.
Post reply on HN