Designers: Learn Coding to Improve Relationships with Your Team
Much has been written about whether designers—especially those working in software environments—should “learn to code.” I’m reluctantly adding this piece to that corpus based (in part) on this sentiment from an experienced developer:
Design leaders concur:
And, look…I get it. It’s lousy if you feel pressured into doing so to earn respect or a “seat at the table.” Your talents are different.
But if building empathy is one of our specialties as designers, maybe learning a few basics is not such a bad idea—even if that’s all we get out of it. That said, I bet if you try it you’ll pick up something else.
The Hidden Bonus
Here’s a quick story: since big data and machine learning have become all the rage, I spent a little time understanding the basics of using large data sets to make predictions. Max Shron’s Thinking With Data looked like a gentle intro—a Data Science for Non-Majors, so to speak. I enjoyed the book, and it gave me a nice overview of the topic area. The best part, though, was how I was able to take one of his thinking tools out of the context of numerical predictions and apply it more generally to my design work. (It was pretty awesome, actually. Give CoNVO a try.)
“Bonuses” like this can be found in learning the basics of programming; that’s exactly the foundation of a new generation of computing literacy programs.
A recent series of articles in the New York Times pointed me to this TEDx presentation on computing by a professor at UC Berkeley. This professor’s ideas are much more than a job-training program; there’s a deliberate emphasis on improving critical thinking and problem-solving skills. Isn’t that right up our alley as designers, lest we be seen as mere Photoshop monkeys?
Why Not Learn?
I don’t understand the pushback on designers learning to code. Relationships improve within the team, designers gain new ways of thinking, and often they can broaden their impact. We’re arguing against learning?
I’ll grant it can be problematic if a designer dabbles in code and starts checking in changes headed for production, especially without quality control. Does the bug triage process know how to loop them in? Where are the limits on what they can touch? Who reviews their code? Once all these questions are answered, has all their time been absorbed, preventing them from considering divergent solutions to problems that may be poorly defined?
But again the key word is learning, as in learning to code and not coding all day. Software teams reap most of the benefits of having “technical designers” once those designers have obtained a certain level of proficiency in the team’s language of choice. You don’t necessarily need to go to the extent of having them check files into version control.
Again, think of it as sending (yourself or) your designers to a Programming for Non-Majors class. It’s about learning new ways to think and having higher-bandwidth conversations with your teammates. You can do the same thing for design, so why not try it for software development?
