Art projects build problem solving skills, logical thinking, attention to detail, teamwork, and critiquing skills. These same skills are essential to every technical project. The following is a list of lessons that I learned in art and have made me a better developer.
Move from General to Specific
In introductory computer science courses, I would be given base code that did the hard work of designing how a whole program works together. When designing my own programs, I fell into the motion of fleshing out a specific function and bandaging functions together. This process was bad because the work-around method would propagate throughout the code. I should have worked from general to specific.
Composition Sketches in Pencil
To capture an entire space in a drawing, I need to scale accordingly so that it fits. I choose a measurement in my scene as the standard, such as skulls. How many skulls-wide and -tall is my drawing? Then I quickly draft the entire space on the page. After working on one area for a short time, I define another. If I hone in on one aspect of the drawing, then that aspect of my drawing will be significantly more detailed than the rest. I end up working around it, but the drawing looks incohesive.
I brought this level-of-detail thinking into my technical projects. After researching different approaches, I start with thinking about how each part will work together on a larger scale to create the intended result. I use flowcharts to visualize how different classes and libraries will work together. I build a base code with placeholders for functionality. Then, I fill it in.
Focus Your Time
Approaching a technical project is daunting. I would block out full days to work on homeworks. And at the same time, I would avoid them because I did not know where to start and did not want to work on them anymore.
Pitcher and Cup in Ink Wash
Similarly, ink wash (typically black ink and water) is an unforgiving medium. There is a limited time to work with it before it turns into chaos. There are two simple strategies: wet-on-dry is applying the ink on dry paper and wet-on-wet is applying ink on water on the paper. If I let a part of the painting dry, I may not be able to get it to the state that I want. But at the same time I have to pay attention to all of it. The relationships between time, the medium, and the paper are fragile and elusive. When working with ink wash, I work in short intervals of time, making it easier to focus. What is realistically achievable in twenty minutes?
I found determining a time limit to engage and disengage with a technical project relieved my stress. One to two hours blocks with a short break is my optimal schedule. Often staring into coding for a long period of time causes me to lose focus and disengage with the project. I have also found that coworking with friends, even when we’re working on different projects, is a great motivator.
Start Over and Refactor Code
Refactoring code, the restructuring of existing computer code, is a daunting task. There have been so many times when I chose not to refactor because of the amount of work that I would have to rewrite. I did not have time to go back. I knew what my code was doing. Maybe it’s inefficient, but it got the job done.
“Wipe down your page and start again,” my figure drawing professor would often say. The measurements were wrong or that foot should be higher that the other foot. If I keep going, I have to work around what is wrong. If I destroy my progress, all the time that I had spent was wasted. Alas, my professor would offer to wipe down my page for me. I would go through this process numerous times, and it hurt less every time. That semester I learned that a deep clean is often needed in the early stages of projects. The longer the mistakes last, the worse it gets as the project moves along.
During all of that “wasted” time, I learned about the process of my work and how the tools worked together. Rebuilding often takes less time than the first time around because I am more familiar with what I was doing. The overhaul of code has the potential of really fixing major problems, and makes code more efficient, understandable, and concise. Rewriting code has become less scary and less like trudging through the swamp again.
Build Your Intuition
Throughout my life, I have been fortunate to have had opportunities in the arts from coloring in kindergarten to creating stages for theater in high school and through formal art classes in university. Over time, I have built up an intuition for my approach to drawing, painting, and building. I am not as afraid to explore and fail at art because it is not my main area of focus.
Between different stages of coding such as in brainstorming, implementing, debugging, and refactoring, there is often a lot of friction or resistance to change. I hesitate to try different approaches when one already works. Debugging is a challenge, but gets easier with experience, tools, and help. My peers and mentors are my resources who give insights from different perspectives and their encounters with similar problems. In time, I will build up a more robust intuition and pass my learnings to my peers and mentees.
Art teaches me lessons that are not as obvious to me in different disciplines. I am continuing to bridge my artistic thinking into my technical projects so they, too, feel as approachable. I believe that art has definitely helped me to become a better developer.
The Interactive Mechanics Fellowship Program aims to build capacity for representation and inclusion in the technology field. We see it as a mutual learning experience for the fellows and for our existing team, so we’ve asked our fellows to share some of their expertise on our blog.