Ever since I started drawing, trying to understand how ‘real artists’ work and think, I was often surprised to learn about something I knew from my own profession! Even between two activities so apparently far apart as pure logic and abstract thinking on one side and making colorful marks with emotional impact on the other, one can find resonance.

Here’s the shortlist of some of my obvious and not-so-obvious findings:

Problem solving

Programming is obviously a problem solving activity. It was really news to me how artists would view much of their work as problem solving, though. It may be a concept artist, who is given the task of designing a vehicle within given constraints until tomorrow, or a painter figuring out the perfect composition, shape language, lighting, color palette…

I think the analogy carries pretty far. To solve your problems, you can work methodically top/down (resp. rough to detailed), or employ trial and error. If you didn’t solve your fundamental problems properly early on, they will come and bite you later (I haven’t heard anyone talking about a ‘bug-ridden picture’ so far, but they certainly exist 🙂 ).

Attention to detail

This seems quite obvious. What is a single misplaced character breaking a program, can be one wrong line ruining your sketch. And you should absolutely know what every element in your program / picture is doing to help achieve its goal. Useless clutter, anyone?

Teams of introverts

It seems both programmers and artists generally prefer to be left alone to work on their piece for endless hours. In professional reality, it is important, though, to communicate a lot with others, as projects get bigger and bigger all the time. Feedback is also a topic here (code reviews, art critique).

Life-long learning

To me, at least, doing something that you’ve never done before is the essence of software development, always expanding your mental toolbox, so you can tackle bigger tasks the next time. There is no finish line, where you have learned everything there is and will be. The same seems to be true for passionate artists, as far as I can tell.

Creative bursts and discipline

In coding, painting, and I guess all creative endeauvours, there are spurts of energy and inspiration, followed by long stretches of filling in the gaps, where great discipline is required to get through the project. Understanding how much making art also requires discipline and quite simply showing up and getting to work helped me a great deal. You’re not a failed artist, if you aren’t inspired every day. You’re not a bad developer, if you can’t produce brilliant code like a machine.

Composition and architecture

As much as a good initial composition can decide over success or failure of a picture, the software architecture of your system can determine the fate of your project. There are functional as well as pleasing designs, concepts such as symmetry and readability in both worlds.

Looks too easy

From personal experience, I know the complete inability of, say, upper management in some companies, to understand why all of this software business is taking so long, when certainly it can’t be that complicated and the computer is doing the work, after all. And if things seem easy and fast, nobody can see it’s the result of years of training and countless hours of practice. Then again, you’ll hear ‘oh, I could never do that’ very, very often 🙂

I’ve heard the same, anecdotally, from working artists.

Style

Obvious in the arts, but there’s personal style in programming as well! Even if everyone in your team is following the same coding guidelines (where to put the braces, etc.), chances are you’ll be able to recognize who in your team wrote a piece of code after a while. Also, you’ll find people able to adapt their style to fit into whatever project they’re working on, while others value their freedom of expression higher than anything else – they might be brilliant, but substantially harder to work with.

I could elaborate on some of these topics, but this is essentially what I found so far, Anything missing? Probably 🙂

It might be worth writing about fundamental differences between making a drawing and making software, too. Have to think a bit about that.