I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck.

If you're writing OSS code or software projects expected to be used by others that may have constraints like that, then by all means the code that gets output matters itself. But even still I'd argue that the cost of writing code manually to get there is still a bottleneck.

In my mind this is what prototyping is for. Just get it working quickly and see if the concept has legs. But be prepared to completely re-write it because the "just make it work" mindset will make it more difficult to change and improve upon in the future.

But when you factor in today's favorite business model of "make it shitty", perhaps this matters very little.

Code you ship vs tooling you use to build the code.

So, the product vs everything that is needed on the way, but isn’t the core.

CI/CD tooling, template population…. Things you write a use once/use few script for.

I typically end up with a library of tools to deal with repetitive finicky tasks.

systems vs application code