My experience from developing products and services across many stacks, in many fields, and in organizations ranging from the small (5-20 engineers) to the larg

My experience from developing products and services across many stacks, in many fields, and in organizations ranging from the small (5-20 engineers) to the large (1000+ engineers) it seems the same pattern always emerges: 1. Setting up your development environment typically amounts to following some perpetually out-of-date check list of things you have to do 2. Setting up the development environment specific to some project typically amounts to following some perpetually out-of-date check list of things you have to do 3. Painfully figuring out why 1) and 2) aren't really working out, and what's missing from those checklists 4. Not updating the checklists through all that ad-hoc stumbling, mostly because you imposter syndrome makes you think the problem is you and not the lists 5. Finally getting to work on things, making small incremental changes to your environment as you go 6. Realizing that the small incremental changes you make actually makes things break when you try to integrate or deploy your work, because the parity between local dev and CI and live environments just isn't there 7. Having some coffee and lament the state of affairs with your co-workers, yet not really do anything to change things; either because you can't really get anywhere in due time (1000+ engineers kind of organization) or because the law of the jungle dictates you have to keep shipping(tm) (5-20 engineers kind of organization) so there's never any time to deal with the debt that just, keeps, building 8. Cry yourself to sleep There are minute differences, but this is the general pattern I've seen through my decade long experience as a software engineer. An important aspect of why this is – I think – stems from thinking your project or setup is a unique snow flake. It's really not. What you're doing is probably not earth shatteringly new and exciting, and even if it is, most of the things you do to get you there aren't. We are all standing on the shoulders of giants, but instead of realizing that and codifying all that knowledge into tooling we can just rely on, we seem to keep thinking that if only we have full control over things we'll be fine. Then there's the other side of that coin, which is to say you don't ever want to have control (for whatever reasons,) and so you hand over everything services that'll build and deploy things magically for you, so long as you have the proper configurations. The promise of those offerings are alluring, and when they work it's great, but inevitably you end up with configuration no longer being best practice, or formats change, or the service pivots; so promises are broken. My feeling is that the answer as usual probably lies somewhere in the middle of having full control, and relinquishing most or all of it. If I understand things correctly, straddling this divide is what Otto wants to do, and Just Work(tm) for the 80% (perhaps more like 99.99%?) of projects that aren't unique snow flakes. The others aren't the target market, and for them the tooling already exists in various forms anyway. It's an ambitious goal; sure to be fraught with edge cases and rabbit holes. I hope it works out.