You are a Unicorn

In Silicon Valley, if you code and design you’re sometimes known as a ‘unicorn’. It was actually the official title of my first job. The term is meant to be endearing and complementary, but I hate it.

It implies that to learn to design and code you need to have some sort of superhuman ability, when in fact it’s what most people should already be doing. The precedent of separating these fields stems from misguided thinking, and it creates efficiency bottlenecks that inevitably hurt productivity.

Inspired from the apprenticeship model of the Middle Ages, our pre-Internet education system split all knowledge and skill sets into subcategories. You could either study art or you could study science, but not both. Unless you were da Vinci, you had to choose.

This requirement of choice was a symptom of the disconnectedness of the old world. It was necessary that a certain amount of physical human experts commit their whole lives to teaching one specialty, because interactive learning was a scarce resource. If there wasn’t a teacher there wasn’t a class. This model was essential, but it isn’t anymore. Interactive learning is everywhere, and it’s virtually free.

In today’s world, setting as standard the idea that you can do only one thing merely assures that you will be unexceptional in your field. You can’t color outside the lines if you can’t see them. I’ve found from experience that everyone is capable of learning to code and design, and that over time they come to reinforce and strengthen each other. The best coders design, and the best designers code.

My story of learning to do both is really unexceptional. I just wanted to be able to make things on the web. I was entranced by the idea that I could make something in my room and it could be instantly available for everyone on Earth to experience. The Internet, to me, was the ultimate creative platform. I was young and blind to the conventional divisions of the tech world, so it seemed obvious that to actually make anything you needed to learn to do everything.

If I wanted to make a pizza, I’d have to roll the dough and put the sauce on. If I wanted to make a program, I’d have to write the code and give it an interface. No one told me I was supposed to separate the functionality of a program from it’s visual representation, so I didn’t.

Specifically, I desired to be able to make stuff by myself. I didn’t want to draw a pretty picture of what something could look like and then have to convince someone to make it with the wizardry of code. On the flipside, I didn’t want to learn how to code and have everything I made look like Craigslist.

I was a passionate philosophy major in college so I didn’t have an official education in either CS or design, but the metal box on my desk contained all knowledge. It’s really not all that hard to teach yourself once you know some strategies and where to find the best information. The single most important thing (which I learned after a year or so of struggling) is that it is always best, no matter what skill you’re learning, to have an initial mini-goal in mind to serve as a proof of progress.

Coding

If you’re learning a new (or your first) programming language, your first step should be to think of some simple application that you’d like to make with it. A grocery list. A bouncing ball. A big red button that goes boom when pressed. Start as simple as feels comfortable. Then go and learn whatever you have to learn to make that simple app a reality. Don’t give up until you’ve made it work exactly how you planned, and look exactly how you envisioned. Along the way, you’ll pick up all sorts of concepts you’d never have realized were necessary and you’ll slowly gather the gold of real experience.

If you’re stuck, try to the best of your ability to verbalize your question into Google. You’ll be astonished at how nearly any problem you’re facing has been faced by thousands before you, and has been eloquently answered by those with experience. As you continue to develop this app (and yourself as a programmer), you’ll organically develop a personal workflow, which will provide much-needed context for whatever you learn next. And, after you’ve finished your app, you’ll be more comfortable making anything because you now understand what the process of ‘making something’ actually entails.

Then rinse and repeatGet a new idea in mind—something completely different yet only slightly more complex—and do whatever you must to get it working. While it’s okay to begin with books on whatever language/framework/system you’re trying to learn, just going through the concepts chapter-by-chapter won’t make you a good practitioner.

The only way to become a good practitioner is through practice. As soon as you can, begin making actual stuff. Even if it sucks, you made it, and if you know it sucks then the next thing you make will be slightly less sucky, guaranteed. This is because a huge part of both designing and developing is simply learning to recognize what’s bad. If you can learn to precisely identify just what is wrong with something then you are already 50% of the way towards improving it.

After a long enough time, most of your initial suckiness will evaporate and you’ll be endowed with the gift of a new skill. You’ll be on the level of most coders, who (as a rule) just figure things out as they go along. The best coders are simply the best at figuring out how to do what they don’t currently know how to.

As you progress, you’ll see that coding is more than a skill you use to make stuff. It’s a system of thinking. It’s an external practical tool and an internal exercise of the mind. It trains your consciousness to habitually break down problems into component parts and reorganize those parts into a coherent solution. This ability obviously helps in all of life. Many coders simply become more logical people because they reinforce their left brain connections so regularly.

