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. I realized that this is probably what it feels like to start working on software at scale. Later on, however, levels begin to require that all workers survive in order for you to succeed. 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. 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.Īnother 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. I was the same way as an English major in college. 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 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. Build in redundancies that let your first choice for an executable action fail and default to a second or a third. Better to ask forgiveness, than permission, might be a layman’s way of phrasing it. 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. If neither options is available, then they can move on down the line. Instead, you start crafting tighter internal loops with if/else clauses that let workers default to a second track when the first one fails. Pretty quickly, however, you learn that this is a terribly inefficient way to write your instructions. I’d add a big jump at the end, so workers could return to the first task. 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. 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. 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. You command small squads of workers through If statements, loops, and basic assignments of memory. 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 can find the rest of the series here. I share my thoughts as I learn the basics of programming. This is part 3 of an ongoing series detailing my journey from total noob to hobbyist coder.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |