I like to imagine it as a sort of volume vs surface area problem.

The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume.

As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.

there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each

the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to continuously trick their employees into productivity

I have been thinking about _how_ to build good (and stable) software a lot in last 10 years. Tried many approaches and verified them one by one. In my experience this is the ultimate fix. It may not work for big tech companies, but for most projects, it is much better to choose this approach.

Collaborative efforts to maximize good results, and predictable gains for each participators.

Thanks for sharing your experience, I feel like this is not very well resourced territory for our industry

Btw you may find Graber/Wengrow's recent Dawn of Everything to be an inspiration for how these sort of structures could scale up to larger groups of people than conventionally thought historically possible

What's the ultimate fix?

tbh this is a big weakness of the left (in terms of its marketing at least) that I'm trying to understand better. one idea is that whatever solutions we conceive of now, are constrained within the understanding we've gained living under capitalism/state power etc., and that we need to dismantle the current system incl exploitation/keeping the majority of peoples time/energy locked up in wage labor/systemic lack of freedom to disobey an order or to freely relocate/etc, before we can explore a wider range of solutions. But I get how this is unsatisfying, sounds like it leaves a vacuum for bad/regressive solutions to come in, but this is something I'm only starting to learn about.

That's why I appreciated the new Graeber/Wengrow, it finds a wealth of prev overlooked ways that humans have lived, post discovery of agriculture, in large societies and with greater freedoms and prosperity defined in new ways besides within the terms of economics. This gives me optimism that capitalism/states aren't necessary or inevitable and that we might be stuck on this shitty plateau having convinced ourselves it's the only realistic one

> no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy

This probably depends on the team and practices that are used within it.

Most code changes in my current team are reviewed within an approximately an hour, deployments are a bit more tricky, especially if you have external clients with their own environments and deployment procedures.

Honestly, CI/CD cycles for the internal dev/test environments take anywhere from 5-20 minutes (with the heavier tests being run separately) and the technical aspects of delivering software (build, test, package, scan, generate docs, send) take around another 10-20 minutes.

It's usually when you have to deal with manual procedures and people that it all slows down.

So, it can be really good to automate as much as you can: code style and warning checks, code coverage checks, dependency date checks, dependency CVE checks, unit tests, integration tests, performance tests, packaging and storing build artifacts, redeployments to whatever environments are permissible (usually automated to dev/test, manual approval against prod).

Ya.. my company does all of that. It's just the people process that makes everything slow. Well, mostly the people process. Having millions of dependencies doesn't help with build and test times either. Usually up to 20 min to run something.

> Having millions of dependencies doesn't help with build and test times either. Usually up to 20 min to run something.

I feel that pain! Honestly working with monoliths and older and larger projects is very demotivating. Now, I'm not saying that you need to go full on microservices either, but working with a few smaller services instead of a single huge one has been a game changer in my experience!

I'm not sure I ever want to go back to the loop of changing some code and then having to wait minutes for the app to launch locally just so I can test something and realize that it's still wrong.

We do use microservices, but even then it's still slow AF. I'm not entirely sure why, I guess just via the code dependencies it includes nearly everything. It's all C++ which probably doesn't help.