Like anyone, I reflect current situations and problems back to things I’ve done, other problems I’ve solved, or more generally what I’ve learned. After I graduated from college, one of the things I spent a lot of time learning about was metalworking. Specifically the art of raising, which is a technique for taking sheet metals (iron, copper, steel, silver, etc) and forming it into 3 dimensional objects by working that over various forms, compressing and thining the sheet with hammer blows. You also have to periodically softening up the work by annealing (so it doesn’t crack and sunder). I still keep the copper flask that I formed from my earliest classes – it’s sitting on a shelf of artwork and plants, a reminder to me of persistence and functional beauty.
In retrospect, one of the most valuable things that I learned in using the knowledge from that class was that when you’re creating something the time to form up the rough object is pretty quick. It is the “finish work” that takes forever. The goal was often a smooth, shiny surface (although I enjoyed the dimpled hammer-beaten look myself) – and the reality is that after you’ve spent the time with the stakes and hammers, if you want that shiny surface, you’re going to have to work your butt off to get it. Cleaning, sanding, and polishing – another incremental process where it gets progressively better. That “finish work” as I like to call it, takes a good 80% of the overall time in making the piece.
Advance 20 years – I still have a propane forge and shop anvil, a few stakes, and a lovely collection of hammers. And most of my creative time is now going into software projects.
I see the same pattern play out: getting the project up and working, just operational – which is an awesome feeling – is just the first 20%. If you want the work to be a finished piece, and not just something you say “heh, yeah – I could see how that might work”, then you’re in for the remainder. Cleaning, sanding, and polishing in the software world is writing tests and fixing the operations so that they’re consistent and clear. Clear the technical debt so that future advances won’t be stunted from the start. Write documentation so that others can use what you made. Write notes to yourself or other developers so that you’ll have a clue of what it was meant to do when you come back to it in a year. It might also be making and refining a user interface (CLI, gui, or whatever) that work flawlessly, shares relevant information, and are accurate and beautiful in their own right.
The deeper take away that’s worth noting – the 80% there for polishing – it’s to make the object work for someone else. In a software world that’s often driven by user feedback. You had better be ready to listen – because (like with art and craftsmanship) it may or may not match your viewpoint and world view. It is inherently subjective, which can make it a real struggle for more analytically minded people.
My recommendation is to take the time, get the feedback, and refine your work. In the end, I think we all want things that are both beautiful and functional, and it takes work and feedback to get there. And that is, to my mind, the essence of the craftsmanship of the work.
Rhonabwy 