Everyone can make use of code today: entrepreneurs, designers, artists, a 10-year-old girl, or a 90-year-old man. Also, anyone can learn to code if they try — I wrote about it before, concluding you don’t need a degree to be any good:
Welcome to part 2
This time, I want to show you code in a different light — one with people at the forefront, not numbers or machines. Code literacy has become important in many professions, making it increasingly difficult to pinpoint where it fits as a skill. For example, designers use code to take ideas and prototypes to the next level, which has lead to the infamous question, “Should designers code?”.
"Maybe a better question could be: Should designers use code to design?"
Whatever the question or answer, we’re seeing more people who think and learn differently, wanting to understand code and use it in their own way. These are people with specialities in ‘artistry, empathy, and seeing the big picture’ — all skills of the right brain, as opposed to the left brain, as highlighted by Daniel Pink in Revenge of the Right Brain. His article suggests to me that the use of code in the future could differ from past norms:
"The world changed. The future no longer belongs to people who can reason with computer-like logic, speed, and precision. It belongs to a different kind of person with a different kind of mind."
I’ve experienced this myself having often crossed the lines between design and engineering, so hopefully in this article, I can show you a perspective on coding that spells the end of the stereotypical developer — there are coders who understand people and emotion (if there weren’t before)!
"There are coders who understand people and emotion (if there weren’t before)!"
Breaking coding stereotypes
I’m not sure why, but the minute I mention I can code, I’m suddenly put in the developer box. I think that's because programming has too often been linked with those who excel in maths and logic (or the left brainers) in the past. It’s evident in hiring too, with whiteboard coding interviews used to screen any job that involves code for those linear skills, as I found when interviewing with Google.
The job was on the design team as front-end developer — a design prototyping role. More of these jobs are emerging, where design and technical skills combine, since understanding the workings of both worlds can be invaluable. Anyway, despite the nature of the role, I was still hit with the same old whiteboard test, and here’s how it went:
Google interview ????
My thought process:
‘What? An algorithm in plain JavaScript... to make... rainbow text?’
‘How do I even write a JavaScript function without autocomplete helping me?’
‘I know the answer to this one... it’s on Google.’
‘Fine, let’s both just watch me struggle’
I’m still not sure how many use cases there are for creating 'rainbow text'.
Making it also requires a way of thinking that's different to what I’ve experienced when using code for design. Knowing how to loop through text in JavaScript is fine, but the small maths bits in the answer (e.g. 360 * i / text.length
) really tripped me up.
I never learned ‘how to crack the coding interview’, since I already struggle with calculating the change from buying a chocolate bar with a £10 note. And there’s no way I’m willing to spend 8 months learning how to pass a test just to get a job when I don’t enjoy it.
After realising I would need those left brain skills to really progress with a career in code, I went and wrote about it, then decided to focus on design as a profession employers would pay me for. Until that is, the perspective of code changes in the future, as Pink predicted (over 10 years ago): "Engineers will have to master different aptitudes, relying more on creativity than competence."
"Engineers will have to master different aptitudes, relying more on creativity than competence."
A different perspective of code
Giving up on programming as a career path didn’t stop me playing around with code though. If it’s possible to build something you’ve designed, why would you not want to?
Despite never understanding complex (or simple) algorithms and data structures, I was still able to take ideas from paper sketches, right through to coded prototypes for IBM’s Internet of Things. Furthermore, a lot of the code from my prototypes found its way into real products, so I can’t be that bad. In fact, I've found that I can create any type of app (iOS/Android/Web) without a problem, just by understanding frameworks and being able to ‘jigsaw’ pieces of code together.
Whenever there’s anything difficult, someone’s always done it before. All you need to understand is how to structure code so that you can reuse complicated algorithms that the smart people have created. It’s also pretty much how I got my computer science degree — by Googling Stackoverflow. I use this jigsaw method to make anything I want.
This brought me to realise whiteboard tests are tailored to find a specific type of coder — probably the person giving all the answers to my Stackoverflow questions. Considering the nature of how code is being adopted by creatives, I think this perspective could become outdated. The way I’ve used code, I found you don’t need to know that algorithm stuff.
Moreover, the skills you need to pass aren’t needed to do amazing things with code in the real world. For instance, Max Howell, creator of Homebrew (one of the most widely used open source software), legendarily tweeted the following:
Code in the design process
The ability to be rubbish at code but good with code suggests there are different ways of doing it, lending to different abilities — so maybe people can be good at code in different ways. Take this picture as a metaphor:
Along those lines (ignoring not all the animals can actually climb), I wonder if just the one way to measure coding ability is enough, especially as the use of code changes. For example Casey Reas, designer of Processing, suggests that code can be used as a tool for expression:
"Code isn’t so different from using typography or a camera to express yourself."
Bringing it closer to design, code can also be used as a powerful tool of expression for interactions. For instance, underlying every animation a designer creates in a prototyping tool is code. Therefore, by understanding the workings of medium you’re designing for, you can be even more expressive and intricate with what you create.
For example, I often throw random values into CSS animations just to test what’s possible (and because it’s fun). At the same time, I can use my understanding of design to spot animation transitions that create the emotional experience I want, such as more excitement or added personality.
Programming in this experimental way lets me use digital constraints whilst keeping people in mind. It’s often lead me to create something unexpected, but great. There are probably lots of arguments against using code like this, such as:
- Designers should focus on design, not code
- Understanding code is the job of a developer
And that’s fine. But for me, there’s nothing more satisfying than creating something real that you can put in someone’s hands, whilst breaking down walls in the process.
"Not every designer is a white man with a beard, and not every developer is a loner with a keyboard."
Learn if you want
I’d say not to let developer stereotypes or traditional whiteboard coding discourage you from learning if you really want to. To paraphrase Jonathan White (designer and developer at AirBnB), if you enjoy it, why not make it part of your craft.
If you do find yourself struggling, it might help to realise that it may not even be the code you’re struggling with. I was often frustrated too, until a friend made me realise something by telling me, "It's not the code you struggle with, it's the maths".
He was right, and I discovered alternative ways to learn. A resource that helped me most was Processing, described on their website as “a language for learning how to code within the context of the visual arts”.
Here are some resources that teach code with Processing to get you started:
"It’s not the code you struggle with, it’s the maths."
Overall, I came to the conclusion that some companies need to put people in boxes for various reasons, but we don’t fit. There seem to be separate boxes for design and development, which creates invisible walls, and a perception that code belongs in the developer box. Clearly, that isn’t true as code literacy, at least, is useful in any role.
I’ve found this out for myself, with my understanding of code helping me massively when combined with other skills such as design and writing. So much so, that I just joined the Marvel team where I’ll be combining roles in content/editorial and front-end code ????.