Managers are expected to say that we should be productive yet they're responsible for the framework which slows down everyone and it's quite clear that they're perfectly fine with this framework. I'm not saying it's good or bad because it's complicated.
Every layer of review makes you 10x slower
121–130 of 339 posts
Re: Every layer of review makes you 10x slower
#122A lot of this goes away when the person who builds also decides what to build.
Re: Every layer of review makes you 10x slower
#123Communication overhead is the #1 schedule killer, in my experience.
Whenever we have to talk/write about our work, it slows things down. Code reviews, design reviews, status updates, etc. all impact progress.
In many cases, they are vital, and can’t be eliminated, but they can be streamlined. People get really hung up on tools and development dogma, but I've found that there’s no substitute for having experienced, trained, invested, technically-competent people involved. The more they already know, the less we have to communicate.
That’s a big reason that I have for preferring small meetings. I think limiting participants to direct technical members, is really important. I also don’t like regularly-scheduled meetings (like standups). Every meeting should be ad hoc, in my opinion.
Of course, I spent a majority of my career, at a Japanese company, where meetings are a currency, so fewer meetings is sort of my Shangri-La.
I’m currently working on a rewrite of an app that I originally worked on, for nearly four years. It’s been out for two years, and has been fairly successful. During that time, we have done a lot of incremental improvements. It’s time for a 2.0 rewrite.
I’ve been working on it for a couple of months, with LLM assistance, and the speed has been astounding. I’m probably halfway through it, already. But I have also been working primarily alone, on the backend and model. The design and requirements are stable and well-established. I know pretty much exactly what needs to be done. Much of my time is spent testing LLM output, and prompting rework. I’m the “review slowdown,” but the results would be disastrous, if I didn’t do it.
It’s a very modular design, with loosely-coupled, well-tested and documented components, allowing me to concentrate on the “sharp end.” I’ve worked this way for decades, and it’s a proven technique.
Once I start working on the GUI, I guarantee that the brakes will start smoking. All because of the need for non-technical stakeholder team involvement. They have to be involved, and their involvement will make a huge difference (like a Graphic UX Designer), but it will still slow things down. I have developed ways to streamline the process, though, like using TestFlight, way earlier than most teams.
Re: Every layer of review makes you 10x slower
#124One thing that often gets dismissed is the value/effort ratio of reviews.
A review must be useful and the time spent on reviewing, re-editing, and re-reviewing must improve the quality enough to warrant the time spent on it. Even long and strict reviews are worth it if they actually produce near bugless code.
In reality, that's rarely the case. Too often, reviewing gets down into the rabbithole of various minutiae and the time spent to gain the mutual compromise between what the programmer wants to ship and the reviewer can agree to pass is not worth the effort. The time would be better spent on something else if the process doesn't yield substantiable quality. Iterating a review over and over and over to hone it into one interpretation of perfection will only bump the change into the next 10x bracket in the wallclock timeline mentioned in this article.
In the adage of "first make it work, then make it correct, and then make it fast" a review only needs to require that the change reaches the first step or, in other words, to prevent breaking something or the development going into an obviously wrong direction straight from the start. If the change works, maybe with caveats but still works, then all is generally fine enough that the change can be improved in follow-up commits. For this, the review doesn't need to be thorough details: a few comments to point the change into the right direction is often enough. That kind of reviews are very efficient use of time.
Overall, in most cases a review should be a very short part of the development process. Most of the time should be spent programming and not in review churn. A review serves as a quick check-point that things are still going the right way but it shouldn't dictate the exact path that should be used in order to get there.
Re: Every layer of review makes you 10x slower
#125Earlier quoted context omitted.
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…
People always makes mistakes. Like forgetting to include a change. The point of PRs for me is to try to weed out costly mistakes. Automated tests should hopefully catch most of them though.
The point of PRs is not to avoid mistakes (though sometimes this can happen). Automated tests are the tool to weed out those kinds of mistakes. The point of PRs is to spread knowledge. I try to read every PR, even if it's already approved, so I'm aware of what changes there are in code I'm going to own. They are the RSS feed of the codebase.
Re: Every layer of review makes you 10x slower
#126That’s because most teams are doing engineering wrong.
The handover to a peer for review is a falsehood. PRs were designed for open source projects to gate keep public contributors.
Teams should be doing trunk-based development, group/mob programming and one piece flow.
Speed is only one measure and AI is pushing this further to an extreme with the volume of change and more code.
The quality aspect is missing here.
Speed without quality is a fallacy and it will haunt us.
Don’t focus on speed alone, and the need to always be busy and picking up the next item - focus on quality and throughput keeping work in progress to a minimum (1). Deliver meaningful reasoned changed as a team, together.
Re: Every layer of review makes you 10x slower
#127Earlier quoted context omitted.
Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way…
>Do people really argue about variable names? Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs. The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.
The greatest barrier to understanding is not lack of knowledge but incorrect knowledge. That's why good names matter. And naming things is hard, which is why it makes sense to comment on variable names in a review.
Re: Every layer of review makes you 10x slower
#128Earlier quoted context omitted.
I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.
Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it. 1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.
Software engineers are pushed to their limits (and beyond). Unrealistic expectations are established by Twitter "I shipped an Uber clone in 2 hours with Claude" forcing every developer to crank out PRs, managers are on the look out for any kind of perceived inefficiency in tools like GetDX and Span.
If devs are expected to ship 10x faster (or else!), then they will find a way to ship 10x faster.
Re: Every layer of review makes you 10x slower
#129As they say: an hour of planning saves ten hours of doing. You don't need so much code or maintenance work if you get better requirements upfront. I'd much rather implement things at the last minute knowing what I'm doing than cave in to the usual incompetent middle manager demands of "starting now to show progress". There's your actual problem.
[flagged]
Re: Every layer of review makes you 10x slower
#130Earlier quoted context omitted.
Which is a thing that depend very much on team culture. In my team it is perhaps 15 min for smaller fixes to get signoff. There is a virtuous feedback loop here - smaller PRs give faster reviews, but also more frequent PRs, which give more frequent times to actually check if there is something new to review.
Does your team just context switch all the time? That sounds like a terrible place to work.
Similar in my team and I don't feel like there's much context switching. With around 8 engineers there's usually at least one person not in the middle of something who can spare a few minutes.