21–30 of 87 posts
Are we going back to waterfall?
She's just arguing that most of the purposes of code reviews should be done before the typing part of coding instead of after. Identifying the best design before investing in typing / tokens.
Waterfall has to do with the size of the loop and when the customer gets to provide consumable feedback. She's not proposing changes to the size of that loop.
How about.. "it depends" ? I review things that I know are "important".. but I've learned that there are many things that I don't care how it works at this point- they aren't critical in terms of I know it's not going to cascade and break other things (that's where us senior engineers know what to look for). But there's no way in the hell I can review all the code that is being generated for so many things that just…
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.
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 thing I just bought or that recruiter I've been talking to? Seen.
I type a stupid thing that will never work? In the 5-30 seconds before I realize it, seen.
It doesn't matter if I trust my pair. That's not how the brain works.
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.
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.
I didn't think this is a controversial take (except for some of the solutions proposed) design and high level implementation shouldnt be happening in code review. that's way to late in the process.
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…
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.
Also we can get rid of that nurse keeping track of surgical instruments during a surgeries.
What's the big deal if a surgeon leaves a a scapel inside of someone?
This article flies so wildly in the face of good engineering and scientific practices it feels like a subtle troll post to get views.
>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…
also if pair programming means saving time on code reviews then that's a further increase in velocity.
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…