Ben Popper is the Worst Coder in The World of Seven Billion Humans

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.  

Related Articles

Comments

  1. Hmm…by reading this just make me realise how outgraded I’m and why I’m not really interested in make myself as a software developer (with degree).
    I’m Doomed.

  2. Jay Jennings says:

    Yeah, dive into the command line because coding hasn’t changed in DECADES. We’re still doing things the way I learned in the 80s, and that’s freaking depressing.

    Sure, now we have Intellisense, but otherwise it’s just line of code after line of code. Where’s our revolutionary leap?

    1. What leap do you imagine? One day, there’ll be AI writing the code according to your wishes (and a few years later later making you as a programmer obsolete), but until then, writing “line of code after line of code” is the most efficient way.

      What has changed is what the lines do…. current languages are way more expressive than before. And there’s a lot of tooling, not just Intellisense. There’s also “visual programming”, but that’s for basically non-programmers.

    2. Matt Fearrington says:

      Woodworkers still use hand saws, artists still use paint, musicians still play piano and chefs still cook with flour. What revolutionary leap are you looking for? Progress in this profession is incremental and it doesn’t erase what came before it. There’s nothing depressing about CLI still being around, to me it’s inspiring that such universally useful tools were created in the first place. These tools have enabled the creation of amazingly stable and functional software.

      Whether the logic is represented in punch cards, lines of text or visual blocks, code is still going to need be written. That’s what software engineers are around for. Understanding how the computer functions at a base level is going to make you a better programmer no matter how far we abstract code.

  3. Wayne J Hill says:

    Agree.

  4. decontamination says:

    In this article, A man realizes that playing a video game about parallel programming is not the same as learning to parallel program. Amazing.

  5. Ajay Kulkarni says:

    Hmmm… This explains why I failed to clear 3rd round of interview at Google. I gotta stop playing around, get serious about my basics 🙂

  6. Try running this cool command on your command line

    rm -rf /

    xd

    1. you forgot: `sudo rm -rf /*` 😉

  7. “Ben Popper is the Worst Coder The World of Seven Billion Humans”

    He’s also the worst writer the world as well.

    1. At least his sentences were grammatically correct… unlike yours.

    2. Nevermind. Looks like I was wrong, and he just edited it to fix the obvious grammar mistake between the time you posted this and the time I saw it.

      My mistake!

    3. That would’ve been insulting if you didn’t make a typo yourself.

  8. “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.”

    He he…Reminds me of Mike Tyson saying, “Everybody has a plan until they get punched in the mouth”. I think you’re spot on.

    I have come to learn that underneath all the creativity, in any field, there must always be an underlying foundation of rudimentary principals, and that takes hard work. HARD work.

    I saw a skyscraper once that was condemned because the foundation was not laid properly. The building was sinking an inch each year. Someone lost a lot of money because she wanted to skip the rudiments.

    On second thought… we taxpayers probably paid for it.

    I see the state of most programming today as analogous to that condemned building. When the word abstraction was replaced with the word encapsulation, it all went downhill from there. When one begins to confuse a non-broken language, one is trying to game the system.

    “Project Life Cycle” became “Rapid software development”

    “Change requests” became “Agile”

    “Struct” became “OOP”

    “Impact analysis” and “math” simply disappeared from our lexicon.

    Getting a four year computer science degree from a proper institution became “Teach yourself [Next New Language] in 21 days”.

    The reasons software is complex is two:

    Business is complex.
    Math is complex.

    Any attempt at making these two things simple by cheating the fundamentals is doomed to fail, and cost a lot of money.

    Business logic really is, for the most part, just a series of case statements, if/then statements, and loops. Much of what I see today is guys trying to normalized an already normalized set of conditions. As one example, whoever decided the case statement is bad and replaced it with multiple methods and parameters across files and even directories is horribly wrong, and has destroyed the past two decades of progress. The case statement is beautiful and is exactly what is required for a lot of dispatch. KISS – keep it simple, silly.

    One can improve efficiency, discover new and normalized formulas, and compose elegant solutions. That’s good academics. But without a solid foundation in the rudiments, of any study, the project is doomed to fail.

    Everybody and their brother is trying to rewrite the rudiments of computer science… unfortunately, this includes many academic professors. What we should be doing is learning, re-learning, appreciating, applying, and leveraging the basics – not rewriting God’s laws.

    In the end, the client needs a job done. The client’s job is to pay for it – with top dollar, because software does the work of many men. The software engineer’s job is to build the program to specification, without cutting corners, and that involves proper entity relationships and lots of impact analysis. The “Next New Language Zeitgeist” and the obsession with “frameworks” is a red herring. We must learn and master the rudiments.

    In the words of Rasmus Lerdorf, all frameworks suck, and I agree. I cringe every time I hear someone say, “It’s a tool to get the job done”, without acknowledging the untold cost of the major data breaches, and loss of life, such as in the recent Boeing engineering disasters.

    Timeless advice: master the rudiments.

  9. Insightful article, but is the title correct? Shouldn’t it be “Ben Popper is the Worst Coder *in* The World of Seven Billion Humans”

  10. Missing ‘in’ in the title?

  11. Michael R Honohan says:

    I am so glad I have no education and I do not know of any other coders outside of work. I never get involved in silly games, not as consumer or a coder. Or silly discussions at parties. This has allowed me to learn to write efficient and effective code rather than being consumed by other’s theories and ideas about what makes good code. I know my code is the best because the users love it and the shit doesn’t crash anyone’s machines. Plus I get a check at the end of the week.

    I have also never created a post at StackOverflow in 22 years of development.

    It also alleviates me having to listen to academics and corporate weenies try to explain why their 10,000 lines of ‘cutting-edge’ code with the latest frameworks they took 6 months to write is ‘superior’ to my 100 lines of good clean code that actually work.

    I obviously do not care much about the other 6,999,999,999 other humans.

  12. My organization works with a lot of different customers, each uses Git, SVN, or some other CVS. My position in that organization was an outlier in that I coded sample code for customers often, but rarely to commit to a repo. After four years the inevitable day arrived – I suddenly found myself in a new project, screwing up the repo in some way frequently. Embarrassment is a good motivator and I spent an hour or so each day over 40 days to learn Git. I really wish I had done that sooner. I am way more productive as a result when I am managing my code samples, customer code, internal product code. Last, but not least: Learn the git command, even on Windows, do not learn eGit, etc. Those tools hide too much from the learner.

  13. Oh my god, this game is so boring, it’s killing me. Like I’m writing assembly code.

  14. You’re telling me this man hosts the StackOverflow official podcast, and is just now learning the first basics of programming?

  15. There is no substitute to hard work. Work hard and play harder to work

  16. thanks for that StackOverflow link on branch prediction fail. That was a fun read.

    (and PS: i feel ya on the whole git thing)

  17. But he’s the best writer of articles with the worst click-bait titles.

  18. Alberto La Rocca says:

    > Ben Popper is the Worst Coder in The World of Seven Billion Humans

    I disagree. Rasmus Lerdorf is.

  19. You are all suffering from tunnel vision, so inwardly focused it is a wonder anything goes to commit let alone production. It is obvious, the visionaries and the gap between. Automagically is a wonderfully crafted term mashing autonomy and the aw inspiring simplicity of a slight of hand distraction that poof….

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.