Programming insights to Storytelling, it's all here.
I often destroyed our home computer when I was a kid. Armed with only 2GB of storage, I'd constantly hunt for files to delete to save space. But I learned the hard way that .ini files are actually important. After the computer failed to boot, I would have to reinstall Windows and Office 97. My father spent countless hours in the Office Suite and always reminded me to make sure I installed MS Excel. I didn't understand what it was for. The interface looked very confusing to me.
Here is a realization I made recently. I'm sitting in a room full of smart people. On one side are developers who understand the ins and outs of our microservice architecture. On the other are the front-end developers who can debug React in their sleep. In front of me is the product team that has memorized every possible user path that exists on our website. And then, there is me. The lead developer. I don't have the deepest expertise on any single technology.
Google just released the future of their Chrome browser. To put it simply, it's AI everything. Meta also released their new smart glasses, complete with a "neural" wristband for input. It too is AI everything. The more I watched these product launches, with their proclamations about the future, the more I was reminded of this observation from Catch-22:
After walking up a hill and being completely out of breath, I knew it was time for a change. Now, the moment I get home from work, I lace up my running shoes and hit the pavement. After a few weeks, my body started to crave that movement, I couldn't stop even if I wanted to. It became automatic. When you set your bedtime to 10 PM and follow it religiously, as soon as 9:45 hits, your eyelids grow heavy. When lunch is at noon, your stomach starts rumbling at 11:58. That's the result of forming a habit. Repetitive actions carve neural pathways in your brain until they become second nature.
When I saw new questions on Stackoverflow, I followed 3 simple steps. First I'd read the question, ask clarifying questions in the comment section, and then I would start writing a comprehensive answer. But one time, someone asked a question and I eagerly jumped to the comment to make a bold statement. "They are absolutely wrong! Don't believe what people say." When I think about it now, I wish I wasn't so eager to get those virtual points.
Every problem, every limitation, every frustrating debug session seemed to have the same solution: Use a modern solution. Modern encryption algorithms. Modern deployment pipelines. Modern database solutions. The word modern has become the cure-all solution, promising to solve not just our immediate problems, but somehow prevent future ones entirely.
Early in my career, I worked alongside a seasoned C programmer who had finally embraced web development. The company had acquired a successful website built in Perl by someone who, while brilliant, wasn't entirely technical. The codebase was a fascinating mess. print commands interwoven with HTML, complex business logic, database calls, and conditional statements all tangled together in ways that would make you want to restart from scratch!
Maybe it was a decade ago when it seemed like every single game developer started believing that all games should be open world. Infinite possibilities, player freedom, emergent storytelling, who wouldn't want that? But open world design introduced new problems that linear games never faced. Players would get lost in meaningless side quests while the main story waited forgotten. Developers would pile on features that didn't serve the core experience. Worst of all, players often couldn't tell when they'd actually "won." I sank an unhealthy amount of time into Metal Gear Solid V when it came out, wandering its open world long after I'd completed every meaningful objective, never quite sure if I was done or just... tired.
A few years back, I was running a CI/CD pipeline from a codebase that just kept failing. It pulled the code successfully, it passed the test, the docker image was built, but then it would fail. Each run took around 15 minutes to fail, meaning whatever change I made had to take at least 15 minutes before I knew if it was successful or not. Of course, it failed multiple times before I figured out a solution. When I was done, I wasn't frustrated with the small mistake I had made, I was frustrated by the time it took to get any sort of feedback.
Writing code is easy. Once you have a solution in mind, and have mastered the syntax of your favorite programming language, writing code is easy. Having an LLM write entire functions for you? Even easier. But the hard part isn’t the writing. It’s the reading. It’s the time it takes to load the mental model of the system into your head. That’s where all the cost really is.
