art and code (1/3)



  1. This is the first of three posts about art and code, specifically about the similarities in chronological flow/process.
  2. These are subjective views/opinions/not facts and are from the perspective of a novice programmer and visual artist.
  3. This topic deserves a much longer extrapolation and could easily become a book. These posts will be fairly concise.
  4. This preface will appear before each post in the series.
  5. I am passionate about this topic and believe there are far more similarities than differences in artistic and technical pursuits. I am, overall, at a loss as to why the two generally are held up in contrast to each other.


When one sits down to make art or code, in the beginning, there can be inspiration first and preparation after. Or, if you are very disciplined, then there may be a dedicated time for sitting down and doing something, after which inspiration may occur. Or not at all. The act of preparation and starting something may be enough.

Because creativity is non-linear, I will touch on both flows. Inspiration first, preparation next; and preparation first, inspiration next (or not at all).

First, I will define each phase (inspiration, preparation).


This is, in my experience, the most addictive part of the creative process in both art and code. It appears in many forms:

  • an idea on a spectrum of vague-to-fully-formed
  • a problem or problems I want to solve
  • something I want to communicate
  • a technique or practical concept I want to practice
  • a whim
  • a capricious urge
  • numerous fancies

The nature of this inspiration affects the momentum with which the project starts. Is there a driving urge to just “get it out”? Is it a lazy, slow unfolding expression of a nebulous concept? Does it feel like something, unless you get it out right now, will dissolve into nothingness? Or is it something that will hang around and nag you until you make it?

The way inspiration arrives can greatly affect preparation.


the environment

  • room | computer
  • easel | text editor
  • blank surface | empty file(s)
  • brushes, paints, palette | languages, paradigms, toolchain

While it’s important to understand the tools at hand in both art and code, I’ve spent way too long in this part of the project, rearranging and putzing around. “Are these the right paints to use?” “Is this the right file naming convention?”

This part of the process is a true danger zone/black hole. While it’s important to make intentional decisions based on evidence and objective criteria, it’s far too easy to become prematurely detail-driven. It’s also far too easy, if inspiration is bearing down like a bullet train, to rush through this part of the process; if that happens, the environment may sabotage execution.

Balance, here, as with all things.


I nest ideation under preparation because I believe that it is an important part of the preparation process. Some may argue that it is really part of the final project.

This is when I actively create collateral in the process of preparing to work on the final project. Examples of collateral:

  • pencil sketch | pseudocode, architecture sketch, UI sketch
  • studies (color, value) | more pseudocode, architecture diagramming, wireframing
  • selecting brushes, paints | selecting languages, toolchain, paradigms


This is the stereotypical creative flow.

  1. Person has an idea. 💡
  2. Person furiously works to turn idea into reality, burning the midnight oil in the process. 🌙
  3. Person magically births the idea, fully realized, in the world. 👶
  4. Person moves on to the next inspiration.

Ain’t nobody got enough midnight oil for that.

But really, that’s not how it works all the time, at least for me. It’s great when it happens that way, and about a third of the time, that is what happens.

Usually when this happens, I feel like the idea has a timer on it. I have to bring it into the world before it fades. So, in a way, this is an inconvenient and unreliable means of creating something.

It’s actually much easier to have the following flow…

preparation->inspiration (optional)

