[dead]
Every layer of review makes you 10x slower
261–270 of 339 posts
Re: Every layer of review makes you 10x slower
#262Earlier quoted context omitted.
> Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.
there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate. agile approaches are based on the quick implementations, redone as needed. my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as nee…
This approach also accounts for the truism that "the customer doesn't know what they want until they don't see it in the final product".
Re: Every layer of review makes you 10x slower
#263But 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…
I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable…
As far as I'm concerned if I approved the PR I'm equally responsible for it as the author is. I never make nitpick comments and I still have to point out meaningful mistakes in around 30% of reviews. The percentage has only risen with AI slop.
Re: Every layer of review makes you 10x slower
#264Earlier quoted context omitted.
Why would I care if my code is reviewed quickly? If the answer is some variant of "I get punished if I don't have enough changes merged in fast enough," that's not helping. From the other side, it's having someone constantly breathe down your neck. Hope you don't get in a flow at the wrong time and need to break it so Mr. Lumbergh doesn't hit you up on Teams. It just reeks of a culture of "unlimited pto," rigid sched…
Because it's basically async pair-programming. You do a lot of small changes ( Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code. Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation…
IMO code reviews are not pair programming. By the time I've raised an MR, it's already perfect. I've had multiple client calls, talked to my team about design, unit tested it, tested it on a container environment, thought about it.
So it really doesn't matter when the review gets done. I mean, even a week and it's fine.
Re: Every layer of review makes you 10x slower
#265Earlier quoted context omitted.
>Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions. Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk? Lemme guess, you cargo culted some "best practices" to offload risk awareness , so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.
> Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk? I guess the answer (if you're really asking seriously) is that previously when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension. So if a change was implemented, the developer would deliver it as a functional unit that…
> when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension
Oh, for sure. Those people making electro-mechanical computers at the end of the 19th century certainly did that a lot.
Re: Every layer of review makes you 10x slower
#266Earlier quoted context omitted.
Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.
I’ve started pair programming with Claude and it’s been pretty fun. We make a plan together, I type the code and Claude reviews it. Then we switch.
You’ve made the analogy but I don’t think you’re actually doing an analogous thing. I think you’re just talking about code review.
Re: Every layer of review makes you 10x slower
#267But 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…
>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 hell in one sentence
I have seen the future, and it is a robotic boot pushing a human neck to the left.
Re: Every layer of review makes you 10x slower
#268But 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…
actually you don't need reviews if you have a realistic enough simulation test environment that is fully instrumentable by the AI agent. If you can simulate it almost exactly as in production and it works, there's no need to code review.
to move to the hyperspeed timescale you need reliable models of verification in the digital realm, fully accessible by AI.
Re: Every layer of review makes you 10x slower
#269Earlier quoted context omitted.
Having data model changes be a part of regular deployments would give me persistent heartburn.
It's why you always have a rollback plan. Every `up` needs to a `down`.
If you do that, it expands your test matrix quadratically.
So, it makes sense if you have infinite testing budgets.
Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good.
I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability.
Would love to hear of an example.
Re: Every layer of review makes you 10x slower
#270But 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…
Well we can't not review things, because the workflow demands we review things. So we hacked the process and for big changes we begin by asking people who will be impacted (no-code review), then we do a pre-review of a rough implementation and finally do a formal review in a fraction of the time.