Are we going back to waterfall?
I mean, we certainly are in a lot of cases. Spec driven development is waterfall, and we're all in the midst of a new experiment to see if it works. I'm not sold, but consultants love it.
Maybe we shouldn't be reviewing all this code
11–20 of 87 posts
Re: Maybe we shouldn't be reviewing all this code
#12This 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.
Re: Maybe we shouldn't be reviewing all this code
#13At 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.
Re: Maybe we shouldn't be reviewing all this code
#14This 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.
Re: Maybe we shouldn't be reviewing all this code
#15> significant lines of code per human-landed diff Claude would be proud. That said, code reviews have never worked well, and it's a weird argument for wanting to preserve them. Pairing is great and under-utilized. On one hand it's a hard sell to managers (let's use two people to do one person's job) and from the developer's point of view, it's intense and exhausting.
What's a weird argument? Did you read this article?
She's arguing that most code reviews aren't necessary. Some can be automated if they are deterministically predictable (eg. formatting, lint, standardization changes). Others should be reviews of design before the coding phase.
She gives a few specific examples of when code reviews should be maintained.
Re: Maybe we shouldn't be reviewing all this code
#16This 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 our current environment using AI, individual development also "doesnt scale", so this "doesnt scale", 2X.
I think these proponents of AI have a very large burden on them to not just make this palatable for developers, but to actually make it "scale" as you say.
The human code review process for AI generated code will simply die due to lack of interest. Its up to the organization to find a suitable replacement or continue to pretend that half asleep disinterested developers are going to fix all this trash.
Have fun with that!
Re: Maybe we shouldn't be reviewing all this code
#17This 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.
+1 for exhausting. Also my experience. Very valuable when you have to write business logic or a complex feature the business will rely on.
Definitely not good for long running work and chasing bugs.
Re: Maybe we shouldn't be reviewing all this code
#18This 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.
Pair programming is one person coding, and one person watching.
Re: Maybe we shouldn't be reviewing all this code
#19Imo, 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.
Re: Maybe we shouldn't be reviewing all this code
#20This 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…
> Pair programming once in a while can be incredibly valuable.
> a world of stress and overstimulation
yeah so I think the thing here is that one of these is an objective outcome of pairing, and the other one is a personal preference. Which is a valid preference, but it does nothing to refute the fact that pair programming is a great solution for the issues laid out in the article.
I don't particularly like writing tests, but that doesn't stop me from doing so. I think we should think about pair programming like we think about tests: a necessary part of the process, and something most companies don't do enough.