The Reviewer Isn't the Bottleneck
(rishi.baldawa.com)
from codeinabox@programming.dev to programming@programming.dev on 10 Mar 10:30
https://programming.dev/post/46970940
from codeinabox@programming.dev to programming@programming.dev on 10 Mar 10:30
https://programming.dev/post/46970940
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.
#programming
threaded - newest
Writing lines of code was the bottleneck before. Vetting them is the bottleneck now, if LLMs are involved.
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.
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
Writing the requirements is what takes time.
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?
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.
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.
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.
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.
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.
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.
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
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.
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.