The Philosophy of a Unicorn

How to Design & Develop


My official job title (when I applied) was ‘Unicorn’. Like most people, I wasn’t sure of exactly what this meant, but I knew I had several different skills so I thought I’d go for it. I ended up getting the job and in that moment I became, I guess, an official unicorn.

In general, this means that you can both design and code. It’s generally frowned upon to call yourself a designer/developer because it sounds conceded, so the more down-to-earth allusion to a mythical beast has naturally replaced it.

Well, I hate the term. It implies that to design and code you need 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 skillsets into nice little subcategories, for it was necessary that a certain amount of physical human experts commit their whole lives to teaching one specialty. Interactive learning was a scarce resource then; 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’m here to argue 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 becoming a unicorn is really very simple. I just wanted to be able to make web things. I was entranced by the idea that I could make something and it could be instantly available for everyone on Earth to experience. The internet, to me, was the ultimate platform for invention, for art, for ideas, for creation. I was blind to the conventional tech divisions of the day, so it seemed obvious that to actually make anything you needed to learn to do everything. No one told me I was supposed to separate the functionality of a program from it’s visual representation.

I also specifically wanted 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. In the same vein, I didn’t want everything I made to 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 luckily the metal box on my desk contained all knowledge in existence. In retrospect, 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.

For instance, 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 you press it. 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 experience.

If you’re stuck, try to the best of your ability to verbalize your question into a Google search. You’d 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 repeat. Get 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 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, all your initial suckiness will fade 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.

More than anything, coding is just a system of thinking. It’s both an external practical tool and internal exercise of the mind. It trains your consciousness to habitually break down problems into their component parts and organize those parts into a coherent solution. This ability can obviously help you in all of life. Many coders become simply more logical people because they reinforce their left brain connections so regularly.


On the other side of this is, of course, designing, or right brain thinking. 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 core of your being.

Everything in the universe follows the same dualistic schema as design and code, and it’s important to understand that absolutely everything is polar. Up/down, hot/cold, yin/yang, masculine/feminine, old/young, black/white, hard/soft, 0/1. We all have both aspects of everything within us, just as we all have left biceps and right biceps. If you’re a guy, work to become comfortable with your feminine aspects—if you can accept and master them they’ll make you a much more powerful creator. If you’re a girl, embrace your pockets of masculinity. You won’t suddenly grow broad shoulders, you’ll just be able to execute a bit more systematically. And just like biceps, some choose to develop these aspects into something that perform well, and some don’t.

If you just don’t think you were born with a sense of design, I’m here to tell you that you’re wrong, and that yours is currently just very weak. Muscles atrophy without use, and the same is true of your design sense. You haven’t developed this sense 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 pretty simple. The design sense is really just another word for intuition. Intuition is the subtle ‘knowing’ you occasionally have about things. Intuiton is 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. The problem is that people too often dismiss this information as background noise, 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 easily reversed. By consciously flipping this reaction, you will quickly develop 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. 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 will become. As this happens, you will increasingly just know what the right decision is.

Value your gut more than you value anything. If something just doesn’t feel right, then it’s wrong, period. Throw it out and continue to do this until whatever you’ve designed just feels right. You really don’t have to know why or have a logical explanation. Your intuition transcends logic. It’s a powerful supercomputer processing more details and perspectives than you could ever begin to comprehend, and doing it all faster than you can read a single word. It’s always there and willing to guide you towards creating amazing work if only you’d listen to what it has to say.

But even still, intuition has it’s place. In my personal design philosophy, 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, then to be seen. Usability is always top priority. When every decision that affects overall usability has been made, you’ve plotted out the space where you can make free stylistic choice.

When you can choose over a range of compelling options, the golden rule is, again, 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. After you’ve finished and think it’s done, do something else for a certain amount of time (a few days preferably), then return with a fresh perspective.

Your intuition is often strongest when you’re looking at something with this fresh perspective. 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. You’ll learn more from watching a kid play than in any university course.

Coding and design are both parts of the same process, and they have to play off each other. Specialized workers were once needed for each stage of a product’s creation. That’s just no longer the case. The only thing holding you back from being a designer/developer is your own internal voice chaining you down with some label.

Don’t be a label—be a Unicorn.

Email me when Max Brody publishes or recommends stories