Theory: Designers and engineers should learn each other’s crafts.
Software development is a world of ignorance, segregation and bigotry. I’m talking about prejudice, not of race, gender or religion; but of areas of expertise, specifically those of design and engineering. This is something I’ve learned from first hand experience, working both in the industry and on open source projects for over a decade. I believe that the most effective way to solve this problem is for designers and engineers to learn each other’s crafts, and I’d like to tell you why.
All my life I’ve been passionate about creating things. Christmas presents I remember from my childhood include rubber bands, tape, and a soldering iron. I have always loved the process of creation. How you can turn ideas into something you can play with, something you can use, something you can enjoy.
When I was 16 years old, I tested out of high school and began contracting as a user interface designer for a firm which happened to be run by my neighbor. I really loved working as a designer, but wanted to be able to make my designs do things. I was especially interested in creating games and graphics applications. I enrolled in a programming class at a nearby community college. My time in that classroom convinced me that I would never be a programmer.
After dropping the class, I felt defeated. Maybe I just wasn’t smart enough. But then I considered how I had taught myself how to play the drums and the guitar. I had taught myself how to make films and design graphical user interfaces. Had I simply taken the wrong approach to learning how to program?
A few months later, I sat down with an HTML version of a C++ book and within a few hours I was hooked. Since then I’ve learned more languages, and have a genuine love for programming. Either I suck at college or that teacher was rubbish, regardless, I’m just glad I found my way.
Over time I developed a consulting business and got involved in open source. As a contractor, clients would give me projects ranging from video production to software development, and everything in between. As I expanded my skill set I became more valuable, and my clients were better served. It’s what I love about consulting. It’s what I miss about consulting.
What I don’t love about consulting is how isolated you are. Early in my career I received a lot of mentorship in the area of user interface design. My work in open source provided some mentorship as well. But I felt like something was missing. So I began to look for a “normal” job, for the first time in my life.
I was shocked at how narrow the job descriptions were. After spending so much time broadening my skill set to increase my value, I was forced to reconsider my approach. I applied for all sorts of positions, not yet sure what relatively small field I should box myself into for the next several years. I took a short-term gig working on embedded Linux systems while I continued my search.
After a few interviews I realized that companies were looking for specialists. I considered dividing my resume into several versions, each tailored to a different field. I wondered how trapped I would feel at a job with such a narrow description. I was worried I might pick the wrong field, and terribly miss working in another.
Finally I found a position working for the non-profit organization that runs Wikipedia. It was a small shop, everything was open source, and they seemed to view my broad experience as an asset. Although I was hired as an engineer, I was soon assigned to work on making Wikipedia easier to use, and it seemed that my broad skill set was going to come in handy after all.
What I soon realized however is that even the most open minded organizations are deeply entrenched with prejudice. Because my title was software engineer, for the first time in my career I was no longer a designer. After many years of hard fought battles, I feel I’ve established my place at Wikimedia, and remain involved in both engineering and design. But as long as my title says engineer, it seems that I will always face prejudice.
In my experience, modern society in general, and tech culture in particular, has become obsessed with specialization. It can be seen in the way the way universities teach, companies hire, and open source meritocracies are run.
This commitment to intellectual monogamy is destructive. When we limit ourselves to small focused areas of expertise, we become more territorial. Barriers to entry are erected around specialized fields, made of nomenclature, terminology and litmus tests. These barriers discourage newcomers, and propagate prejudice toward the people on the outside of them.
Intellectual monogamy is also quite ineffective. It narrows the perspective from which all problems are viewed, severely limiting lateral thinking abilities. It also stresses the limits of human communication by focusing so much on dividing that it gets in the way of conquering.
Sadly, when people do take a more distributed approach, they risk becoming known as a “Jack of all trades, master of none”. To be clear, intellectual promiscuity is no better than intellectual monogamy.
Certainly there are some people who achieve significant breadth and depth.
Leonardo Da Vinci is regarded as being a polymath. A polymath is basically someone who has significant knowledge in multiple areas. A true renaissance man, he could also be described as an intellectual polygamist. His deep commitments to both art and science were complimentary and empowering, not a dilution of his potential.
But during the renaissance, things were different. Leon Battista Alberti (1404–1472) said that “a man can do all things if he will.” This concept, known as Renaissance Humanism, boils down to a belief that humans have limitless capacity to develop, and they should develop skills in all areas.
Both intellectual monogamy and promiscuity suffer from the same problem – single dimensionality which leads to linear gains. When we increase both breadth and depth, we can achieve quadratic gains in our total area of expertise.
It begs the question however, whether this is even achievable by most of us. Many believe that the Da Vincis of the world had greater innate talents than others. Innate talent, however, is not even known to be reality or myth. If innate talent does exist, it’s severely overrated. Either way it’s not what it seems.
The notion of talent is quite similar to luck. Both are poorly understood and often given undue credit. The causes of these phenomena can be divided into two categories; internal forces which we can control and external forces we cannot. Louis Pasteur once said, “Chance favors the prepared mind.” In the case of talent, one might say that “Nurture favors the diligent mind.” Open source must be a community dedicated to supporting people in a variety of fields, so that the diligent can best develop the skills needed to accomplish our shared goals.
Open source has been very successful in this way for engineers. The mentorship and support that most projects provide contributors is amazing and has resulted in a surplus of skilled participants set on giving back and sticking around. Is that the experience of a designer? It surely depends on the project. Observationally it appears that in the majority of cases, participants with such ambitions find themselves alone and uninspired. And to be frank, in most cases these designers aren’t prepared for the opportunities being presented to them.
The danger of low expectations
What I’ve learned from my experience contributing to open source projects is that most of my fellow contributors work in the tech industry to make a living. What I’ve learned from working in the tech industry is how unnecessarily divided the fields of design and engineering are made to be. As a result, the two groups have incredibly low expectations of mutual knowledge.
If a designer hands an engineer graphics assets that have been prepared without any consideration given to the medium they are to be realized in, they are a bad designer. Just as a print designer must understand how 4 color process printing works and how to prepare artwork for press, so too must a web designer understand how HTML and CSS work, as well as how to properly optimized graphics for the web.
And to be fair, if an engineer creates a product with a user interface that can not be improved without major code changes, they are a bad engineer. If you are writing a program a human is meant to use, you should be concerned with use cases. Even if you are writing a service or a library, APIs are used by humans, and user experience should be an important factor in everything you do.
What’s dangerous is when we no longer expect such basic knowledge of each other. The funny, or perhaps tragic, thing about expectations, is that people tend to live up to them, but rarely exceed them.
We should expect more out of each other, and not be afraid to be critical of someone not living up to those expectations. If someone can’t take criticism then they aren’t dedicated enough to their craft to be taken seriously anyway. Being willing to fight to maintain high standards doesn’t make you a bad person, it makes you a leader.
A few years ago, at a soulless corporate conference in Portland, OR, I sat down in an enormous convention center ballroom, excited to attend the only talk about design on the entire schedule. What followed was 45 minutes of bad advice and offensive prejudice. But more concerning than the misguided speaker’s remarks and ironically poorly designed slide deck was how much the audience appeared so comfortable with her dogmatic sentiments and bigoted slurs. The talk was called “How Not to Design Like an Engineer”.
Throughout the talk, two common stereotypes were referred to again and again. Designer and engineer. Like all other stereotypes, they incite prejudice. But just as not all Italians are mobsters, not all designers are impractical, and not all engineers are aesthetically impaired.
As progressive and evolved as many of us may think we are, the truth is that most of us are quite prejudiced in this area. What does it mean to design like an engineer anyway? She went on to advise engineers to do whatever it takes to get a designer involved, and blindly follow their every whim. Given a view of humanity where specialization is the panacea to supposed finite limitations of human capacity, perhaps the speaker wasn’t too far off the mark. But I don’t buy into that view of humanity. None of us should.
It was that day that I realized just how bad things really were and decided to, at least eventually, write this essay. My message is simple. Designers and engineers should learn each other’s craft. Especially in open source. Or, to put it another way, become a designgineer.
If designers learn engineering, they will realize the value of open source, free licensing, remixing and reuse. They will become better designers as they move away from proprietary graphics tools and toward prototyping using open formats and standards. Their aptitude for details will bring a valuable motivation for cleanliness and consistency within a codebase.
If engineers learn design skills, they will realize the value of aesthetic experiences. They will become better engineers as they prioritize user experience, whether it be the user of an application, a consumer of an API or an engineer working on the same project with them. Their aptitude for process optimization will bring a fresh perspective on interaction design problems.
Both groups will benefit from a shared vocabulary as they communicate and solve problems together. With a greater understanding of each other, they will have more empathy and develop healthier and more supportive relationships with each other.
When I began work at the Wikimedia Foundation, I didn’t immediately get on well with the development community. I was a new hire, and many of these people had been contributing to this open source project for years. The more knowledge I gained of MediaWiki, the easier it became to work with them, and I eventually became one of them.
Shared knowledge creates a special bond between people. If you’ve ever seen two Arrested Development fans go on for hours quoting lines at each other, you know exactly what I mean. Mutual understanding increases good faith between contributors of a project, and if there’s anything that developers and designers need more of, it’s good faith.
Bike-shedding. It’s an incredible phenomenon where people who otherwise know how to choose their battles will dive in headfirst and spend hours fighting about trivial matters – all based on opinions. Plato once said that “opinion is the medium between knowledge and ignorance.” While engineering is hardly immune to this valueless pastime, it’s especially common in collaborative design.
The solution is always the same however, no matter what the field. Ideas should be tested and backed with data. We should demand such rigor, and subject ourselves to the same standards. And for the record, the bike shed should always be painted green.
I want to come back to something I mentioned before, about barriers to entry. Specialized fields tend to grow these barriers somewhat organically. Specialized vocabulary is part of that barrier. If you’ve ever heard a designer say the word affordance, or an engineer use the word closure, you’ve seen it first hand.
Shared vocabulary is perhaps the most important kind of shared knowledge. Speaking to people in their own language demonstrates a level of respect and recognition of the value of their craft. When we learn another craft, the barriers come crumbling down.
In the project you’re working on now, I want you to think about the ratio of decisions you make on your own and those you make collaboratively. Each decision we make has consequences, some intended, some not. There will always be blind spots that cause unintended consequences. In hindsight we call these decisions mistakes. Collaboration with others is the most common defense against knowledge gaps, but this model breaks down at some point because it depends too much on communication and oversight. The more people involved that have a broad knowledge of the full stack, the fewer mistakes will be made.
Whether you are a ready to learn more about design or engineering, the way to learn a new craft is the same. Be patient. Give yourself projects. Do it your own way.
Patience is important when learning anything. Set aside a real amount of time and use it to explore and experiment. There are free courses from major universities, but research doesn’t have to be structured. If what you are doing doesn’t feel enjoyable, try it a different way. You will eventually strike a nerve and get sucked in, at which point it will feel more like play than work.
Unless you are going to take a class that will provide assignments, you will need come up with them yourself. The best way to go about doing this is to donate your efforts. Burgeoning engineers can release their work under open licenses and build upon existing open source projects. When learning design, you can create things for people who desperately want or need them. Free work for worthy causes gives you motivation to complete the work without the pressure to perform at a professional level. Personal projects done in private are very easy to drop, so if you are going that route you will need to be very disciplined.
I want you to get serious about learning another craft, but I’m not suggesting you do so at the detriment of what makes you awesome. Approaching a new craft should not be an act of abandoning the ones you already know. Sketch out your program on paper before coding, or use Github to store and share design work. When attention to visual detail and knowledge of implementation are combined, your creative process will be set free.
Step out of your comfort zone and get serious about adjacent crafts. It will make you better at what you do, and you may find a passion you never knew was there.