Published on <a href="http://ift.tt/2pSU94t">| Prototyping: From UX to Front End &mdash; Medium</a> Melsen Carlsburg <img alt="" src="http://ift.tt/2p5j8i6">(a joke: the concept of design as embedded ruby code)
Three weeks ago, I took the plunge and started a <a href="http://ift.tt/14op8qU">coding bootcamp</a>. I have been working for over ten years as the lead graphic artist at a family-owned screen printing and embroidery shop. I’m still working there part-time as I make my way through this program.
I was nervous that this would be a tough career move. I had very little experience with computer science, and I didn’t fully know what I was getting myself into!
Fortunately, I’ve found that some key lessons I learned as a designer are helping smooth the transition. I am used to planning design projects on a very tight schedule. In a production environment, you can’t afford to waste time, so you figure out the most efficient and accurate ways of achieving results, out of necessity.
With coding, my goals are slightly different: I want to learn well and deeply, and I don’t want to prioritize doing things quickly — I want to avoid anything that would take away from the learning process. However, I have a feeling that these habits of creating things efficiently and accurately are going to serve me just as well for learning as they did for production.
Below are five of these lessons.
<h3>1. Track Your Time</h3>
Keeping track of productivity helps keep me accountable. I’ve been using the app <a href="https://www.toggl.com/">Toggl</a>, and it has provided a way for me to visualize how my time is spent. Somehow, the act of clocking in and out just puts me in the headspace where I want to make every minute count, and I end up focusing better.
The other benefit to this is that I can put away the coding homework when it’s time to be done. I’ve heard a lot about the concept of <a href="http://ift.tt/1MdTs9T">Work Life Balance</a> in the past few years, and though I don’t believe work and life are mutually exclusive, I have definitely felt more recharged and able to engage in the “work” side if I have had adequate time to unplug.
<h3>2. Visualize Your Goal</h3>
Often, my design projects will have clear end goals. It’s very important to be able to define what it is you want to accomplish before forging ahead, so you don’t <a href="http://ift.tt/2pSBy8X">spin your wheels</a> overly much. Articulating the goal can often give you clues to how you will solve the various challenges that stand between you and your finished product.
I’ll give you an example:
<img alt="" src="http://ift.tt/2p58LLk">Picture of a screen-printed 4-color design on a t-shirt
In this design, I needed to decide what the print order would be of the four ink colors. Once I decided that, I also needed to plan for how the colors would overlap. Before messing around with expanding selections in Photoshop, I visualized my goals.
This helped me picture what I wanted the final screens to look like. Then, when I went to make a plan of attack, I could base my steps on this visualization of the final product, and I could compare my possible solutions against the goal to predict if they could accomplish it.
In software, I imagine this skill — this ability to look ahead to possible end goals and compare what I’m doing to what I want to accomplish — to be incredibly useful. After all, it seems that every piece of software gets built to address a need of some kind, and it will be really important to keep my sights set on the core purpose, as I’m building out features.
<h3>3. Break it Down into Manageable Steps</h3>
I think this concept is related to the fact that many people can only remember up to <a href="http://ift.tt/28KKOkt">7 digits of numbers</a> reliably. It’s unreasonable to expect that a person will hold all the details for the whole project in their head all the time — that’s a waste of cognitive power! Wouldn’t you rather be using your brain to focus on each detail in turn, so you can do a really good job with each step?
Make a list of all the steps you’ll need to accomplish your goal. Then work on them one by one. You can always zoom back out and revise the list of steps as necessary.
If you have multiple projects with similar steps, you could even work on all the first steps together, then all the second steps, etc. I’ve found that the repetition inherent in this method makes me more accurate and more speedy. (Practice makes better — as long as you practice the right things!)
From what I’ve heard, this idea translates directly into the <a href="http://ift.tt/1UwRtzf">Agile Software Development</a> process, which provides a structure for multiple people to collaborate on projects in an efficient and directed manner. On a more basic level, it is essential to the practice of designing Algorithms.
<h3>4. Automate Repetitive Tasks</h3>
If there’s something you do exactly the same way every time, then logically it would make sense to save the steps for later, so you could simply duplicate them without worrying about missing a step. Not only will you be saving time, you’ll be staving off <a href="http://ift.tt/2ao2zem">directed attention fatigue</a> — saving your brain power for making new decisions, rather than re-hashing old ones.
In my design experience, this manifests as saving <a href="http://ift.tt/1miKY83">actions</a> and <a href="http://ift.tt/1pn2nvE">macros</a>. It also means using design guides, libraries, and templates so you don’t have to re-invent the wheel every time you start a new project.
In the developer world, this can mean defining methods and functions, so you can refer to them whenever you need them. In a larger sense, this also includes the practice of building up libraries and frameworks — collecting many segments of code that you know work, then simply calling them up when you want to use their functionality, versus re-writing similar code every time.
<h3>5. Simplify</h3>
Fewer moving pieces means a smaller chance of error. Let’s say I have a design file with 500 red objects in it, and I need to go through and change all the red objects to black. There is a much higher chance that I will miss an object or select wrong objects with this file, versus a file where all the red objects have been merged into one red object beforehand.
I’m talking about simplifying in the sense that you reduce the number of decisions the artist has to make on any given file. Not only are you saving time, you are boosting the chance of accuracy.
With coding, programmers are always striving for an <a href="http://ift.tt/2p5fi8Q">elegant solution</a>, meaning “a solution that solves the problem in the simplest and most effective manner.” This concept also ties in with the idea of <a href="http://ift.tt/2pSV3hE">encapsulation</a>, and the idea of DRY, or “<a href="http://ift.tt/2p5aqjX">Don’t Repeat Yourself</a>”.
Keeping these five lessons in mind has helped me feel more confident in the learning process. I hope you found them useful as well! What guidelines and ideas have helped you in your process of learning to code?
<img src="http://ift.tt/2pSC9XU" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2p57nIH">Learning to code: Five lessons from a career in graphic design</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learning to code: Five lessons from a career in graphic design

Top Stories