I think most people think programming is cold, precise, and mechanical. It’s actually creative, perplexing and deeply personal.

— Unknown (from http://discordianquotes.com/quote/think-people-thing-programming-cold-precise-mechanical-actually)

I’ve said similar words many times. I wish more people understood them.

Programming is Creative

What does it mean to be creative? It usually means making something that other’s can see as beautiful, or as unique, but also it means applying your mind to making something real that exists only at first in your mind.

To Create:

1. to cause to come into being, as something unique.
2. to evolve from one’s imagination, as a work of art or an invention.
3. to perform (a role) in the first production of a play or motion picture.
4. to make by investing with new rank; designate: to create a peer.
5. to arrange or bring about, as by intention or design: to create confusion.
6. to do something creative.

The thing that makes something a craft vs a fine art is that crafts have some utility beyond their form, or because of their form, whereas fine art is meant to be displayed.

Both have long traditions and both are necessary for a society.

Beauty exists in many forms, many guises, and beauty exists as such in software in many forms and guises as well. While it is difficult for many to see such things, especially non-programmers, and for many beginners, and even for many very experienced developers, the thing about what they are producing, the code, has form, function, embodies aesthetics (although the rules that apply to that vary), and is the result of a spark of imagination.

Software has use, certainly, and I’d never expect to see a source code listing hanging in the Louvre, it is, however, something that could use more exposure.

As we head deeper into the 21st century, a rallying cry has emerged around the notion that programming is a core life skill. While I am not quite going that far, I do think that it is a skill that can be acquired by many, and put to use by many. It’s not quite in the same arena as being able to do laundry, cook a meal, balance a checkbook, and so on, but it is possible for it to be something enjoyable, useful, and as rewarding as many fiber crafts, or knowing how to fix your car, or playing the piano. No one person needs to know these things, but it sure makes for a better world that someone knows these things, and that they enjoy doing them.

Software development as a profession is not altogether different from being a custom cabinet maker, or a construction worker, or an auto mechanic. Sometimes writing software is just labour. Sometimes it is a labour of love. Sometimes, it is both. And sometimes, it is much, much more.

Programming is Perplexing

One of the key concerns about writing software in earnest (as opposed to doing kata) is that it is primary about solving a problem (or problems). The problem might be the developer’s, it might be some other developer that has the problem, but far and away most software is written with an end user in mind: someone who does not want to write the software themselves, or at least have someone provide them the means to solve their problem.

But one of the other natures of software is that once that problem is solved, once the program is written, it doesn’t really need to be written again. Not that it isn’t: as developers we do recreate solutions to problems over and over. The thing that appeals to many developers though is solving new problems. And new problems are perplexing.

That comes in basically two flavours:

• the perplexity of the domain
• the perplexity of the solution

The “domain” of a solution means what particular knowledge is needed to understand the nature of the problem: the people involved; their vocabulary and jargon; their tasks, steps, procedures; their rituals, beliefs, values; and what already exists in the realm of the solution.

The solution offers its own perplexity because it requires understanding of how to put it together: its pieces, subsystems, libraries, ecosystem, and so on.

The co-mingling of both of these adds yet another dimension of perplexity: how do you connect what those that will be using the program with those that will be writing the program? This is yet another skill, and the lore of software development is rife with tales of how the lack of such skills has caused many problems. Everyone knows about the developer with no social skills, for example.

People often remark about how negative software developers are. I firmly believe this to be a complete misinterpretation of the behaviour they see when proposing something to developers: at heart, most developers are problem solvers, very much akin to puzzle solvers.

If you look at people sitting around a table putting together a jigsaw puzzle, mostly what you’ll observe are people in tight concentration and focus. If you simply look at them outside the context of the puzzle, they look rather perplexed, or even angry, because of this intense concentration. Yet replace the context and it all makes sense.

One of the major issues in non-developers watching developers is that they do not really understand what is happening: at the point when it looks like developers are throwing out objections, or things that sound like your idea won’t work, what they are actually doing is beginning the design in their heads, observing potential problems they’ll have to solve or work around, and clarifying for themselves the beginnings of the design. One of the best things you can actually get from them is “That won’t work”. While that sounds disheartening, especially if the idea you presented has personal meaning, what that actually means is “I have an idea that may work for your need”, or “I am now engaged on solving your problem”. One of the worst things you can get is a shrug and “That’s nice”, because that means they don’t care. And you want them to care.

Programming is Deeply Personal

While programming has many core skills, and many best and better practices, and many concepts of aesthetics and fitness for use that are shared, it is also a realm of individual imagination and approaches to solving problems. One of the common phrases is “There’s more than one way to do it!” is so true, and creates part of the rich tapestry of software that is available for people to use.

Writing software means something different to everyone who does it. There are many different reasons people feel the need to write software, and many different approaches to that effort.

As with all products of the imagination, software is no less bound to the personality of its creators.

For a long time, companies that produced software tried to instill process in people, with the notion of reducing the uncertainty of how much time and effort it took to produce the software. Removing the uncertainty gives a business the ability to predict or forecast more accurately how much money it is going to take to create a product that they can then sell, giving part of the equation of how much money they think they will make in the near term.

The problem with that is that when pressed on software developers, it becomes yet another problem for them to solve; we’re insatiable when it comes to getting problems to solve sometimes.

But I digress; software management is a topic for another post.

The key thing here is that while there are many traits one can find in common among developers, and certainly many shared skills, knowledge, tools and libraries, it is never going to be the case that you will find two programmers with identical thoughts about what they are producing. What you make is yours – the product of your mind – even if it is being made with others. You cannot separate that personality from the thing it creates.