D is for Development
Learning how to think: small epiphanies of a designer learning to code.
I’m a designer learning to code, but this isn’t another article advocating all designers learn to code. Or another article advocating all designers not learn to code. Nor is it a comment on the value and mission of organizations like Code.org in the US or Year of Code in the UK, or the many great services encouraging everyone from kindergarten kids to grandparents to roll up their sleeves and join the programming party.
Learning to code has been revelatory for me, on a fundamentally personal level.
And so ignoring all polemic on who should and shouldn’t learn to code and why and how and when, it felt important to write down some of what it has meant for me — mentally, emotionally, and maybe even ‘spiritually’ (if you ask me at the right moment).
The unknown can often be daunting, and programming is no exception. If I’d known all the following sooner, I might not have delayed for quite so long.
I better understand the unique value of ‘flow’, and my appetite for patient problem-solving has increased exponentially.
I was an art-crazed kid, I used to spend hours getting lost in drawing and painting. I didn’t know it at the time, but that was ‘flow’ — being completely absorbed in and focused on a task. With programming that state of immersion has been different. The focus, and thought processes required, engage entirely different parts of my mind to those hours lost drawing or painting.
Separately, I consider myself to be logic-driven but I was never much of a mathematician. Code has undoubtedly expanded my capacity for patient, detail-oriented problem-solving. A product, I‘m sure, of exercising the faculties used in those deep periods of concentration.
I have more, not less, reverence for the devices I own and people that make them.
Being a life-long technophile, with a good few years behind me working with developers, I’ve always had the utmost respect for engineers and the technically-minded. I wondered if learning code would be like ‘meeting the wizard’, that reducing the mystery would reduce the magic. But the opposite is true. The more I know the more respect I have for the development community.
My views on the nature of thinking have changed.
Steve Jobs once said that ‘everyone in this country should learn how to program a computer, should learn a computer language, because it teaches you how to think’. I think he was right on that.
And yet, as powerful as the ‘thinking tools’ offered by programming may be, I’m also more keenly aware of how limited computers can be in contrast to the mind. For example, a child can intuitively tell two objects are similar without needing to ‘process’ thousands of such objects to determine similar properties. This has two key consequences: greater awe at the workings of the mind, and greater awe for the people who have tried to replicate mental processes mechanically from Babbage through Turing and onwards. In some ways when we are learning to think in the way Jobs described, we are learning to think (just a little bit) like those innovators and geniuses who led the way to today’s computing.
It’s deeply emotional, and encourages delayed reward.
Given that successful programming requires drawing on logic above all else, the emotional side is perhaps too often over-looked. In my limited time I’ve certainly experienced extremes of frustration and elation, as intractable problems, errors and blocks give way to solutions. And the longer the struggle, the greater the relief and reward. That’s a journey everyone should frequent, in my mind, as our expectations for instant gratification extend into more and more parts of life and culture.
It’s empowering.
Probably the most obvious point, but I could hardly leave this out. From being an avid user of all kinds of devices and services, to having ideas for products and services myself, nothing is better than the feeling that the realization of such ideas is within my grasp — not impossible, or else dependent on someone else. And as a user, a knowledge of the underlying workings means more control, understanding and empathy with product and service creators.
All this may be achingly obvious to other programmers, but for me it was bound up in the mystery and intimidation of an otherwise daunting unfamiliar world. My efforts to teach myself, prior to joining the excellent MFA Interaction Design program at SVA, had been limited and frequently frustrating. But with a little help, and encouragement leaping the first few conceptual hurdles, a world opened up and I won’t look back.
Most of the dialogue around learning to code seems to focus on equipping the next generation with the skills they’ll need for a technology-driven economy, and implicitly that if we don’t encourage this generation to code the economy will lag behind others. On a narrower level, a similar argument exists for designers to reach beyond their current skill sets or else fall behind more technically-able peers. Too little of the discourse, at least that I’ve encountered, examines the deeper personal benefits.
So perhaps instead of pressuring a generation of kids to get ahead, or scaring designers about their impending obsolescence, someone should be talking about how effing rewarding writing code can be.
Shout out to Joel Califa for his input.
