This is part 3 of an ongoing series detailing my journey from total noob to hobbyist coder. I share my thoughts as I learn the basics of programming. You can find the rest of the series here.
To help get me into the programming mindset, or maybe to cleverly sabotage my work ethic, a colleague recently introduced me to a game called Seven Billion Humans. You command small squads of workers through If statements, loops, and basic assignments of memory.
One of the most fascinating lessons in the game is that you can write great code to optimize for size or speed, but you can’t necessarily find a solution that simultaneously optimizes for both. Before I started playing, I had assumed the ideal software would approach a sort of zen koan, something that packed the greatest possible productivity into the fewest number of characters, because simplicity is an essential virtue that builds on itself.
To get myself through some of the trickier scenarios, I would often resort to a chain of if statements, each one defaulting to the next. I’d add a big jump at the end, so workers could return to the first task. Pretty quickly, however, you learn that this is a terribly inefficient way to write your instructions. Instead, you start crafting tighter internal loops with if/else clauses that let workers default to a second track when the first one fails. If neither options is available, then they can move on down the line.
I’m not certain, but I think this gets back to the essential truth at the heart of the most popular Stack Overflow question of all time. Better to ask forgiveness, than permission, might be a layman’s way of phrasing it. Build in redundancies that let your first choice for an executable action fail and default to a second or a third. I am still a beginner, far from the level of skill that would require me to use glue code between libraries, but I can already see the thought process that pushes you down that path.
If I’ve invested 15 or 20 minutes into a level and cobbled together a set of instructions that get me 95% of the way to beating the mission, I will usually try and find a little glue to make the whole thing hold together long enough to work, rather than going back to square one and building something that avoids the structural mistakes. I was the same way as an English major in college. If I had written a 10 page paper and it just wasn’t gelling, I would try rearranging the order of the sections or adding better transitions, before admitting defeat and working on a new thesis.
Another revelation that comes to you slowly, in drips and drops across different levels, until it finally solidifies into a deeper epiphany, is the way in which a solution can succeed despite producing edge cases that can slowly build into critical flaws. At first, the game presents you with levels where a worker can perish—falling down a hole or being eaten by a shredder—and you can still achieve victory and move on to the next challenge.
Later on, however, levels begin to require that all workers survive in order for you to succeed. I realized that this is probably what it feels like to start working on software at scale. The little bugs that don’t bother you when you have just a few hundred users start to create serious problems when you have tens of thousands. And unlike the levels in a video game, you don’t get a fresh start with every new rung on the ladder. Instead, you need to patch things up enough to keep them from breaking, accept that you’re adding to your technical debt, and keep on building.
All this highfalutin theoretical knowledge is wonderful! I’m having so many epiphanies I can barely keep up, but of course when it comes down to the actual work on FreeCodeCamp, I’m still struggling with the basics in a lot of ways. This reminds me again of my 15 year journey through martial arts. You show up in the dojo and on the first day you learn some basic moves. Often, after the physical exercise is done but before class is dismissed, the sensei will give a little bit of a lecture. It’s a chance to instill certain moral values and sprinkle kernels of wisdom to their new students.
The eager student will often find ways to demonstrate their new techniques and ideas, explaining to friends or even strangers at a bar exactly how one should behave in a fight in order to come out as the victor. It’s not till you get in a real fight that you realize there is a big difference between philosophical notions and techniques trained on a willing opponent and what works in combat. Your body needs another thousand hours of practice, or even 10,000 hours, in order to actually put that to use in a situation where somebody isn’t helping you along.
I’ve got lots of great insight into coding from playing these games, but I still haven’t managed to create my GitHub account, auth in, and connect it to the working group of peers going through the stack coding training with me. 7 Billion Humans has given me some smart things to say if parallel programming comes up at a cocktail party. But I can’t share a repository with my colleagues or begin to even offer a tiny bit of help when it comes to real engineering. It was a way to convince myself I was learning while having fun, but it was no substitute for the grind of the basics.
As Jerome Hardaway, the founder of Veterans Who Code, told us during a recent interview, “ I think the most I learned out of my bootcamp was git,” he said. “If you want to become a developer today, you need to started learning git and command line yesterday. Those are two skills that I think people don't give enough respect to.” Today I finally got around to installing git. I opened up a Terminal window on a Mac for the first time. It brought me back to my teenage years, when I spent countless hours playing games in MS-DOS. I haven’t poked around in this kind of file system since I was entering cheat codes for WarCraft II and SimCity. It feels odd to be back—and frightening. Like I might accidently input some command that would wipe out my whole machine. Like taking off the hard candy shell of pre-approved apps vetted by a corporate store, leaving only the soft gooey center that will melt in the wrong conditions and make a mess of everything.
So here’s my New Year’s resolution. Time to quit playing games, roll up my sleeves, and do the hard work of failing, flailing around, and learning the basics. We’ll be taking two weeks off the podcast, and this will be my last post in this series for the year. I’ll see you in 2020 with a few new ideas.