The Shadow Artist, The Software Engineer: Getters, Setters, and Other Things I Loved Without Knowing Why - Robert Simoes

Skip to content

Robert Simoes

In Julia Cameron’s The Artist’s Way, she defines a “shadow artist” as someone who works near an artistic outlet without ever fully owning it. For example, the music producer who promotes concerts, the novelist who goes into journalism, the filmmaker who becomes a critic. Each profession scratches an itch of artistic motivation, but never satisfies it.

What drew me to software was not the job listing prose. Not solving difficult technical problems using AI, i.e., tokenmaxxing to feed the IPO roadshow; nor taking technical debt as an exciting challenge, i.e., unmaintained code can never be a systemic failure, rather, a fun interactive escape room for hardcore engineers; not even my favourite, having a firm grasp of data structures and algorithms, i.e., setting aside the Staff Engineer interview failed last week for not using optimal recursion, using the O(n^2) iterative solution as a sober vanguard to code clarity, brevity, and pragmatism. No, these virtues aside, what drew me to software was, strangely enough, the qualities it shares with writing.

I’m drawn to software development, a stark contrast to my incompetence with physical objects because of Turing’s insight. Turing revealed that any human step-by-step process could be simplified into symbolic manipulation for a Turing machine. In short, a computer can do almost anything you can think of. I trust you will be careful in sharing this coveted knowledge, though, more-so if Sammy Super Product Manager comes asking.

No, no, I can assure you, Sammy, it can’t be done in less than 2 weeks. That’s just the elementary limitations of computers. Turing Machines and such. Complexity and other mathematics. You know. Trust me, dear Sammy, I have a degree in the Science of Computational Machines.

So long as you stay shackled to your two-dimensional plane, or 8.5 by 11 page, you can create anything your mind can conceive (the effort involved or whether anyone cares is another matter). Imagination without construction, however, is just delusion.

Just like elegant writing, code that is well-organized has a pleasing rhythm. In programming, and I trust the secrets of my heart with you now, dear reader, I always felt glorious satisfaction in defining the getter and setter functions of a newborn class. A way to set and a way to get: clear, structured, and correct. Imagine now this father’s joy, seeing their first child class exit the compiler’s womb, asking only what variable to set its name to. It’s the same ritual of firming the paper three times before placing your first blemishing ink mark on the page. How could anyone live without this?

With joy, I laboured in the intense “needed it last week” coding mines, looking for metaphors and analogies to link the abstract classes. Some might question the elegance of a FactoryProviderManager building AbstractFactory classes, demanding simplicity instead. But this is naïve. Even if it was useless to write and refactored later, the structure itself demands an audience. My shameful satire aside, the same structural instinct found in building a sentence drew me into programming too—the pleasure of hanging just enough ornaments on a branch of vocabulary to catch the light, and no more. Thinking about what to expose, what to hide, what needs to be left off the tree entirely. And you might not believe it, but this wasn’t even the major fascination.

During a passionate debate with Majest Claude, who I’m sure will be our future governor, I discovered my passion for naming. Phil Karlton states: “There are only two hard things in Computer Science: cache invalidation and naming things.” Strangely, the naming aspect of computer programming was something I revelled in. Writing acts to clothe the invisible forces and make them visible; and herein, naming becomes an anchor point.

So then, when a top-down mandate comes to, “Use sensible and descriptive names for new repositories,” One would naturally expect to hear shouts of tyranny, great tyranny! Even quieted, those passionate coding compatriots, held down in their shelled foxholes of git commits, unfazed by the hollow utilitarian victories of upper management, would sooner see an AI agent destroy production for the third time this month, than drop their rebellious naming tendencies. To clandestine operations they turn and resist. Shortening those oppressive names into acronyms to comply: the Long Term Storage Service becomes the “L+ Service” in TDD, PRD & other alphabet soup documents. It’s a shallow victory, though. Deep down, the shadow artists know they love descriptive names and resist only being told what to do.

AI coding agents, in that manner, have dulled a lot of interest in programming and software development, and I don’t think I’m alone there. Active boredom is a recurring theme outside the realms of careermaxxing....