Design

On the other side of this is right-brain thinking, or designing. Ideally, this exercises the complete opposite aspect of you. It’s the free, curvy, feminine, spontaneous, intuitive part. It’s the curious child, the passionate perfectionist, the free-flying, pre-potentiated, imaginative essence of existence.

Everything in the universe follows this same dualistic schema as design and code, and it’s important to recognize the essential polarity in all things in order to see how design and code need each other.  “Hot” only exists because “cold” does, and the same is true of all descriptive words: up/down, masculine/feminine, old/young, black/white, hard/soft, 0/1. We all necessarily have both aspects of everything within us, just as we all have right and left biceps.

Being and non-being create each other.
Difficult and easy support each other.
Long and short define each other.
High and low depend on each other.
Before and after follow each other.
— Tao Te Ching

While that’s true, not everyone exercises their biceps equally.  There is still a gender divide instilled in us through cultural conditioning that makes certain things naturally easier. If you’re a guy, work to become comfortable with your intuitive, feminine aspects. If you’re a girl, embrace your pockets of logical masculinity. The more you choose to systematically develop the divergent aspects of yourself, the more balanced and secure anything you create will become.

If you just don’t think you were born with a sense of design, you’re wrong. Yours is currently just very weak. All muscles atrophy without use, and your design sense is no different. You haven’t exercised this muscle because you don’t know how, and you don’t know how because you don’t have the slightest idea what it actually is.

Well, it’s actually simple. The design sense is really just another term for visual intuition. Intuition is the subtle ‘knowing’ you occasionally have about things. It’s your subconscious bubbling up and popping into conscious awareness. It gives you answers but doesn’t reveal it’s method.

You’ve experienced it sometimes when you don’t know why you feel something but you just do. You feel like you should stay in tonight for some reason, or you sense that that person is trouble. The problem is that people too often dismiss this information as background noise, and rationalize it away as the random firing of chaotic neurons in an imperfect system. You were taught to ignore this information from a young age so you’ve slowly withered your perception mechanisms to it. Your conscious mind has told your unconscious: “this isn’t valuable data”, and your unconscious has responded by ceasing to provide you with apparently useless information.

Luckily, this can be reversed. By consciously flipping this reaction, you’ll redevelop your design sense. Internalize the fact that the ‘random’ feelings you have towards certain things are not background noise, but the main show. They’re not random chaos, but hyper-intelligent insight from sources you don’t need to understand to benefit from. The more you listen to this minute data, the more you tell your unconscious to provide more of it and the stronger your perception and understanding of it becomes. As this happens, you’ll increasingly just know what the right decision is.

But even still, intuition has it’s place. From a pure, zen, Apple-ish design perspective, the amount of free stylistic choice should be minimized and the pure functionality of the product should determine most main decisions. If it’s more usable (yet slightly less aesthetically-pleasing) to have a large button to the right, then that is still the correct decision.

Most of the time you’ll be building some sort of tool that does something, and tools exist first to be used, not to be seen. When every decision that affects overall usability has been made, you’ve plotted out the creative space where you can make free stylistic choice.

When you can choose over a range of compelling options, the golden rule is, as always, to choose whatever feels most right even if you’re not sure why. As I’ve written previously about typography, there are certain times when there is no clear logical reason why one design choice is better than another, but it undoubtedly is. These choices provide added dimensions of meaning, and should be made with the utmost care.

Pay extremely close attention to initial feelings about what you’ve made after it’s been a few days. If you’re ecstatically happy about it and think it’s the best thing you’ve ever done, congratulations, you’re finished. If you just feel..meh..then it’s now your task to identify what about it is making you feel that way and try to correct it. After you think you have, take some days off, and only when you return with excessively positive feelings do you know your work is actually complete.

If you’ve made it this far, I’ll leave you with one final thought. Learn from children. Children don’t discriminate between finger-painting and tree-forts, between playhouses and paper-mache volcanoes. They just create for the pure process of creating; because it’s fun. They want to finish a project so they can show it to their friends and know it was them who made it. They don’t follow rules and they don’t think in paradigms. They just make something until they’re proud of it, then fiddle with it until it’s better. All children are unicorns. You’ll learn more from watching a kid play than in any university course.

Coding and design depend on each other. What type of wood a bench is made of effects how it is painted. Specialized workers were once needed for each stage of a product’s creation, but now that’s just no longer the case. The only thing holding you back from being whatever you want is your choice to label yourself as something specific.

Don't be a designer or a developer or a unicorn.  Just create stuff and let people decide what you are.