I basically use the same kind of hesitance around automation when making programming decisions: 1. Automate for spec and quality first(make it work, get it rig

I basically use the same kind of hesitance around automation when making programming decisions: 1. Automate for spec and quality first(make it work, get it right, make it fast) 2. Add opt-outs(write to the limits of your debug system, apply the Principle of Least Power, use common formats and protocols) 3. Automate the easy parts first and limit scope(short build scripts, mockup UI, placeholder systems, set scalability targets, etc.) Software projects are ultimately about the full automation of a complex data processing task. The difficulty is in learning enough about the problem and knowing where to set boundaries. Writing software that "does anything" is one of those philosophical black holes that is easy to fall into in small increments, because the system can surely always do more, and you might have a library that solves 90% of the problem...