Coding Like Gomer Goof
There's an undeniable appeal to the fearless prototype approach to coding. My third and final archetype is comic hero Gaston Lagaffe, aka Gomer Goof.
Join the DZone community and get the full member experience.Join For Free
In my two previous posts I brought up directors Stanley Kubrick and Woody Allen to illustrate the difference between the programming artist versus the pragmatist. Now I like to complete the triad with the proverbial kid in the candy store – or bull in the china shop. Not a film director will serve as the archetype, but my favourite Belgian comic hero Gaston Lagaffe by André Franquin. This slapstick humor series ran for three decades until the 1980s. The character was translated as Gomer Goof but will always be Guust Flater (Dutch) to me. You can skip the recent movie.
Gaston’s lowly job at the fictional editorial office of the actual Dupuis publishing house in Brussels was to sort the incoming mail. Instead, he wreaked constant havoc with his fascination for the applied sciences. Everything he touched came crashing down in the space of a single page, followed by a hefty repair bill from the real professionals or a trip to the emergency room. Gaston was impulsive, reckless, undeterred by his lack of know-how, and occasionally brilliant. He had a penchant for robotics and experimental chemistry, concocting a liquid soap that ate through the office floors like the alien’s blood.
Each day is a developmental Groundhog Day in Gaston's universe, because he must not grow up and develop. You can’t build a long-term character arc when each stunt is cause for dismissal. So, we start each work day with anticipatory relish, certain in the knowledge that all will turn to complete disaster and be forgotten on the next page.
Gaston tries his hand at software only once (offices had typewriters back then), but we can imagine what it must have looked like. However, bad code doesn’t lend itself well to physical comedy. It doesn’t smoke, smell, or explode. In software you can mess around with impunity, using any length of virtual duct tape, unaware of performance, security, or just not caring even if you are aware. Sloppy and undocumented, ignoring bureaucratic ISO norms for maintainability. There’s an undeniable appeal to this prototype approach. It’s the quickest, cheapest shortcut from brainwave to running software.
Shuffling bits around does not feel as if you could ever risk life and limb the same way that working with high voltage or corrosive fluids does. You’re not working with atoms that can harm you. Indeed, any bug-ridden body of code is perfectly harmless…. until you move it to production, and it does blow up in your face.
None of my code from the turn of the millennium has survived; the year I started programming for a living in the UK. I’m sure it was full of the Gaston touch. I argue in my defence that all the young guns took a relaxed stance towards software quality. It was a crazy time. Long since forgotten startups advertised their ludicrous ideas on primetime tv. Any arts graduate with a taste for programming could start a lucrative career, so I did. Only a small minority of teammates had CS degrees, and we all started like Gaston. Over time this mentality gave way to the notion that if a job’s worth doing it’s worth doing well. Gaston doesn’t care about doing a job well. His passion is that of a wayward child. His stamina lasts a few sleepless nights and then he tires of the idea.
Creative, meticulous and brimming with energy: few minds check all three boxes, and not at the same stage in their career. Creative yet sloppy people can have brilliant ideas with lousy execution. You can forbid them to touch code until they get organized, but you are throwing out the baby with the bath water. Babies can grow into responsible adults with proper supervision. We should both heed and nourish our inner Gaston and educate the ones in our team.
Louis Pasteur took saliva from rabid dogs foaming at the mouth in his quest for a vaccine. Scientific breakthroughs often happen through fearless stamina and personal risk-taking. A playful fascination for the tools without a goal to apply them to something useful is not a bad motivation to start a career in software. It’s a better indicator of success than a rational weighing of costs and benefits. I rationally decided to study economics straight out of high school and was back home eight months later.
Opinions expressed by DZone contributors are their own.