Should Designers Code??
No, Part Two: Know Versus Do.
There’s a recurring debate in our industry over the question of whether or not designers should write code. I answered the question more broadly in a previous post, but there is so much to say on the topic that I will put my more detailed thinking in subsequent posts, beginning with this one.
As I stated before, my answer to the perennial question is, “No, designers should not code.” But lurking behind the demand for designers to code is the more pertinent and useful question of whether or not designers should understand the strong forces that the coder has to wrestle with. My answer to that is an unequivocal “Yes!”
It’s not at all important that anyone other than a programmer know anything at all about the minutia of programming. Such details are useful only to the programmers themselves. Conversely, it’s vital that anyone who directs, advises, influences, or is influenced by, programmers know about the hugely powerful forces at work on the programmer and their world. These forces are frequently invisible, counter-intuitive, and completely unremarked even though they rule the developer’s world. Many programmers wrestle with these forces every day, yet are utterly unaware of their existence simply because no one talks about them.
I’m convinced that one of the motivations behind the developer’s plea for designers to know how to code is the developer’s own desire to make some sense of these larger forces that he can feel but doesn’t understand. The programmer makes sense of their world by coding, so it follows that they want others to do the same.
While years of programming is one good way to grow to appreciate these tacit forces, it’s not the only way. The main reason why developers want designers to learn to code isn’t because they need help coding, but because it’s the only way most programmers know to learn the nature of programming.
This isn’t the place to enumerate all these hidden “forces,” but here’s an example of what I mean.
Writing any software at all is very difficult, fraught with error, and takes years. On the other hand, calling pre-written routines inside a commercially available library of code is cheap, fast, easy, and fast. Therefore, and this is a fact of tremendous importance, most programming never gets attempted. Rather, programmers call existing libraries of code. This is one reason why our software tends to look the same, act the same, and seem to have a manifest destiny of behavior and scope. Another way to look at this conundrum is that innovation is much more expensive than simply rearranging the deck chairs. Developers under management’s schedule-gun will tell designers that, “We can’t build that. It’s technically impossible.” Translated into English, it means, “I would have to write original code rather than using something pre-written, and it means all of the risk, danger, time, and cost would be on my head. There’s no way I’m going to take that bullet for some unproven ‘user need’.”
Designers, managers, and others who work with developers don’t need to know a thing about actual coding, but they need to understand the impact of this — and many other — qualities and characteristics of programming.
It’s okay for a designer to insist that a programmer write something complicated and difficult from scratch, but they better be ready to make a strong case for the developer’s efforts. And the developer needs to trust that the designer understands the tradeoffs.
The Infantryman.
All my life I’ve been intrigued by war and the military. Even as a pre-teen, I was a voracious reader of military fiction and non-fiction, and I still am. The engineer in me was enthralled by the cool hardware: the tanks, guns, ships, and airplanes of the arsenal. Even more enthralling though, was the puzzle of soldierly behavior. How, I wondered endlessly, could those men at the Somme or Thermopylae have left the safety of their dugouts and walked into a certain death? How can someone write a final love note to their wife or mother, pin it to the wall of a trench with their knife, then go over the top into a hail of deadly machine gun bullets?
I’ve no doubt that my curiosity was impelled by a question common to all young males? Was I strong? Did I have courage? Did I have what it takes to do my duty regardless of the personal danger? Could I face death? Was I a man?
On the wall of my workshop is a framed memorial to my father-in-law, who served in World War II. He was a replacement second lieutenant in the First Infantry Division, entering combat in the icy winter of 1944, during the Battle of the Bulge. Ed was a smart and decent guy, and he managed to survive the battle. This was no small feat, as the life expectancy for replacement soldiers at that time was measured in hours, not days or weeks. A couple of the medals in his collection were earned in those frozen foxholes.
As any infantryman will tell you, the only medal worth a damn is the simple blue rifle of the Combat Infantryman’s Badge. You get it when you have been in combat. Thirty years of faithful service and exceptional performance in peacetime won’t get you that coveted rifle. It’s the difference between a veteran and a soldier. It means you have seen the elephant, that you have been to the edge and looked into the abyss.
In the early 1980s I discovered — and fell madly in love with — a nascent sport so new it didn’t even have a name. For years, I threw myself into it, playing every weekend without fail, and was a fanatic proselytizer of the sport. It involved going far into the deep, dark woods with compressed-air-powered industrial marking pistols, then hunting down your similarly-armed buddies, and shooting them. The game was essentially capture-the-flag, except that we were armed. Our pistols fired only a single shot at a time, we wore camouflage fatigues, and crawled and ran stealthily through the woods for hours. After several years of development and evolution, this sport has come to be known as Paintball. The game has changed somewhat — today it’s closer to volleyball — but back then it was remarkably similar to Napoleonic-era warfare.
Paintball answered my big question, and I’m sure that was part of its attraction. The fighting was close-in, dangerous, painful, personal, and was characterized by long, tense stretches interrupted by moments of sheer life-or-death panic. Somewhere in the back of my mind, I knew that getting “killed” by a paintball wasn’t the same as getting killed by a bullet, but when the starter’s whistle blew, and your teammates silently evaporated into the woods and you stood there all alone, you knew that it was real, that you were a target, that people with guns were out there right now hunting you down.
The sensation was pure and absolute. The adrenaline heightened my senses. I became a warrior, and my personal safety was rarely my foremost consideration. To my surprise, I occasionally found myself breaking from cover, yelling “ATTACK!” at the top of my voice, and leading my troops into a hail of paint pellets. Yes, I would lose myself in the rush of hot blood in combat. Yes, I would unthinkingly take a bullet for the team. Yes, I was a man.
Was I a combat veteran? Emphatically, no! Was I an infantryman? Emphatically, no! Was I entitled to the respect of a real soldier? Emphatically, no! Did I understand the soldier’s job? Yes. Did I have empathy for the veteran? Yes. Was I a better designer of markers and tactics? Yes. I knew, even though I didn’t “do.”
The best lesson.
I spent many years writing software, so, in the world of coding, I’m a real veteran. I’m entitled to the equivalent of the Combat Infantryman’s Badge for programmers. I’ve written compilers, games, business software, spreadsheets, word processors, geographical information systems, visual programming languages, critical path visualization software, and more. Did any of that make me a better designer? Sure it did. But the one single act that made me a great designer was stopping programming. When I abandoned the tools and practices of the coder, when I ceased coding to instead look back at my programming career and ask myself what mattered about it, is when I learned the most.
I immediately saw that being a programmer established a powerful mental framework for viewing the entire process of software development. It was abundantly clear that this framework was in conflict with the needs of the people who would use the software. The programmer has to serve two masters: the computer and the user. Programmers cohabit with the computer, but they rarely see the user.
What made me a good designer wasn’t my years of coding, but my profound understanding of the invisible demons programmers wrestle with. If a designer is skilled at their craft, knowledge of these development demons is what makes them successful at their job.
Unfortunately, there are plenty of working designers who are not skilled at their craft, just as there are plenty of developers who cannot code. The sad fact that there are more open jobs than there are competent practitioners is a powerful influence that muddies the water of what, exactly, should a designer know.
The primary responsibility of the interaction designer is to represent the interests of the user in the product creation process. They need to be as proficient in identifying users and understanding their motivations as developers are proficient in writing bug-free code. But while designers are weaned on the concept that developers implement their designs, developers are weaned on the concept that no one understands their work and that they are solely responsible for its behavior and its success. The younger cohort of developers who learned in a more collaborative world are more open to the direction of designers, but find themselves struggling with the competence gap, both of themselves and the designers.
You don’t have to do another person’s job to be able to work well with that person, but you have to understand the broad issues that your co-worker deals with. When that co-worker is ignorant of their own issues, all sorts of crazy notions emerge. Crazy notions like designers need to code.
Here’s Part One.
Here’s Part Three.
