Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

Post reply on HN
Print view View original

171–180 of 339 posts

Re: Every layer of review makes you 10x slower

#171

Post by wiseowise »

nananana9 wrote: post #137
nfw2 wrote: post #101

from article: 1. Whoa, I produced this prototype so fast! I have super powers! 2. This prototype is getting buggy. I’ll tell the AI to fix the bugs. 3. Hmm, every change now causes as many new bugs as it fixes. 4. Aha! But if I have an AI agent also review the code, it can find its own bugs! 5. Wait, why am I personally passing data back and forth between agents 6. I need an agent framework 7. I can have my agent wri…

I've been begging left and right, and I've yet to see a single example of this agent-written high-quality quickly-shipped code.

OpenClaw! You just need to slightly change the definition of “good code”. The point of code is to ultimately bring money. The guy got hired by OpenAI and who gives a shit what happens to the “project” next. Mission accomplished.

Re: Every layer of review makes you 10x slower

#173

Post by herbstein »

Swizec wrote: post #31
onion2k wrote: post #22

But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team wh…

> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~1…

> I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

That's cool. Expect to pay me for the availability outside work hours. And extra when I'm actually called

Re: Every layer of review makes you 10x slower

#177

Post by gebalamariusz »

Well, this all makes sense for application code, but not necessarily for infrastructure changes. Imagine a failed Terraform merge that deletes the production database but opens the inbound at 0.0.0.0/0, and you can't undo it for 10 minutes. In my opinion, you need to pay attention to the narrow scope specific to a given project.

Re: Every layer of review makes you 10x slower

#178

Post by steveBK123 »

zingar wrote: post #166
steveBK123 wrote: post #157

Earlier quoted context omitted.

> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for…

It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect…

My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead.

To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report.

Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API.

It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.

Re: Every layer of review makes you 10x slower

#180

Post by srean »

onion2k wrote: post #22

But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team wh…

Bean counters do not like pair programming.

If we hired two programmers, the goal was to produce twice the LOC per week. Now we are doing far less than our weekly target. Does not meet expectation.

Post reply on HN