How Learning to Program Is Like Being Alone on Mars
Learning to program is like being on Mars when an antenna decides to strike you down leading to your crew mates thinking you’re dead, and therefore returning to Earth without you.
In other words, it fucking sucks.
“Wait, what?! That’s insane!” I hear you say. Well, maybe, but we can learn a lot from studying how to deal with being alone on Mars, and we will discover that the methods for effectively dealing with isolation on Mars applies to programming as well.
“But” you say, “we haven’t sent people to Mars yet let alone left someone there without help”. That is true which is why we turn to the next best: Science-fiction.
Have you read the book “The Martian” by Andy Weir? If not, you should read it now, and return to the article later because there will be spoilers. (It’s a good book; it’s worth your time)
Should you have forgotten it, or just don’t want to read it, the book is about a guy called Mark Watney who is left alone on Mars after being struck by an antenna in a storm during an emergency evacuation. The rest of the team, thinking Mark died, leaves Mars, and sets towards Earth.
For the purpose of this article, we will ignore the small detail that even though winds on Mars can reach speeds up to 94 km/h, they can barely lift dust off the ground due to the low pressure of Mars’ atmosphere much less tip entire rockets and ripping off antennas. That is according to Wikipedia.
Mark, however, wakes up despite his wounds, finding his crew members having left him with a damaged shelter, and no way of contacting NASA back on earth.
I imagine most of us would give up, and simply accept the fact that we are going to die here and there’s nothing we can do about it, but not Mark Watney; he applied the “Mark Watney method”.
Mark Watney method: Don’t die.
Instead of worrying about how to return to earth, he proceeded to tackle the more immediate problems such as rebuilding the shelter, regaining radio contact with earth, and rationing food so it will last longer. He does this, not by forgetting about his main goal, but by letting it stay in the background while he works on smaller, and more manageable tasks, that accumulate towards the main goal.
Linus Torvalds once put it like this when explaining why he is not a visionary:
I’m an engineer. I’m looking at the ground, and I want to fix the pothole that’s right in front of me before I fall in. Source.
How does this relate to learning programming? Often, when learning to program, people think they want to create, say, a simple Tetris app. Building a Tetris app when just learning to program is the equivalent of getting back to earth after waking up alone on Mars. It’s a great goal to have, but it shouldn’t be your immediate goal; you should break it down into more manageable chunks, and sub goals.
Collect rock then return to home
The goal seems so far away that you will often negate any progress you make as it seems so small compared to your final goal which you have convinced yourself is “an easy goal”, and should be within reach. So you may start by jumping right into Unity, and begin to make your game before you have learned the basic syntax of C#. You will likely soon be overwhelmed by the relative complexity of the project on which you have embarked, and quickly abandon it thinking programming is too hard.
What you’re essentially doing is, right when you wake up on Mars, you ignore your wounds, the damage to the shelter, and the radio contact with NASA, but start scrapping what remains for parts to build an improvised rocket. (It almost sounds silly when put like this)
If instead you were to use the “Mark Watney method” by breaking the problem down into smaller tasks that are easier to accomplish you dramatically increase your chances of completing the project.
Not that long ago, I was in a similar situation when creating this website. I had no idea about how to create a website, and how to deploy it; in fact, a few years prior I’d given up on making one as there seemed to be an infinite amount of seemingly insurmountable problems that needed to be tackled.
However, this time I didn’t worry about not knowing how to deploy a website, or not knowing anything about how to secure user input; instead, I rested assure that I could figure it out when the time came, and focused instead on more immediate problems such as how to display a single static webpage.
I was only concerned about fixing the pothole right in front of me before I fell in. I later learned the rest such as how to make the static webpage dynamic, and how to connect to a database. Eventually, and way slower than experienced developers, I ended up with a finished product that I could launch.
By tackling just one of the nearly infinite problems at a time, Mark Watney was able to safely return to earth at the end.