Rake Routes

by Stephen Ball

Program Like a Videogamer

Videogames are coolVideogames are cool

I see a lot of you out there worried about the next step in your programming career. Or even worried about the next step when learning a new framework or language. Today let me try to assuage some of that fear by describing my approach.

What button is jump?

Programming is an amazing job. It can also be extremely stressful. There are few industries that move as quickly and completely as programming, especially web programming. Were you using Rails five years ago, ten years ago, fifteen years ago? Five years ago Ruby web devs still had to choose between merb and Rails 2. Ten years ago Rails wasn’t even publicly available. Fifteen years ago and I don’t think it was even a glint in DHHs eye: we were all coding Java and mod_perl in caves and wielding blunt objects.

The pace isn’t slowing down. Rails 4 will be out soon, and there are plenty of other frameworks that you could be keeping up with to mine for implementation ideas if nothing else. Thanks to the advent of mobile platforms there are now more browsers to target, not less.

Even within the Rails framework there’s a lot to keep up with. The latest in cutting edge domain modeling. Two Rails stacks, using plain old Ruby objects, the service layer, testing testing testing.

To both experienced and new programmers it’s hard to even know where to begin. Programming news can be a source of stress and anxiety. That’s no fun. I want you to have fun, so here’s what works for me. Let’s start at the beginning: how I learn.

Embrace failure as a means to learn

Videogamers embrace failure as a requirement for progress. No matter how easy the videogame is you will fail at some point before you reach the end. In a videogame, failure is the primary mechanism for learning. Learning how a game works” and what it expects. The same method can be used to learn a new programming language, framework, or technique.

When there’s a new technique I want to try, or a new gem I saw on Railscasts, or I want to explore a programming idea I heard I’ll just create a blank directory. Usually I won’t even give it a proper name, because naming is hard. Then I make it my mission to write bad code. I don’t just ignore or disregard mistakes, I set out with the goal to make mistakes. Once I’ve done it all wrong, then I can spiral in towards actually understanding what’s going on.

Want to know Rails? Break it. Break it to pieces. Delete all of application.rb and see what happens. Create controllers that pull data from files instead of databases. Create views that initialize variables and contain huge swaths of business logic. Create models that contruct HTML and JavaScript. Tie it all together with duct tape and CoffeeScript. Test nothing, test everything. Build models that only contain one field. Build a model that houses every piece of data your application could possibly need.

I find that if I think too much about how to best approach even a simple learning experiment I’ll start overanalyzing every little thing: will this directory/application name make sense in six months? Am I coding X in the best possible way? etc. This is a trap!

Admiral Ackbar: He knows when something is a trap.Admiral Ackbar: He knows when something is a trap.

It’s a trap in that you’ll waste all of your time worrying about never making a mistake instead of actually learning something useful. We programmers have an interesting and amazing field. We are a lot of very smart people arguing very heatedly about how to best make our jobs easier. This is awesome. But it can also be intimidating. Oh no! You’re using factory_girl, that’s so passé! Don’t worry about it.

Think about a fighting game. Street Fighter II, Mortal Kombat, Soul Calibur, whatever. Is there one character that’s correct? Well, yes and the answer is Chun Li. But any of the characters have viable playing strategies.

Many heated arguments about languages, frameworks, and/or process fail to recognize that. They had a bad time trying to play as Voldo for a startup this one time and so they’ve come away from that with the certain knowledge that Voldo sucks and no one should ever play as him/her/it whatever. The same goes for minitest/rspec or delayed job/resque/beanstalkd. All of these tools were written to scratch a specific itch. If you don’t like one, then that doesn’t mean that no one does or that no useful work can come out of them.

Ok? Ok.

Play that game!

Stomping one Goomba isn’t the end.

Super Mario Bros World 1-1Super Mario Bros World 1-1

I also make time to practice fundamentals. That is, code up a Rails application that I’ve coded up dozens of times. Maybe I’ll vary things or take a slightly different approach, but not usually. I like to say that even Jordan practiced free throws.

I’ll also periodically go through all the cool sites we have now that go through Ruby fundamentals. Ruby Monks for example, really cool stuff. Benjamin Fleischer compiled a list of resource for learning Ruby and general programming in an epic github repo: bf4/learning

Going through one Rails tutorial is like one level of a videogame. You’ve made progress, but Bowser is still out there. Hmm, what’s Bowser in Rails? Maybe splitting a complex app into a few focused Rails engines? I should think these analogies through more.

New games? Yay! New games!

Having a solid grasp of the fundamentals goes a long way towards feeling confident, at least for me, when trying to keep up with the news. Once you’ve learned a few frameworks or langauges (or beaten a few videogames) you get excited to learn about a new one on the horizon or released on github. I had a blast playing with meteor one afternoon, for example.

How do you know which tool or method to try out? It doesn’t matter, just pick one that interests you. You aren’t buying a lifetime stake in your experiment, you’re just experimenting.

You can choose to bring in some rigor and approach the framework with a fundamental project, follow their given tutorials, or just mess around and guess how things work. If it’s a completely unfamiliar framework or language you’ll probably have to stick to the tutorials (e.g. playing a new videogame genre for the first time) but if you’re in familiar territory (e.g. a new version of one of your languages) then it’s fun to poke around for a while for surprises.

Have fun!

If you aren’t having fun and your job is programming then you need to rethink things or find a better place to work. I dread the time when the other shoe drops and the rest of the world realizes that we programmers get to play all day and call it work. :-)

Up next Gem Spotlight: interactive_editor Today we’ll take a quick look at one of my favorite gems: interactive_editor. Have you ever been in a REPL session (rails console, irb, pry, etc.) Customize Your IRB You probably spend a lot of time in IRB (or the Rails console) but have you taken the time to customize it? Today we’ll take a look at the things
Latest posts Where did the recent Elixir posts go? A subtle Go bug that types cannot help with swapcase with the tr command nice go test output See where vim settings came from Containers in the real world and backpressure in distributed systems Elixir Phoenix and “role postgres does not exist” From awk to a Dockerized Ruby Script Finding leap years with the cal command The Problem of State Clojure Functions in Four Ways See Some Clojure A simple language spec isn’t a feature when you’re building applications The Fastest Possible Tests Shrink your data into bitfields (and out again) Every “if” statement is an object waiting to be extracted Choose Generic Tools Hyperlinks you might find interesting — #4 Running bundle install on rails master Use tldr for command line examples Friday Lunch Links — #3 Friday Lunch Links — #2 Logical Solver: Turn facts into conclusions Programming with jq Command line tools - jq Friday Lunch Links — #1 Why diversity matters Music for coding - October 2019 Code puzzles are a poor way to gauge technical candidates Add vim to a pipeline with vipe Connecting Objects with Observable