My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.
Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).
The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.
It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.
But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of my day to day work are the things you mentioned as being serialization points. The time I take to figure out what needs doing, what the best approach would be, making sure it was actually the right thing to have done in the first place once I'm done, all that stuff. I use AI assistance for those tasks too but it's not the same effect as when I just hand off the pure implementation phases. So it winds up being "faster" and you'll have to pry my AI assist tools out of my cold, dead fingers - but if I'm being honest with myself by *that* metric it's not a huge gain.
People. Already. Know. This.
It hasn't been the bottleneck for decades for the majority of products.
I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.
Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.
> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.
> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.
The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)