When you call the humans who keep production safe “the bottleneck” you’re painting a very specific picture. The reviewer as the obstacle. The gate as friction. Something to route around. Cue in the Balrog scene from Lord of the Rings. That picture determines what you build. The tools to remove reviewers look different from tools to support them.
The Reviewer Isn't the Bottleneck
https://rishi.baldawa.com/posts/review-isnt-the-bottleneck/
14 Comments
Michal@programming.dev · 19 pts · 170d
If review is the "bottleneck", I'd say the code needs to be optimized for review time. Ship small increments of easy to understand code, touching as small surface as possible, and make sure it passes the review with no need for corrections and re-review.
robojeb@lemmy.world · 8 pts · 170d
Ideally you can do that, but even the most well designed software ends up needing a larger refactor/reorganization that will touch a large portion of the code base.
My boss likes to say "you aren't qualified to design something until you have built it once" which I do feel rings true. This inevitably leads to at least one major redesign for a significant codebase.
Kissaki@programming.dev · 2 pts · 169d
Some people are more receptive to these kinds of things than others. Not only in terms of open mind but also how they are able to apply it (or capable of applying it?).
I wish agreeing on intentions and improvements in terms of scoping and description would be met. Same with unnecessary, obvious issues showing up costing review time and iterations. I just don't get how these are issues - but they are - for or with some people.
pinchy@lemmy.world · 9 pts · 169d
When the review bottleneck is solved by being bypassed the client/end-user becomes the "bottleneck". Why can’t he just approve whatever I’m throwing at him and call it a day? \s
ulterno@programming.dev · 1 pts · 168d
Might as well just give me their money and call it a day. No real product required.
I can then "pay" that money to 10 other companies for nothing and then the govt. can pay my client for contracts of nothing.
And everyone can be a billionaire.
ulterno@programming.dev · 1 pts · 168d
Because you arr telling the dev to sign off on code made by something that is at best, a code-writer that doesn't just do what you tell it to do.
FishFace@piefed.social · -3 pts · 170d
Writing lines of code was the bottleneck before. Vetting them is the bottleneck now, if LLMs are involved.
tyler@programming.dev · 9 pts · 169d
writing lines has never been the bottleneck, that's only something a junior would say. The bottleneck is always requirements: changing, understanding them, making sure you don't miss test cases before writing any code.
FishFace@piefed.social · 0 pts · 169d
No, the bottleneck is not always requirements. Understanding requirements is a prerequisite to writing correct code, but it takes a fraction of the time.
Obviously different domains have different complexities of requirements and code which changes the ratio
alsimoneau@lemmy.ca · 2 pts · 169d
Writing the requirements is what takes time.
FishFace@piefed.social · 3 pts · 169d
Instead of spending 4 weeks writing requirements and 1 week implementing them, have you tried spending a day guessing at requirements, half a week writing a prototype, and then asking the customer if it works for them?
Have you ever worked on a tools team where your customers are internal and your developers are also customers and so know the requirements inside-out?
ulterno@programming.dev · 1 pts · 168d
Hehe! I have.
And what took the longest was for me to get used to the dual versioning of QML modules and fixing the UI code that was partially using stuff from both versions.
Business logic was pretty small for me but that was because other engineers had already written most of it in Maths.
ulterno@programming.dev · 1 pts · 168d
Yeah, e.g. writing UI code takes a lot of time, while it tends to be pretty simple overall and that's why we have so many UI toolkits, to reduce the amount of writing required for UI.
TrippinMallard@lemmy.ml · 4 pts · 169d
The bottleneck was human ego and people not actually having enough experience for designing complex systems. Or people without enough experience setting up people systems that interfere with those who can actually design the systems.