One thing I don’t see developers talking about much is that if your job is to only read code instead of writing it, how do you expect to stay good at reviewing code if you never write it?
I only speak for me but when I review code I need to dig into my own experience writing and and remember what works and what doesn’t that I’ve internalized over years of writing and manually debugging code. Take that out of the equation and I wouldn’t be good at reviewing code for long.
I used to write a lot of C++ back in the day, and I can still read it and understand it for the most part but I would never be able to effectively review anything non-trivial. I just don’t have enough recent experience writing it myself to have internalized all of the obscure pitfalls and gotchas. And just vommitting out some C++ from a bot and just having it redo things until it has the appearance of working correctly isn’t gonna help me with that.
“My job now is just reviewing code” is such an extremey short-sighted view I’m terrified for the future where nobody understands anything anymore. I’m sure OpenAI and Anthropic would love this though.
And yeah, reviewing code is one of the more tedious and unfun parts of the job why would I want this?
One of the most annoying parts of my job is my supervisor who used to be a dev but became a manager years ago. He doesn’t really understand the codebase enough anymore and I spend so much explaining basic things to him now it actually hinders our productivity when he wants to “contribute”. And let me just say that getting a Claude sub for the whole team hasn’t helped this at all.
And one last thing - every single engineer I know that needs to maintain a Stripe integration hates them with the power of a million suns.
>how do you expect to stay good at reviewing code if you never write it?
What exactly does "writing code" mean?
Are you telling me I have to write for loops and if elses forever?
Totally agree with this. When I review code I don't build a strong mental model of the system, and I think you can only really do that by solving the problems that arise during the creation of the system yourself. I'm optimistic the pendulum will swing away from the "hand off a spec to an agent(s)" and back towards engineers being engaged and directing LLMs to implement/optimize smaller, more specific pieces of code, with most of the direction being determined by the user