Sitting down to do something, anything, is often the most difficult part of the process with art and code. Finding the time, building it into my schedule, and creating a habit (ahem, #100daysofcode).

Oftentimes, I sit down to do something, without planning what that is, and a very faint spark of interest turns into something I love and am proud of. The latest example of this particular flow is my Breathe project. It started as an experiment with CSS loaders, and ended in a tool I actually use and invested a lot of time in.

From my experience, this is a vastly underrated creative sequence. Preparation can lead to inspiration, and often does, for me anyways.

Don’t believe me? This is what Edith Wharton has to say about it:

Many people assume that the artist receives, at the outset of his career, the mysterious sealed orders known as “inspiration,” and has only to let that sovereign impulse carry him where it will. Inspiration does indeed come at the outset to every creator, but it comes most often as an infant, helpless, stumbling, inarticulate, to be taught and guided; and the beginner, during this time of training his gift, is as likely to misuse it as a young parent to make mistakes in teaching his first child.

Edith Wharton, The Writer’s Quote Book: Link

Ah, speaking of which:

At Pixar, protection means populating story meetings with idea protectors, people who understand the difficult, ephemeral process of developing the new. It means supporting our people, because we know that the best ideas emerge when we’ve made it safe to work through problems.

Catmull, Ed. Creativity, Inc. . Random House Publishing Group. Kindle Edition.

Nurturing an idea and starting to execute on it, without crushing it under the almighty boot of judgement or constraints, is challenging.

A perfect segue…

and finally…

Because I can’t ignore these, any which way I approach an art or code project, there’s generally an abundance of…




i have no idea what I’m doing!

Then. At last.

Because all of that was exhausting, and it’s time to just. Do it.

Broken Windows Theory

I’ve been reading the Pragmatic Programmer. Like, two pages at a time. Because, it’s dense. Just several pages in, I was captivated by the use of a theory I encountered during my experience working in the built environment.

The broken windows theory is a criminological theory that states that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes.

Source: Wikipedia:

Abstract this theory into non-physical structures, systems, and processes, and the analogies are easily found. I’ve seen this and experienced it in systems, processes, and relationships.

Small acts of disorder cause decay.

Of course, this theory has been widely discussed and widely used. And, of course, there are issues with this theory and criticisms of the research methodology.

The intent of this post is to present this theory in the context of its usefulness and applicability for software engineering; I do not not intend to analyze the validity of the original research and I do not discuss the theory’s use in policing.

So what does the Pragmatic Programmer have to say about broken windows and software engineering?

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation. We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor. You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood.

Hunt, Andrew. The Pragmatic Programmer . Pearson Education. Kindle Edition.

This theory has already impacted my own coding practices. Each time I feel impatient and want to skip over a potential issue in an effort to get on to shiny new things, I remember that each piece of code could become a broken window or part of a broken window.

Read more:

The Broken Window Theory In Product Design

freeCodeCamp: Don’t Live with Broken Windows


#100daysofcode is a thing. It’s a hashtag. It’s popular. People tweet it. People do it. It’s got hype.

Every day, my clock restarts at 0 and I have to sit down for at least 1 hour and code at some point during the day.

This is day 2 of my #100daysofcode.

What is it?

What #100daysofcode is may be best explained by the rules. There are just 2 rules.

  1. Code minimum an hour every day for the next 100 days.
  2. Tweet your progress every day with the #100DaysOfCode hashtag.

That’s it. Anything else rules-related can be found here:

Why am I doing it?

I recently started the freeCodeCamp curriculum and was looking for accountability strategies and things I could talk about when I go out networking. This ticked both of those boxes.

Wait, freeCodeCamp?

Slipped that in there.

sneaky banana

I’m not dedicating an entire post to this decision, so I’ll squeeze this in here. After I finished the Python programming course, I had loads of project ideas (see this blog post) and while I had learned many computer science concepts and how to apply them in Python, I needed a few more skills before I could build, as I mentioned in that article, a full on web app.

Building full stack apps in Python is semi-doable but not a smooth process.

And I was not in the mood to once again spend extensive time researching for more resources. I’d already done the research and considered freeCodeCamp (FCC).

It’s free. I love the mission of FCC. It’s available now. So I went for it.

Why #100daysofcode and freeCodeCamp are perfect together

Starting anything is daunting. freeCodeCamp is a lot to bite off. #100daysofcode provides social accountability and helps kickstart a habit that can last well beyond just 100 days.

There is nothing to writing. All you do is sit down at a typewriter and bleed.

Mark Train

With this, it’s more like: There is nothing to coding. All you do is sit down.

End of story. No bleeding (whew). It’s really as simple as that for me. I just need an excuse to sit down and focus on coding for at least one hour per day.

Tweeting about my progress every day is invigorating and I’m excited to report what I’ve done each day. The community on Twitter around the hashtag is very supportive, and both of these endeavors are great talking points during networking.

Things you need to get started

  • One hour per day for 100 days
  • Twitter