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.
