[flagged]
Maybe we shouldn't be reviewing all this code
81–87 of 87 posts
Re: Maybe we shouldn't be reviewing all this code
#82[deleted]
Re: Maybe we shouldn't be reviewing all this code
#83>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…
You must not be familiar with Thoughtworks. Even before AI they were happy to bill you 5x more consultant hours than necessary.
Re: Maybe we shouldn't be reviewing all this code
#84> “ Shift the judgment left
…shorten feedback loops.[…]
Take the things we say code review gives us.
If we want to explore alternative solutions
[…]
If we want knowledge transfer
[…]
If we want junior engineers to learn how experienced engineers think
[…]
If we want collective ownership,
[…]
If we want architectural alignment
[…]
And if we’re reviewing code for formatting, linting, known security problems or things that can be deterministically tested
[…]
Review by exception
None of this means nobody ever reviews code.”
I don’t program as a “hired programmer”, but rather use programming in my work. That said, reading this list i’m at a different takeaway— I’m thinking “code review” is a catchphrase for a bunch of reasonably different tasks.
Re: Maybe we shouldn't be reviewing all this code
#85This 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.
>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.
That is literally what most people hate about it.
Re: Maybe we shouldn't be reviewing all this code
#86Earlier quoted context omitted.
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 pur…
Your experience sounds really interesting, can you tell us more ?
Re: Maybe we shouldn't be reviewing all this code
#87>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.
I've done pair programming (at an Extreme Programming shop).
There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on.
But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot.
Pair programming is not about getting more done, it's about getting less done (but done better).