The tension of a creative playing software engineer

Before going any further, an important clarification is in order. I am not advocating for superficial generalism. Many people who call themselves generalists are, if we are being candid, competent at PowerPoint and conversation but unable to produce particularly impressive work in any single discipline. They know a little about many things, but not enough to build something substantial. This is not the model I admire. The model I believe in is closer to the historical idea of the polymath: a person who develops genuine, working competence across several domains and understands the structural relationships between them. There is a significant difference between breadth without depth and breadth supported by repeatedly earned depth. The first creates versatility as an aesthetic. The second creates synthesis. And synthesis is where unusual value tends to emerge.

There is a longstanding fiction that creative and technical work belong to different species. On one side sit the imaginative types, arranging ideas and arguing about tone of voice. On the other sit the engineers, quietly constructing systems of considerable complexity while pretending not to care about typography. This distinction has always seemed unconvincing. Both activities revolve around the same essential questions. What problem are we solving? How should the system be structured? Which constraints matter? How do the pieces fit together? How will another human being experience the result? The medium changes. The underlying mental process does not. A campaign is a system. A website is a system. A service is a system. A software platform is a system. The best practitioners in all of these fields are, in one form or another, architects.

The traditional agency model is optimized for specialization. Strategy writes the brief. Creative develops concepts. Design produces layouts. Developers implement. Producers prevent the entire machine from drifting into chaos. This structure works, but it assumes that knowledge should pass between departments rather than reside within individuals. That creates organizational clarity, but also translation loss. The strategist may not understand technical constraints. The developer may never hear the original reasoning. The designer may produce something elegant that collapses on contact with reality. The multidisciplinary practitioner short-circuits this process. That can be extraordinarily useful. It can also be commercially inconvenient. If one person can connect strategy, design, production and technology, several carefully maintained boundaries begin to look less inevitable. Organizations often prefer clean categories to individuals who move freely between them.

Clients frequently claim to value people who are both strategic and hands-on. In principle, this is true. In practice, procurement systems favor recognizable titles and predictable categories. It is easier to hire a developer, a designer or a strategist than someone who insists, somewhat inconveniently, on being all three. The multidisciplinary approach also complicates pricing. If the same person can define the problem, design the solution and build the mechanism, the distinction between planning and execution becomes less clear. This is efficient. It is also difficult to fit into familiar commercial structures. And familiar structures have a remarkable instinct for self-preservation.

From the beginning, the divide between “creative” and “technical” felt artificial. Graphic design is structured problem solving. Film production is systems orchestration. Copywriting is information architecture with better verbs. Software engineering is design under stricter logical constraints. The tools differ. The underlying habits are remarkably similar. One observes patterns, decomposes complexity, experiments, iterates and attempts to create something that works elegantly. Whether the output is a campaign, a service or a web application is almost secondary. This is one reason I eventually formalized the technical side of my work with a degree in information systems. Not because I was changing identities, but because I wanted a more rigorous vocabulary for instincts that had been present all along.

Studying information systems was less a conversion than a recognition. It provided structure and terminology for ways of thinking that had already shaped much of my work: systems thinking, information architecture, process design, data modeling, and the persistent desire to understand how things function beneath the surface. In retrospect, much of my earlier creative work was already technical. Large campaigns are operational systems. Productions are dependency graphs. Brand architectures are classification frameworks. Facilitated workshops are real-time decision engines with delightfully unpredictable human inputs. Software engineering simply makes these structures explicit. And, unlike some meetings, the compiler is admirably honest.

I sometimes describe myself as “a creative playing software engineer.” This is partly self-deprecating and partly true. It acknowledges that I arrived at software through an unconventional route. But it also understates the continuity. The same curiosity that once led me to dissect campaigns now leads me to design databases, deployment pipelines and publishing systems. The same satisfaction I once found in a well-constructed concept I now find in a coherent architecture. The medium has changed. The impulse has not.

There is one last point worth making. “Polymath” is a dangerous word to use about oneself. It tends to conjure images of Renaissance geniuses and impossibly gifted minds. Used carelessly, it can sound grandiose, self-important and slightly absurd. That is not what I mean. To me, the word does not imply exceptional intelligence or any special category of genius. It describes a particular temperament: a very curious person with a stubborn desire to understand how different systems work. Such people are drawn not to one domain, but to the structural similarities between many domains. They read widely, build obsessively and spend years acquiring enough practical competence to connect seemingly unrelated fields in useful ways. This is less glamorous than the title suggests. Most of the time it looks like late-night reading, self-directed projects and the repeated discovery of how much one still does not know. The defining trait is not brilliance. It is curiosity. And perhaps a certain inability to leave interesting questions alone. So if I occasionally use the word “polymath,” it should not be interpreted as a claim to genius. It is merely a concise way of saying: I am a very curious person who enjoys learning how things work and building at the intersections between disciplines. The title itself is unimportant. The curiosity behind it is what matters.