The Code Life Analogy
I spend a large part of my awake time looking at code, and that affects the way I think about things in general as well. Around 4 months back, during a late night philosophical discussion with a friend of mine, I found myself explaining something using code analogies. And I was pretty impressed by that analogy :P. So I recently thought a little more on it, and I realized that code is a really good analog to life in general. Confused? Let me walk you through it.
Think of every human and his/her life as a software. Being born is like the first few lines of code, something like the “Hello World” code, where you basically have just a single feature i.e. you can breathe, but that’s about it. During the initial years of life, most of the code is contributed by your parents. They design and implement a ton very important features such as how to talk. For the rest of your lives, you take these features for granted, something like how you take the TCP/IP protocol stack for granted while building any networked application. Slowly, over the years, you start taking control of yourselves and start building your own code. Still, for a large part, typically until the time you move out of your homes for further studies, bulk of the code still consists of what your parents wrote. Moving out for studies is like a beta version release — the code is functional and has most of the basic features and is fairly well tested, but it is in no way complete. From this point onward, you start writing and committing a lot of code for yourself. You also look at other software systems, like your friends and modify your code according to them — under peer pressure. An interesting point here is that no one’s code is ever fully open sourced. You might get to see modules of the code and glance on a part of someone’s life, but it is highly unlikely that you would ever get to understand anyone in their completeness — possibly not even yourself. Sounds like we need github for life :D.
Getting out of your comfort zone is like stress testing your code. You know it will be painful — the code will definitely break at the most unexpected places — but it is the only way to improve your code and to make it more robust. Travelling is like testing your code in different environments, which leads to adding ifdef statements to alter your behavior based on where you are. Meeting people is like checking out other software. Learning from your mentors is like trying to reverse engineer them and trying to add their features in yourself. Getting advice is like receiving bug reports or feature requests. Being appreciated is like getting a positive review. Hobbies are like auxiliary features you develop just for the fun of it. Studying, or advancing towards whatever career choice you have made, is equivalent to iterating over your code multiple times to improve it’s design and focusing on a select set of features and trying to make yourself the best software with those features. It takes time and is a long drawn process — but definitely worth it. But let’s not dwell upon this boring process and rather talk about the more interesting development phase — finding your significant other ;).
Finding your significant other is, arguably, the toughest thing in life. And why not — after all, finding a significant other is like finding a software that you really appreciate — which is tough to begin with, because, well, a lot of softwares out there are just not compatible :P. But it doesn’t end there. Once you find someone you really like, you need to collaborate with them on yourself as well as on them. Just imagine, a huge code-base, built over years, and then a new developer comes in and starts adding code. And you can’t just ignore their code, you have to merge it with your master branch — make it a part of your life. No wonder there are so many merge conflicts :P. And then, you also need to contribute to the (significant) other code-base — just understanding which takes so much time and effort.
Having realized this code-life analogy, I think I have found a way to — at least in theory — solve any problem in life. Handling life problems should be just like debugging code. And what do you do to debug code — well, you printf :D — you printf indiscriminately and all over your code, and then iterate over it to find the exact line of code which is causing the problems. So to solve a life problem, you need to communicate, and communicate even the smallest things because you never know where the problem is, and then iterate until you pin down the exact problem. The non-analogous part is that who to communicate with changes depending on the problem, unlike the stdout which is always there to listen to all that printf has to say :P. And if everything else fails, you can always resort to “I don’t debug, I just stare at the code long and hard until it confesses”, which is just the coding equivalent of “give it time”, or maybe just accept and live with the problem and declare the bug as a feature in the next version release ;).