Line Rider is an extremely addictive web game. (Try playing it, and see when you can stop.) Now a lot of programmers would rather play that than work on their project. But actually, if you program right, you can actually make it fun instead of being a dreary bug-fixing experience.

First, what are the elements of Line Rider? There's 3 parts. There's the fun factor, which is achieved by watching the cartoon sledder drive over the track that you created. The more complex the track, the more "fun" you get by watching it.

Next, there's the design factor. Getting the actual control of where the sledder is going to run next is also fun. Using a pencil, you actually draw the track. In more advanced versions, you can use an eraser to take out mistakes.

Lastly, there's the problem factor. When you design the track, it's going to be prone to problems since you cannot exactly calculate where to rider is going to be thrown. This presents the challenge of fixing the problems to make the rider go smoothly. Even problem solving can be fun, if the problem can be overcome. Additional tools such as an eraser in other clones of Line Rider increase the ease at which users can fix their track.

So how does this tie into programming? It's actually fairly simple. When you are writing the program, you are essentially builing a track. When you test the program, you get enjoyment watching the output (hopefully).

So why do programmers not work for free, since they're essetially "playing Line Rider"? Well, usually the biggest problem presented in programming is the bug fixing. Every program is prone to them, and they usually prevent or halt execution of the code you have written. But wait, don't Line Rider tracks have problems when you're building them?

Imagine trying to build a huge track in Line Rider all at once, with flips, jumps, and wheelies all planned, and then testing the track only after you've completed the last detail. What would inevitabily happen is the rider would crash after the first few "tricks" that it would have to do, leaving you with the task of fixing all those problems in the track before it will run.

So, the way most people create Line Rider tracks are in sections. They test out the section, correcting any faults right away, and once it works, they move on to the next section. This is exactly how someone should write software.

Too many people, especially programming newbies, start off with a project. Even if it's not beyond their capability, they often end up failing because they write the whole program, and only after they've finished writing the source code do they try to test it. They soon become overwhelmed with the errors, and giving up on the project completely saying, "It's too complex for me".

But here is what complexity really is: just a group of simpler problems. So the key to solving a complex problem is to break it down and solve each smaller problem individually, and you will end up solving the bigger problem. And this apply to all problems in life, not just programming.

This is an excellent article for both new programmers as well as seasoned veterans. I program for a living but I also do it for my own pleasure. It can be enjoyable and should always be to one degree or another; I find it hard to visualize doing such tedious work as software design\programming if I was not empassioned and rather obessive about it.

It can be akin to a game: lighthearted, thrilling, rewarding. But, without a sound strategy it is easy to suffer defeat. Always plan your programs at least in your head if not on paper; even while I am building the actual program on the compiler I have a large sketchbook beside my mouse where I take notes, work out mathematics, draw diagrams-- whatever is needed to suceed in my task(s).

Thanks for the great article.

sharky_machine