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

71–80 of 87 posts

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

#71

Post by em-bee »

nomel wrote: post #66
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.

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

you are not being interrupted. your partner is thinking with you and is paying close attention to what you are doing. they will know you well enough to not interrupt you while you are focusing on something specific. they will wait for the right moment to speak up if they have something to add, and even then they will not change the focus to some other part of the task if they know that this would disrupt you.

this takes time to learn of course. and individuals handle this differently. i to can't handle interruptions, but when i am focusing a piece of code, and my partner telling me or asking me something about that same piece of code, then for me that's not an interruption. interruptions are notifications and being asked to change the focus on something different. that should not happen when pair programming.

another aspect not mentioned yet, when there is an actual interruption from the outside, one of the people in the pair can handle that interruption, while the other continues to focus. the interrupted one can then jump back in much faster than you would if you were interrupted while alone.

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

#72

Post by [deleted] »

em-bee wrote: post #14
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…

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

[deleted]

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

#73

Post by em-bee »

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

Earlier quoted context omitted.

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.

i get where you are coming from, but i suspect that the company that does that would also exhaust people without pair programming. bad work environments exist, and yeah, those are probably not the places where you want to introduce pair programming.

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

#74

Post by sublinear »

> My question is: why are we waiting until code review to do all of those things? I’ve never particularly liked pull requests as the centre of the software development process.

This is a strawman. Who is writing code professionally without planning ahead?

> Perhaps that’s what AI is exposing. ... It worked, sort of, while humans could only produce code so quickly.

Huh? This doesn't make any sense to me either for the exact same reason. Are the kinds of people who always sucked at planning finally getting slightly better at it with AI? Is this a breakthrough for people with ADHD, or what? Do these people really like seeing lots of text scroll by so much that they can't have a few simple meetings?

I'm still confused what any of this is really about. To me it reads like another AI copout blog post. I want to understand the author's idea of a productive workflow.

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

#75

Post by [deleted] »

em-bee wrote: post #71
nomel wrote: post #66

Earlier quoted context omitted.

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

you are not being interrupted. your partner is thinking with you and is paying close attention to what you are doing. they will know you well enough to not interrupt you while you are focusing on something specific. they will wait for the right moment to speak up if they have something to add, and even then they will not change the focus to some other part of the task if they know that this would disrupt you. this ta…

[deleted]

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

#76

Post by nomel »

em-bee wrote: post #71
nomel wrote: post #66

Earlier quoted context omitted.

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

you are not being interrupted. your partner is thinking with you and is paying close attention to what you are doing. they will know you well enough to not interrupt you while you are focusing on something specific. they will wait for the right moment to speak up if they have something to add, and even then they will not change the focus to some other part of the task if they know that this would disrupt you. this ta…

> you are not being interrupted. your partner is thinking with you

As the many examples in that discussion show, this is your subjective experience, with others build different than you.

To me, those two sentences side by side are in complete contradiction with how I experience the world, where the knowledge of a persons attention is distracting, like a glaring light.

But, for learning a new language/framework/codebase, I think it would work very well. The quickest, and most enjoyable, "ramp ups" I've ever experienced were just sitting next to someone and bouncing questions off of them as I explored.

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

#77

Post by horizonwingtech »

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.

[flagged]

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

#80

Post by grebc »

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…

If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.
Post reply on HN