Designer Brain, Programmer Brain

The typical daily activities and thoughts of a one person studio at the end of 2023

When business owners define an organization chart they have discreet roles: server, cook, host, manager, etc.. As a one person studio, it is difficult to describe the roles I play. I wear a lot of hats in order to get the job done. Everyday I spend a bit of time on operations: sending invoices, responding to leads, organizing my business. About a dozen days throughout this year I spent time on my studio’s strategy. Sometimes I believe that not having a specific role is an advantage. For instance, I have a holistic perspective on the choices I make for my business and for my clients. However, other times I think this type of thinking can stunt creativity. When I have an idea, I play out all the steps and costs involved. I do not act on this impulse because I realize how much work is required. While I wear a lot of hats, there are two roles that stand out: designer and programmer. I have spent the last two decades familiarizing myself with these two roles. I would like to share how I see them and how they influence my practice today.

A collection of images I save under shared attributes of Procedural Aesthetics. 2010–Present. A term I use to understand a curious dynamic between creative and pragmatic. The same dynamic I find between the designer and programmer.

The Designer

This role is all about looking. I look at a problem in front of me, the vision a founder has, or the brief from a cultural organization. I look at it from different angles. There usually is not enough time within the scope of work (even in my own personal projects) to look at it from all angles. I take what snapshots I can. Then I piece together a mental model of the subject. This model does not directly translate to the solution, the prototype, or the final deliverable. However, it guides me when I have to make a decision. And designers needs to make many decisions throughout the duration of a project. Broad decisions have cascading effects. Smaller decisions fill in the gaps or challenge the big picture. The sum of these decisions is a design system. A great system incorporates the different angles that I see and understand in the subject matter.

The daily tools I use in no particular order when in this role are:

• Sketchbook and Pen

• Adobe Creative Suite

• Figma

• Google Slides, Sheets, and Docs

• Screen Capture

• GIF Brewery

The Programmer

This role is all about executing. There is an actionable milestone in front of me. Rewrite a codebase into a different language. Transcribe a physics algorithm into a shader. Export saved frames of a session into a video. Every milestone has multiple steps involved. The steps can be small enough to juggle in my head or so big that I need to write the list down. To execute a step with authenticity requires focus. Programmers focus on stripping away as much context as possible. This is known as modular programming. For instance, a step does not need to know about its previous or next steps in order to run. It is impossible to strip all context away; to operate in a vacuum. But with enough focus, constructive and (surprisingly) divergent results occur. Great results yield new understanding: about a programming language, software, API, execution loop, generally how computers work. This in turn speeds up my ability to execute. To be honest, the compounding effect of this role is seductive.

The daily tools I use in no particular order when in this role are:

• Sketchbook and Pen

• Visual Studio Code

• Github Repositories, Issues, and Desktop

• Xcode

• Terminal with Oh My ZSH

• Target Devices: Smartphones, Computers, Televisions, Headsets, etc.

• Notion

I think about these two roles as if they are at different ends of a spectrum. This spectrum is the lens through which I approach work. If I get stuck in one way of looking, I can switch to the other. I do this because of how I was taught. I began with a formal design education. This education led me to computer programming. It took me about ten years to feel comfortable and confident about navigating the programming domain. These experiences allow me to slide between the two roles in rapid succession to produce work. Looking forward to the year ahead, I am excited and curious: how can my roles expand?

Is there another role I should incorporate? Is there a different way to relate designing and programming? What new tools will become available to strengthen the bond between the two?

What roles do you play? Will they or might they change next year? Wishing you peaceful last days of 2023.

—Jono