Reviewing human code and writing thoughtful, justified, constructive feedback to help the author grow is one thing - too much of this activity gets draining, for sure, but at least I get the satisfaction of teaching/mentoring through it.
Reviewing AI-generated code, though, I'm increasingly unsure there's any real point to writing constructive feedback, and I can feel I'll burn out if I keep pushing myself to do it. AI also allows less experienced engineers to churn out code faster, so I have more and more code to review.
But right now I'm still "responsible" for "code quality" and "mentoring", even if we are going to have to figure out what those things even mean when everyone is a 10x vibecoder...
Hoping the stock market calms down and I can just decide I'm done with my tech career if/when this change becomes too painful for dinosaurs like me :)
> AI also allows less experienced engineers to churn out code faster, so I have more and more code to review
This to me has been the absolute hardest part of dealing with the post LLM fallout in this industry. It's been so frustrating for me personally I took to writing my thoughts down in a small blog humerously titled
Sample of one, but I find gentle exercise in evening (like walking) isn't a problem. A moderate-to-intense run in the evening does affect my sleep, though.
I don't disagree with this but even walking 4mph @ 87°dewpoint = ⅔ soaked, which feels not gentle. Actual intense exercise in that mug might kill us however.
>A moderate-to-intense run in the evening does affect my sleep, though.
Oddly, I've used short strenuous workouts to combat severe insomnia. More pain is better. It helps when panic is the driver but not for sleep=broken events.
The earlier machines had much higher quality capacitors that are mostly still OK afaik. Consensus (if I may be so bold as to try to represent it) in the Amiga community today is: definitely recap the later Amigas (A600, A1200, A4000, CD32) with their cheaper SMT caps that usually leak and slowly destroy the motherboard, but A1000* and A500 usually don’t need it.
*The caps on the motherboard, anyway. I am not sure about the durability of the internal PSUs. I haven’t bothered to replace anything in either of the A1000s I acquired recently.
That's true. It feels like every other ladder-climbing wannabe out there is also trying to attract powerful people's attention on Twitter et al these days, so I imagine it's much harder to stand out than it was for a kid in the 1970s. But you're not wrong.
I agree it probably was easier once you knew where to find them. Almost every celebrity is accessible through the internet if your megaphone is loud enough.
I also don’t claim to make such effort. I just want to clarify that networking is a conscious skill and not always a result of family connections.
As a reviewer... it really, really depends on how trivial or gnarly the PR is.
If it's a simple change that is obviously correct, I'll try to unblock the author ASAP - often within minutes, even if it interrupts my flow.
If it's a giant PR with lots of risky changes in vital code, an awkward-to-unreadable diff, and/or maddeningly questionable design/coding decisions that require me to think a lot and compose some nuanced, reasoned comments to steer you in a better direction, then, well, you might find yourself nagging me for a review 2 days later. (And I'll probably ask you to split up PRs like this in future, e.g. to separate major refactoring from any logic changes.)
This x1000. It's not about the org, really. It's about what's being changed.
Yes, a lot of large codebases have things that look wrong. They're not always wrong. Trying to clean up what look like cobwebs at the core of a large codebases often means removing things that are there for a reason. The reason is usually counterintuitive and could be documented better. But often only a few people can really evaluate the change.
A small PR is likely to be accepted quickly, and a large PR is likely to take awhile. No one gets upset by that, though.
The flip side is that a small PR to a critical part of the codebase is also likely to take awhile and be treated as "default to no". It's often hard to see that from the "outside", though.
With that said, trying to go the extra mile and make things clear, concise, and better documented than before goes a long way in getting an MR reviewed quickly.
