Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Code review for CRUD apps is largely something you can hand off to a council of sub agents. Code review for a system whose business logic is not obvious within the codebase? Currently none of the prescribed steps in TFA solve for a peer looking at it with fresh eyes.
    by levl289
  • > “ Shift the judgment left …shorten feedback loops.[…] Take the things we say code review gives us. If we want to explore alternative solutions […] If we want knowledge transfer […] If we want junior engineers to learn how experienced engineers think […] If we want collective ownership, […] If we want architectural alignment […] And if we’re reviewing code for formatting, linting, known security problems or things that can be deterministically tested […] Review by exception None of this means nobody ever reviews code.”

    I don’t program as a “hired programmer”, but rather use programming in my work. That said, reading this list i’m at a different takeaway— I’m thinking “code review” is a catchphrase for a bunch of reasonably different tasks.

    by xtiansimon
  • i do find it deeply funny that a polemic against peer review has an AI generated header image with easily identifiable problems (notebook contents upside down, one child is about to cut her hand with scissors, the other is building a geometrically impossible "lego" structure). if only it had been reviewed by someone else before publishing!
    by wgreenberg
  • For a second I thought this was Fowler posting but it's actually the CTO. Look if not reviewing code works I'm sure we'll see startups and new companies pushing it to the max.

    I'm at a startup myself and we make judicious decisions about what to review and what doesn't need review. Our core systems go through code review - alignment is always built up early anyways.

    by humbleharbinger
  • At 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.
    by ramshanker
  • 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 looking over your shoulder is a world of stress and overstimulation that I (and I suspect many others) will not stand for.

    by Arainach
  • > If we want to explore alternative solutions, I’d rather do that before implementing one of them.

    Sounds cute. But you won't know what any of them really are until you've built at least one of them. You can write specs and have meetings for years and you'll still miss something fundamental about the approach that will be discovered in the first hour of building.

    by singpolyma3
  • I think with the velocity of AI generated code, that's not even an option. There's no way code reviews can scale. We will need better tools for AI reviews, but also a direction that I think will become critical - knowing how to drive human attention where it is really needed. This seems to me one of the major parts that are missing today. We should know when a review is critical and when we can skip it.
    by margolis20

Explore Birbla archives