Software Development as Craft

2021-06-19

Software development is a job — but it is also a craft. Unless you are fortunate enough to be able to dictate technological choices at your job, many of the software tools you use at work may have been selected for you. Depending on the type of development you do, this might include your operating system, your IDE, the programming languages and frameworks you use, and others.

Treating development as purely a craft however, there is no reason you shouldn’t be able to play around and tinker as much as you like. Because you are not maximizing profits, you are free to use even an obtuse variant of a dated programming language or to write an application entirely on your iPad. Many developers first took to programming through an affinity for tinkering with software, and as they move from being a student or hobbyist to a real developer job, there is a tendency to trade in an attitude of exploration and play for maximizing productivity and monetary gain.

Work or play?

Over the years, I have noticed people discuss software development as a craft XOR a job. But I don’t think it is especially novel to think of it as both. Something that I found works for me is to maintain a clear distinction of when I am doing development as one or the other. Keeping this distinction of craft or job in the back of my mind tends to simplify decisions like the following:

• Which scripting language should I use to automate this functionality: PowerShell or Python?
• This seems like a fun thing to automate. Should I do it?
• Should I go for my Masters in Computer Science?

In my experience, the problem with blurring the line between software development as a craft and software development as a job is the constant battle between productivity and play. And by identifying clearly in my mind which of the two an upcoming task falls under, I am able to reach a satisfactory decision more quickly.

When you’re on someone else’s clock, of course you might need to put personal preferences aside to maximize the productivity of the team. But when you’re off work — perhaps even when you’re writing something that might be useful at work — then by all means, go with what you enjoy most.

Make time for play

This leads to my second point: if it sounds like something you want to do, take time outside of work to practice software development as craft. This means focusing on play, exploration, and personal fulfillment rather than productivity.

If you’ve always had an eye on learning a quirky programming language but it’s not likely to be a hot commodity on the job market, do it anyway. If you want to see whether you can churn out a non-trivial app using just your iPad, give it a try. And if you are considering going for a Masters even if it’s unlikely you’ll get a high enough raise to make it worthwhile, maybe just do it for learning and personal fulfillment.

TL/DR

Knowing the distinction between software development as craft and as work — and tracking which one my tasks fall under has helped me with certain kinds of decision-making. Making time to do software development as play has helped me sustain a high level of enthusiasm and interest in my field of work.