Approaching Software as a Craft, then as a Engineer.
Craft first, engineering second.
There’s probably a lot of software programmers, developers, and engineers who will take issue with this. That’s kinda the point. Software should be approached as a craft first, then a engineering problem second. There are so many ways this is true, it’s going to be hard to touch them all. I might be biased but who cares, besides, you are more then welcome to be wrong! I have strong feelings about software as a craft because it affects every aspect of how we write code. The approach you choose will ooze from your code, relationships, teams, interactions, and your career. A software project reflects the people and ideals that built it.
Why is software a Craft first?
What kind of products do you like to buy or use? When looking for something that you care and are passionate about where do you turn to first? This should be obvious to most people. When it’s something close to your heart we all look for things made by someone who cares about what they are making. It’s their craft. Handmade, handcrafted, blood, sweat, tears and their soul poured into making a beautiful product. It’s because they love what they do and what they are producing.
Software is no different. You want something that rolled of the end of an assembly line and ends up on the Walmart shelf? Or do you want something that was forged and thought through by someone who was paying attention to the details?
Software as a Craft is a better end product.
Software made by someone who loves what they are doing is always going to be better. When I approach a new data pipeline there is always a sense of excitement, a new problem, the endless possibilities laying ahead. There is something beautiful about a blank PyCharm project that slowly starts to take shape and form, and re-form, code being beaten, tested, smoothed into something unique and clean.
For people who just show up everyday to do the same thing over and over, it’s just a job. And guess what, their code will always display that, no passion. Then there are those who are more worried about the academics then the pragmatic approach will produce software that matches their personality. Dry, boring, rough around the edges, and generally not nice to be around.
Is Engineering Important?
Of course engineering is important. The best intentions if poorly laid and planned will end in ruin. If your just bad at programming or lazy then there isn’t much more anyone can do. I rarely find this to be the case though. People who are “bad” at writing code aren’t really bad at writing code. They are just not enjoying their work enough to care about what the code is going to look like in the end. They do enough to not get fired and get the minimum viable product finished with the least amount of work. They should be working at the Walmart of software.
Anyone who approaches software as a craft will end up caring about the engineering side of their code. Someone who is learning and perfecting their craft will make it their business to understand the ins and outs of software design patterns and technologies. The difference is that they will be pragmatic in their approach, not just tied to a certain ideology because that is how their professor told them to do it.
Software Crafters learn from other Crafters.
One of the best indicators that someone is a crafter of software is that they learn from other masters of the craft. If you checked the websites they visit most or their Kindle library you would find books and blogs that are all about writing code in their area of interest. People who love to write code never think they have arrived, or perfected their craft. They are a crafter because there is a desire to learn more and look under the next rock.
A software crafter looks to and chases after others in a constant push to learn and grow in their software design and though processes.
In Conclusion
Software design is a craft, and then a engineering discipline second. The only people who would argue otherwise are the “too smart for everyone else” engineers trolling around on StackOverflow, it’s the person on the software team no-one really wants to work with because they are generally unpleasant, just like their code.
Choose to love your craft, your code, treat every piece like a work of art, something that is alive and should have character. If you approach software design with these ideals you will become better, your code will better, more usable, longer lasting, and useful to others.