Ever since I started teaching at the New York Code and Design Academy, I have been thinking about the core qualities of a successful designer and developer. The class aims to teach the students enough to build a web application on their own, from concept to completion. It is a 96 hour, 16 week course taught in 3 hour chunks, so the goal is really to—starting from nothing—give them the knowledge they would need to get started in the tech industry. But if my co-teacher Zach and I expect to train our students to practice web design and development at a professional level, does that mean we are attempting to train unicorns?
The Supposed Spectrum
I think most people think of a hard designer-developer split, as if there is a spectrum with designer on one end and developer on the other. They see it something like this:
The more of an engineer you are, the less of a designer you are, and vice versa. Perhaps it is because engineering is more associated with analytical "left brain" thinking and design is seen as a more creative, "right brain" exercise. In reality, this is a false dichotomy, as both designers and developers need to use a combination of divergent and convergent thinking to innovate and problem solve. Both disciplines are more similar than most people (and the internet) make it seem.
“Good designers and good developers actually have a lot in common.”
As Austin Bales says in a great talk, good designers and good developers actually have a lot in common. The crossover really even shows itself in our language when we use (appropriate) terms like "social engineering" for techniques designers use to illicit certain behaviors, or "software design" for the planning and creation of programming code. Both designers and developers put a premium on simplicity and clarity. Both are trying to make their creations as easy to intuit and work with as possible. Developers refactor their code as requirements change and complexity increases the same way designers redesign interfaces to make room for new or changing functionality. They have similar traits, skills, and motivations, they just work in different mediums and have different specialties. Designers tend to specialize and focus on the beginning of the creation process, whereas engineers specialize on the end or latter half of the process. I say a more accurate representation of a single person's skills might look something like this:
Each person has a certain level of skill in the designer and/or developer subject areas, where many of the skills and habits that would make you excel in either area would help in both. People may have a tendency to lean towards one area over the other, but no one has a "type" that would prevent them from learning and improving as a designer or a developer. What matters is the time and effort put into learning. World class designers and developers have put in lots and lots of dedicated practice: their (proverbial) 10,000 hours.
I wanted to write about this because as I attempt to distill my professional experience into teachable morsels for my students, I have realized that the one of biggest barrier is mental. People who have categorized themselves as an engineering (or math and science) type will shy away from and avoid areas of knowledge considered to be in the realm of a designer (or "creative") type. At Stanford this took the form of the great divide between engineering major "techies" and humanities major "fuzzies." I believe this prevented many would-be "ninjas" and "unicorns" from ever reaching their potential. The effect is similar to having a fixed mindset instead of a growth mindset. Deciding you will never be good at design because you are a "developer type" is a sure way to never become a good designer. You have set up a self fulfilling prophecy.
Being a great designer and a great developer is not an impossibility. With enough time and effort, you can become a designer or developer or both, no forehead horn required.
P.S. You can follow my writing on Medium, my blog's RSS feed, or me on Twitter @uxdiogenes.
P.P.S. This was on Hacker News.