| I agree with the sentiment but not the examples: > spend days setting up a CI/CD pipeline This should/does take minutes. It's like 15 lines of YAML for most CI providers. Ideally it's a part of the template you use for new code. > use a cool new library they just found Integrating a useful lib that makes the code simpler should be done from day 1. Don't code your own platform lib and switch to SDL halfway through development. Don't code your "tracer bullet" on Win32 API calls when you're going to be using libuv. And like CI/CD, integrating libraries into the build should be painless > if it’s software that’s going to ship, it needs tests Oftentimes the tests are the only way you know if the code is even minimum viable, even manages to be the "tracer bullet". Ok you implemented a new feature, what says the code even runs and doesn't segfault immediately if there's not a test to build the new code into and run? Not comprehensive tests, but something |
Should if you discount tool selection, learning tools, managing access control, deal with technical and organization imposed constraints, documentation and alignment across the team.