How can craft help you gain traction? That was the question Harry and I explored in episode 41 of Traction Heroes.
I brought to the conversation a short reading from a book that had a big impact on my career, Chris Crawford’s The Art of Computer Game Design:
Games must be designed, but computers must be programmed. Both skills are rare and difficult to acquire, and their combination in one person is even more rare. For this reason many people have attempted to form design teams consisting of a nontechnical game designer and a non-artistic programmer. This system would work if either programming or game design were a straightforward process requiring little in the way of judicious trade-offs. The fact of the matter is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts together is rather like handcuffing a pole vaulter to a high jumper; their resultant disastrous performance is the inevitable result of their conflicting styles.
More specifically, the designer/programmer team is bound to fail because the designer will ignorantly make unrealistic demands on the programmer while failing to recognize golden opportunities arising during the programming. For example, when I designed the game Energy Czar (an energy-economics simulation game), I did not include an obviously desirable provision for recording the history of the player’s actions. During the final stages of the game’s development, virtually everyone associated with the project suggested such a feature. From technical experience, I knew that this feature would require an excessive amount of memory. A nontechnical designer would have insisted upon the feature, only to face the disaster of a program too big to fit into its allowed memory size.
Another example comes from Eastern Front (1941). While writing the code for the calendar computations, I realized that a simple insertion would allow me to change color register values every month. I took advantage of this opportunity to change the color of the trees every month. The improvement in the game is small, but it cost me only 24 bytes to install, so it proved to be a cost-effective improvement. A nontechnical game designer would never have noticed the opportunity; neither would a non-artistic programmer.
This image of two handcuffed athletes greatly influenced how I understand design. Simply put, people without hands-on knowledge of a system’s capabilities and constraints shouldn’t be making critical decisions about those systems. (You can guess where I fall on the “should designers learn to code?” question.)
Of course, this applies to more than just designing software. Managers should understand how the organizations they manage deliver value — and not just in theory, but hands-on, on the field. The obvious challenge: delegation. You won’t be effective if you over-manage. But in today’s complex ecosystems, it’s easier to fall prey to abstraction than the opposite.
Where do you land on this spectrum? Please let us know in the comments on YouTube. (We’d love to build more of an audience there now that we’re sharing videos of the shows.)