The term "engineering" has a place: to convince non-techie stakeholders to take us seriously and trust our domain expertise. Outside that context, I prefer to

The term "engineering" has a place: to convince non-techie stakeholders to take us seriously and trust our domain expertise. Outside that context, I prefer to think of myself as a craftsman for small projects, and a gardener for large projects. Software never exists in isolation. It is interwoven with countless other hardware and software stacks, and more importantly, the humans that use and maintain it, as well as the organizations and processes those humans inhabit. And every single component in that system is constantly mutating. The true masters of the craft are those who strive to understand and tame this chaos: weeding the garden, but also leveraging that wildness in constructive ways, allowing the garden to grow organically. By making code so readable, flexible, sharable, testable, and durable, that it exists in a non-stop feedback loop with its ecosystem. (Taleb's "antifragility" is a useful mental construct for this ideal.) Most software projects are not run this way, whether due to a lack of expertise, budget, process, or all of the above. But given how easy it is to write bad software (or good software that decays into bad software), I believe gardening is the proper metaphor for non-trivial software systems.