I've been writing a lot of code for the past 6 months. I have to admit, it is a welcome change from Word documents and PowerPoint presentations. Java, unlike text and graphics has a clearer definition of correct and finished. But, like text and graphics, the definition of done isn't finite. There is usually a bit more polishing you can do. Another way to factor the code to make it a bit more tidy. And that's something I've been doing a lot of in this 6 month period. Factoring, rearranging, trying to follow the spirit of my blog, add simplicity. It's done when there's nothing left to remove.
I've felt for a long time now that we don't view software engineering correctly. Even that term, "software engineering", illustrates a root cause of the problem. Engineering, in all disciplines, is viewed as the opposite of artistic. I've had these conversations with my "creative-type" friends and it's a stereotype that is common. Yet I view all engineering disciplines as art with constraints. Just like a photographer is bounded by the limits of the lens and the film (or digital sensor), software engineers are constrained by the boundaries of the programming language and the processing power of the target system. But that doesn't make software engineering any less creative or artistic.
Given that though, we teach software like we teach math. Artists are taught not only about the mechanics of their craft but also the art. We stop software engineering after the mechanics. Languages are covered in detail. Code factoring is taught with precision, not as the soft skill that it is. And then we enter the workforce. If we're lucky, we run into some mentors that help us learn our craft. If we're not, we bang out code to project deadlines and while that gives us experience, it doesn't give us skill.
Getting a chance to focus on writing software for the past few months, gave me a chance to understand this reality. I do not make clay pottery but I have friends that do. And what they relate is a feel that you develop for the clay. You come to know when the clay is the right consistency. How much pressure to apply to achieve the desired thickness. And this can only be learned by doing. This is the way software is for me. There's a feeling when the software is coming together well. It isn't something that can be expressed in precise terms, codified into a set of steps. It's an emotional response to the components falling into place cleanly. In other words, it's art.
I thought about how I learned to write software. I was fortunate enough to be exposed to some very good software engineers. They guided me early in my career. Helped me understand the difference between okay, good, and great software. In other words, I spent time as a journeyman. Given problems to solve, code to write, and usable feedback on how I could make my software better. Of course I also learned a lot the hard way. Ideas that seemed good at the time, only to discover they had a serious shortcoming. And of course, I rarely settle on a solution to a problem until I'm completely satisfied with it. We all see the same problem repeatedly through our career and I take that as an opportunity to continue to adjust and refine the solution until I know it is solved as cleanly as possible.
And of course, that is what an artist does. Express oneself in a way that provides satisfaction. Refine the expression until it is succinct and yet powerful. This is what software should be. Concise solutions to business problems that can illicit a positive emotional response from others in your trade. If you don't have emotional responses to software, perhaps this isn't your craft. For that is the only way you can move past just creating code to crafting code.