What’s important when developing software?

When talking to other developers, I can’t help but think we spend too much time on tooling and code perfectionism.

When it comes to tooling, I can’t help but think that the things we’re doing could be fairly easily done if more people knew bash and their language ecosystem’s primary build tool; like NPM, MAKE or Maven. I’d jump from one project to another and then on top of all the CLI interfaces, I also have to learn another subset (or set) of options and configuration structure. This isn’t me being a grumpy old man. This tooling problem has been around for a long time.

These tools generally emerge from the needs of a specific large project or code base. They abstract some of their patterns for building, deploying, and testing then release the tool to the outside world. Sometimes, that tool fills a vacuum that needed filling. In the JavaScript world, Grunt and Gulp have some legitimate reasons for existing; but they didn’t have good reasons for being used in so many places.

Speaking of things popping up in so many places, man “code is craft” is nonsense. Code is engineering. We are building stuff so that it works right for the demands on budget. Crafts are where you appreciate the wood and the grain, the tool and the process. Engineering is a process. We have requirements, budgets, timelines, and business goals. There’s some craftiness in engineering and some engineering in craft, but they prioritize different things.

Getting things done to the required level of resiliency is important. Sometimes, a craftsperson will put their foot down on a quality issue, but it might before for the sake of the craft, code “quality”, or purity. For an engineer, we have to be aware of certain minimum standards that are necessary. An engineer may have to put their foot down for quality, but this quality is often about software resiliency and security where people’s lives, financial well-being, or privacy is at stake. We may have to push back against a customer for their own best interest in real, high stakes matter. This is not diminutive of craft. Some great tools (see paragraphs above) have emerged from the love of code and processes, but ultimately, the tools that stick around did so because they were useful.

This all being said, there’s still a lot of good tooling. There’s still a lot of places where craft-like code and resilient software development overlap; just don’t get too bogged down. Make something that something, get feedback and improve it.