Coding

A lone engineer stands at the city gate. She built a subway station here three years ago on a sunny day. On this dark, foggy night, she wishes her flashlight shone brighter, her map was up to date and that the neon signs of Ginza weren’t powered by a frozen yogurt stand ten miles away. If you’re in production, product or some other non-tech discipline, you’ve probably found yourself face-to-face with a supposedly smart and experienced engineer saying they’re unable to tell you how long it’ll take to build your next feature. Maybe they asked for a day or five to think about it. Perhaps they even said they wouldn’t be able to provide a responsible estimate until work is already underway, essentially leaving you with a dice roll and hoping for a triple natural 20. ...

When I kick the bucket drum, I’ll leave behind three creations: my spawn and 10 buckets of bits. One bucket full of code and another brimming with notes. /* No, not these kinds of notes. */ Perhaps the artifact in this Game Over scene will instead be more akin to a single, large, loud volume where .exe and .wav files have gone to fade out their filename extensions and merge with abandon. In the game loop of my biocomputer, this is the degree to which for-loops and 16-bar loops play off each other and engage in a constant, consonant, interdisciplinary dance of call and response. I am reflecting not on some shallow, semantic version of symbols and cymbals in symbiosis but a real, requisite reciprocity recursing deep into namespace SubBass. ...

At some point, your co-worker (peer or otherwise), or even an entire team, will massively screw up. Or you will. Perhaps you already have. If the latter is true, congratulations – you’re in a great place to make a positive difference. I’m going to assume, perhaps barring certain egregious transgressions, that you already manage failure from a place of empathy and growth, not through shaming or punitive means. If that’s not the case, you’ll first have to look elsewhere for help to make that change. ...

Stravinsky talked about the concept of creative limitation in music being useful in order to reach new and different results. There have been TED talks on limitations as an upside. (LaaU?) Publications like Harvard Business Review and Forbes have written about constraints breeding creativity. Since the concept became somewhat popular, it can sometimes feel like way too much lemonade-making and not enough being pelted with a dozen lemons in the face with your eyes open. ...

While my perception of my own knowledge path has been something like “I know nothing” -> “I know everything” -> “I know nothing”, engineers at any level can become overly convinced that their own approach is the correct one. A junior engineer straight out of school may be overly biased toward approaches taught there, which may or may not be effective in, for instance, a heavily product- and market-driven environment. Someone with a few years of experience may, due to their own definition of what success looks like, believe they have arrived and there’s not much more to learn. (This was me during the dot-com bubble.) A senior engineer with a decade or more of either going deep or wide can become too set in their ways and reluctant to incorporate different thinking, like single-brain groupthink. The rock star engineer, if you subscribe to such a thing, may well have developed an ego matching the size and approach attributes of a tropical island dictatorship. ...