> I do read the code, but reviewing code is very different from producing it, and surely teaches you less. If you don’t believe this, I doubt you work in software.
I work in software and for single line I write I read hundredths of them.
If I am fixing bugs in my own (mostly self-education) programs, I read my program several times, over and over again. If writing programs taught me something, it is how to read programs most effectively. And also how to write programs to be most effectively read.
I learn the most from struggling through a problem, and reading someone’s code doesn’t teach me all the wrong ways they attempted before it looked like the way it now does.
I was thinking in situations where a coworker might send me something to review, and I might have thought "hmm, I wouldn't have done it like that, but this is a great way to do it too". Also, a good source of teachable code is to participate in a programming contest, and then review the repositories of the teams who scored better than me after the contest.
I agree that if I don't already know how to implement something, seeing a solution before trying it myself is not great, that's like skipping the homework exercises and copying straight from the answer books.
This is why tutorials in programming don't really teach much because you get the finished version. Not all the wrong steps that were taken, why they failed, what else was tried.
These steps are what help you solve other issues in the future.
This is why I still haven't embraced agents in my work but stick with halfway manual workflow using aider. It's the only way I can keep ownership of the codebase. Maybe this will change because code ownership will no longer have any value, but I don't feel like we're there yet.
If I am fixing bugs in my own (mostly self-education) programs, I read my program several times, over and over again. If writing programs taught me something, it is how to read programs most effectively. And also how to write programs to be most effectively read.
Reviewing code is absolutely different from writing it, and in my opinion much harder if the goal is more than surface level understanding.
This is what I am still grappling with. Agents make more productive, but also probably worse at my job.
> reviewing code is very different from producing it, and surely teaches you less
Maybe he meant "reviewing code from coding agents"? Reviewing code from other humans is often a great way to learn.
I interpreted this as not as good a way to learn.
I learn the most from struggling through a problem, and reading someone’s code doesn’t teach me all the wrong ways they attempted before it looked like the way it now does.
I was thinking in situations where a coworker might send me something to review, and I might have thought "hmm, I wouldn't have done it like that, but this is a great way to do it too". Also, a good source of teachable code is to participate in a programming contest, and then review the repositories of the teams who scored better than me after the contest.
I agree that if I don't already know how to implement something, seeing a solution before trying it myself is not great, that's like skipping the homework exercises and copying straight from the answer books.
This is why tutorials in programming don't really teach much because you get the finished version. Not all the wrong steps that were taken, why they failed, what else was tried.
These steps are what help you solve other issues in the future.
This is why I still haven't embraced agents in my work but stick with halfway manual workflow using aider. It's the only way I can keep ownership of the codebase. Maybe this will change because code ownership will no longer have any value, but I don't feel like we're there yet.