Background
- When I was studying for the LSAT, I found it helpful to do other kinds of logic puzzles as a way of getting better at the LSAT's logic games. I learned certain lessons / best-practices from those other puzzles that I was able to then apply to the LSAT's games.
- I suspect that the same thing may be possible with programming; by playing these games, in which a lot of the variables/frustrations/distractions of normal programming have been removed (like spending time looking on Google to figure out what to do next, or not being able to understand the documentation), I suspect (hope) it will be easier to learn certain lessons about the 'best' way to do programming.
Lessons learned
Games
- Beginner-level
- LightBot - This one looks really well-done.
- CodeMonkey - Less well-done
- COLOBOT - Haven't checked this out yet, graphics aren't great
- Elevator Saga - the elevator programming game
- Human Resource Machine
- 2017.01.14 - Use comments to label portions (stubs) of your code so you can work on them one-at-a-time. I was working on a task that required some branching logic and I didn't have any comments to separate the different parts, and I ended up getting confused. Adding comments to divide up the different branches made it much easier to work on one part at a time.
- Learn Git Branching
- I'm not sure if this qualifies as 'programming', but I thought it was related enough to be worth including here.
- TIS-100
- This game isn't as hard to get into as it might seem from the screenshots. I'm only a few puzzles into it, so I'm sure it gets much harder, but the learning curve hasn't been killer so far (eg Dwarf Fortress). There are only ~10 commands to learn.
- Things I'm learning:
- It's serving as a great way to practice getting started on software projects. When I start a new puzzle I'm filled with that feeling of dread that I always get when I need to program a new thing, and the secret to success is to just crawl your way forward, to make any kind of change that puts you closer to the goal.
- When you're stuck, trying stepping through your code! It's amazing to me how often I resist doing this, and how quickly I often solve my problem once I do it.
- 2017.01.08 - This game is really making it clear to me how often it's the case that starting is the hardest part. I'm consistently surprised at how quickly a solution comes together once I get started, and how much less time it takes than what I estimated when I first looked at a given puzzle. Of course, the opposite is possible as well: thinking something will take one amount of time, and it actually will take far longer...
- 2017.01.13 - Signal Edge Detector - This one really hit home this idea: when you have a complicated project that will have multiple complicated parts, create a 'skeleton' / stub out different components and deal with them one-at-a-time. In this case, that means creating a kind of dummy function that returns dummy data, just for the purpose of getting the 'main' function up-and-running. Then go into those dummy functions and flesh them out.
But in the case of starting a company, this could mean something like "faking the back-end", where you have humans handling things that you eventually want the computer to be able to handle. That's what the Stripe founders did when they started, for example; they just wanted to see if people would use the front-end if it worked.- Also, don't spend time worrying about the efficiency of your solution until you have a working solution. Once you have a working solution, then go back and see how you might be able to make it faster.
- If you're stuck, write out exactly what it is you are stuck about.
- If you're stuck, write out a simple example in Notepad and write out the step-by-step process that would solve that simple example.
- 2017.01.14 - Interrupt Handler - If you feel stuck, try taking a break and coming back to the problem to look at it with a fresh set of eyes. I did this when I was doing problems on the LSAT and it really helped. In this case, when I came back I wrote out in Notepad what the transformation was that I wanted to do, decided to experiment with a slightly different way of doing things than I'd done it up until that point, and it worked immediately.
- 2017.01.15 - Signal Pattern Detector - Output a '1' if the last three inputs have been '0', and output a '0' otherwise.
- One of the things that struck me while working on this one is that the heart of these tasks is figuring out how to decompose the overall objective into smaller step-by-step objectives.
- The smaller objectives I came up with were: 1) move the input to the output, 2) Check if the input is a '0', and if it is, move a '1' to the output, and otherwise, move a '0' to the output, 3) The same as #2, except saving the last input as well, 4) The same as #3, but saving both the last input and the one before it. The epiphany I had was to see that I could simplify the problem by just checking the current input, and then just checking the current input and the one before it.
- Double-check things (like your understanding of what the computer is doing).
- In this case, I had first gotten the machine to display the correct output for one zero, and I then wanted to get it working for two zeroes. And I wrote some code that increased the number of test cases that I was passing. But right before I was about to go on to tackle three zeroes I asked myself, "Am I absolutely sure that code did what I thought it did?", and sure enough, when I double-checked, the code was actually getting everything right except for the case of two zeroes. Hopefully this screenshot will help somewhat:
- 2017.01.22 - If you're stuck, try writing out a high-level description of what the solution should do, and then gradually refine that description to get closer to what the actual code should look like.
- Analogy: When you're doing a drawing / painting, one technique people use is to start with a rough sketch and then gradually refine it.
- Screeps
- This one looks cool...
- ...it apparently has some kind of subscription model.
- Shenzhen I/O
Developers
Articles
- 2016.10.03 - RPS - Can videogames teach you programming?
- Human Resource Machine
- Hack ‘n’ Slash
- "you have an incredible amount of freedom in approaching every puzzle, but at the same time, it can be terribly intimidating if you don’t understand why your solution simply didn’t work. To be fair, though, that’s pretty much programming in a nutshell."
- difficulty spike makes Hack ‘n Slash a rough game to play, but if you can get past that, there’s a lot of good stuff to learn.
- As a game, Hack ‘n’ Slash has a lot of problems. As a programming tutorial, it’s markedly better. (...) So long as you’re prepared to learn the hard way just how much trial, error, and frustration goes into coding, you can come away with a firm grip on the systems and processes that underpin all languages of the modern era.
- TIS-100
- Summary: So, can you learn to program by playing games? I’d say yes, with a couple of caveats. First, the challenges of programming are rarely as clearly defined as the puzzles in the aforementioned games; project requirements often change multiple times during development, and sometimes you won’t even know whether what you’re trying to do is possible until you do it – or give up. (...) Second, games alone won’t turn you into John Carmack; they can teach you the basics and help hone a programming mindset, but you’ll still need to hit the virtual books before you’re ready to make the next DOOM.