Rajesh Kumar

Things to say, things to think

Agile Life Projects

31 Dec 2012

What do you do during your spare time? If you're anything like I was 10 years ago, your answer probably is "I don't really know. Watch TV, I guess?"

Don't get me wrong, there's nothing actually wrong with watching TV. It might just not be the best use of your already dwindling spare time. With TV, it's not clear what you're getting better at. And it's certainly not a clear path to personal improvement. Now if you're like the rest of the world and don't care about personal improvement, or getting better at something everyday, or you don't believe in the idea of sharpening your axe everyday, that's fine. But the very fact that you're even reading this post makes me think that you aren't like the rest of the world. Or at least you're trying not to be.

Even if it's obvious to them that it's doing them no good, the majority of the working population still kick back after a long, tiring day at work and spend 3-4 hours a day watching TV. The problem with TV is that if left uncapped, can take over your life. I've had my fair share of channel surfing addictions too, so I know what it feels like. There's a reason the TV is often referred to as the "idiot box". Want to take back control over your life like you remember from your college days? Chuck your TV out the window. Do it today. Do it right now. This essay can wait.

So if TV is out of the question, what should you be doing during your spare time?

The naïve approach is to just "go with the flow" and do what you feel like doing in the moment. And that's how I was for the longest time when I stopped having access to a TV. I didn't really think about what I wanted to do. I just went and did it if I felt like it. And if it got boring after 5 minutes, I'd find something else to do. Pretty simple, eh?

Now, don't get me wrong. This naïve approach isn't always a bad one. Sometimes, it might even be the right thing to do. There's benefits to adopting this model of life for a couple of weeks, months or a year. But make sure the time period isn't unbounded. There's even arguments supporting this model for the first twenty years of our lives. But if you keep doing this for a long enough time, you end up becoming what we call in my line of work a "jack of many trades". Mediocre at several things, good at nothing.


A "jack of many trades" is perhaps the worst thing you could become. Well, maybe not the worst — being good at nothing is probably worse. But at least there's nothing pretentious about being good at nothing. People would get it and move on with you. However, if you're a jack of many trades, you're not great at anything either. So you won't be seen or see yourself as a "specialist", an "expert", or someone who's "knowledgeable" at anything. And that's just a horrible place to be. You might as well not be good at anything.

Every person who has made a good name for themselves so far in this world is incredibly good at what he/she does. Mediocre people don't get recognized for anything even if they're actually better than a lot of people in their domain. Unfortunately for the mediocrities, there's just a lot of other people much better than them by definition.

Being good at only a very few things and a total zero at everything else isn't very ideal either in this world. Unless you're really, really, really good at what you're good at. Maybe the best in the world even. But since most of us don't fall into that category (I don't, yet), we can't afford that luxury of not even knowing how to tie our shoe laces because we're so busy being the best in the world at something else.

Instead, what I find works best is a hybrid solution. What works best is not just being a jack of several trades, but additionally great at a few specific niches that you can clearly state in words. Specific niches such as singing, dancing, drawing, painting, rock climbing, sculpting, video recording, video processing, martial arts, etc.

What I'm proposing is to engage in life projects. Pick 3-4 narrow slices of your life you'd like to work on, and then work on them everyday. It's important to work on your life projects rather frequently because you want to dig deep into your narrow slice and go all-in. The advantages of going all-in are tremendous. You want to pound on that niche so hard that within just a few weeks, you're already significantly better than 80% of the people around you when it comes to that one specific domain.

"Life" projects don't mean you're stuck with these projects your entire life. You decide at the start how long you're going to keep this "contract" with yourself for. And then at the end, you decide if you want to renew this contract. If you don't think a specific project is working out for you, switch to something else more productive. But you want your project lengths to be at least 2 weeks long to make them worthwhile. During this period, you're not allowed to jump ship unless something drastic happens. Power through your projects and try to learn as much as is humanly possible about your niche. If your project happens to be a skill, craft your skill and hone your trade like there's no tomorrow.

Every waking moment of your spare time should be spent on one of these projects that you've chosen for yourself. And nothing else. There's a rather good reason you only pick 3-4 projects at a time. If you have too many projects going on at once, you lose focus and can't go all-in. And we all know the power of remaining focused on just a few things. Every company that has tried to do too many things at once has failed. Choose the 3 projects that will provide the highest value to your life, and cut the rest. Cutting the bottom 7 from your list is the most important step in this strategy. During the next few weeks, you'll be tempted to work on "fun" things that you enjoy that aren't part of these 3 projects. But you must firmly say no. Those activities can wait until the next project cycle.


Sometime during the chilly Vancouver Fall in November 2003, during a moment of quite introspection in my bedroom, I had my first epiphany ever. It was so profound, I didn't even know what I had was called an epiphany — I only realized that a week later. During my rather brief moment of insightfulness, I decided upon a new way of running my life. A new way that would categorize everything I did during my spare time into 1-5 "projects". Today, 10 years later, during a chilly 2012 winter in Toronto, I couldn't be more pleased with the results.

Here's a selection of "projects" I've worked on for the last decade or so, in chronological order:

  1. Nov 2002 — Become a PHP "expert". Master the PHP programming language to the point where I'm more comfortable in it than I am in English. Interestingly, I just "renewed" this project contract again last Friday (on Dec 21 2012) for like the 30th time! I find this project very rewarding and satisfying, and my LinkedIn profile is testament to the results. 10 legit endorsements on PHP, nice!

  2. Nov 2003 — Work towards getting a 42/45 on my IB final scorecard. I only ended up getting a 40, but hey, it was still worth pursuing this project for a year and a half. This project concluded in May 2005.

  3. Feb 2004 — Project Typist! Work towards a typing speed of 100+ wpm. This was right after I realized what it meant to be pareto productive. I managed to hit a whopping 115 wpm surprisingly with just a month of intensive practice.

  4. May 2005 — Project Juggler. Learn to juggle 3 balls effortlessly. Resolved in just under a week.

  5. Jun 2005 — Get better at writing! That's when I started this blog. I figured the best way to get better at writing was to just start writing more. Going through my archives, it's apparent my writing quality—both in content as well as in style—has gone up by at least an order of magnitude. This project too has been on-going for more than 7 years. I renewed this project as well last Friday (Dec 21, '12) so I could let myself write this post and the last one. What renewing means is that whenever I choose to spend my spare time writing a well thought-out essay, I always allow myself to continue unless I have a more pressing deadline. So even if these essays take a while to write and re-write, I find it's worth my time. There's just no other way to get better at writing than to keep writing.

  6. May 2006 — Project DSLR! Learn to shoot decently well with an entry-level DSLR camera. This project carried on for 4 years but was put on unexpected hold for 1.5 years from May 2010 to Nov 2011.

  7. Jan 2009 — Project Get Fit! We all know how that worked out for me. Embarrassed at my level of fitness while living in one of the fittest cities in the world, I went all-in into this project, giving it my 100%. The results were staggering. After just 10 months of intense self-designed Fartlek training, I had become fitter than most people I knew back then.

  8. Jun 2009 — Project Flosser: form a habit of flossing at least 5 times a week, but at most once a day. I had been procrastinating this one for over 2 years! It was also my first experiment in the domain of habit formation. I'd never consciously done that before. I'm proud to report I still continue flossing at least 5 times a week even today, after 3.5 years. I know it's a habit nowadays because I actually feel weird and grossed out when I've gone 2 consecutive days without flossing. The same way I feel if I start my day off without brushing my teeth or taking a shower.

  9. Oct 2010 — Project Biker: get better at cycling, especially on the city streets with heavy traffic — without a helmet! Very ambitious.

  10. Dec 2010 — Project Zipcar! Goal: legally drive a zipcar in San Francisco. Read all about it here.

  11. Feb 2011 — Project Half Marathon! Run my first ever half marathon. This was going to be tricky due to my very wobbly knees, but doable.

  12. Jun 2011 — Project Driver! Get better at driving a car. Like really better. Not just know the rules. But be able to drive well sub-consciously.

  13. Nov 2011 — Project DSLR Round 2! Get at least 5x better at shooting with a DSLR than I already was.

  14. Dec 2011 — Project Toronto: Figure out a way to re-locate myself back to Toronto in 2012 with the least amount of effort.

  15. Dec 2012 — Project DSLR Renewed (for an additional year): Get at least 10x better at shooting quality shots with a DSLR than I already am.

This is just a selection. Several of these similar "projects" were initiated by me over the years for all the things I love doing everyday: hiking (Half Dome!), scaling mountains (Machu Picchu!), running/fitness (marathons), ping pong, travel (sight-seeing), and improving my language skills in PHP, Ruby, English, Tamil, Spanish and French.

Each project cycle has a clear goal (either subjective or objective), an action plan, a routine that I can follow regularly, and a contingency plan on what to do if things go awry. For Q1 of 2013, these will be my on-going "projects":

Everything I do during my spare time must fit into one of these project buckets. If they don't, I stop doing what I'm doing instantly. Before starting a task that's going to suck in more than an hour, I stop and ask myself: what project bucket does this task fit inside? If I can't answer that question in under 5 seconds, I find something else to do. There's only so much free time in a day, and it's very important to consciously choose how we spend it. Notice how TV, socializing, and "hanging out" aren't on this list. I will therefore be limiting myself to only a very small amount of time on them: perhaps a few hours per week in total.

It is this very highly-engineered process that has caused me to say no to a lot of tasks I might actually enjoy. I only want to engage in projects that interest me the most, or have the highest ROI for me. Life is too short to get good at everything. So I've been carefully nurturing what I want that list to be. After a few decades of constant iteration on these "life projects", maybe I'll be good at many things as a side-effect.

In fact, saying no to activities is the hardest part of the strategy. Your friends will almost definitely ridicule you for this. They'll think you're merely fishing for excuses to say no to doing stuff with them (mine did), but you know better. Always be willing to try stuff out for an hour or two. You want to keep an open mind when it comes to new things. But if you're going to invest a decent amount of time and effort into something, think twice before starting out. You could end up spending 10 hours on something and just become mediocre at it. Or you might end up becoming great at something that just doesn't add that much value to your overall life. Like the way I got really good at some computer games back in the day.

What heuristics do I use to say no to a prospective project?

Because of the above project rules, I've had to call it a day on several projects of my life thus far. I've had to cut learning Go for example. I've cut learning to ski and snowboard. I've said no to cooking until now. I've called it quits on indoor rock climbing despite numerous requests by my roommate since I wasn't getting as much ROI out of it per unit time. And the list goes on.. I've probably cut more things than I've included. But that's a good sign that you're being choosy in your project selections which you should be.


The concept of running your life as a set of projects isn't terribly new. 5 years after I came up with the idea on my own in 2002, I learned that the software guys had already come up with a name for this style of project management way back in 2001. They termed it agile software development. Each project cycle is called a sprint, and during a sprint, you stay focused and power through your tasks without distraction. At the end of each sprint, you have a sprint retrospective (how did your last sprint go?), and a sprint planning session (what should we do this sprint?). Agile sprints are typically 2 weeks, but your life sprints can be as long as you deem fit for the type of project you're working on. 3 months seems to work well for me when it comes to existing projects, but for new projects, I limit them to just one month so I can review my progress regularly. I can always renew a project if it's working out to my liking.

Due to the very agile nature of my projects stemming from the requirement to frequently review the list of projects being worked on at any given time, I call these projects agile life projects.

Now go build your list for January 2013 before the year turns over.

Permalink Permalink

Natural vs Programming Languages

22 Dec 2012

The number of similarities between natural (human) and programming languages can be pretty startling. Just the other day, I was discussing the parallels between the two forms of languages and I was amazed myself at how many commonalities I could find with such considerable ease.

The truth however is that this fact regarding the number of parallels shouldn't really have come across as a surprise. The two forms are still languages at a very fundamental level, not just by name. They were both essentially created to achieve one goal: to communicate. In particular, to communicate ideas and expressions. And in some cases, instructions.

Programming languages have a lot more similarities among them than what meet the eye initially. This means that if you know one programming language well, it's a hell of a lot easier to learn other programming languages, at least within the same family. The first two languages are the hardest to learn. The 3rd and higher are substantially easier, and it obviously gets easier as n grows.

This is not unlike the natural languages. If you know English, it makes it a lot easier to learn other Latin-based languages such as French and Spanish. Unfortunately, knowing English doesn't necessarily make it easier to learn languages outside the Latin family — languages like Hindi, Arabic or Japanese that are so profoundly different from English and French in a number of perturbing ways.

My life's experience with programming languages are a clear example of this concept. My first two programming languages were BASIC and PHP. After these first two, it was pretty straight-forward to pick up other similar languages in the family such as C, C++, C#, MATLAB, Javascript, Ruby, and Python. I merely had to learn what was different. However, learning new languages outside this core group got tricky. Languages like LISP/Scheme, AMPL, SQL, Regex, and Dart. To me, they felt like what learning Japanese today would be after 2.5 decades of English.

Fortunately, the more languages you know, the easier it becomes to pick up another one. If you know how to code in one language really well, you should be able to pick up multiple languages fairly easily, assuming you're willing to put in the effort required to practice each one. Furthermore, the more diversity you have in the list of languages you know, the easier it gets.

This is why when good software companies see that you don't know the language they're coding their app in (Scala for example), they simply resort to looking at how many other languages you know. They're hoping to see in your resumé that you have exposure to so many other languages with enough diversity between them that it'll be trivial for you to pick up a new one.

The biggest language debate of the 21st century among coders is if knowing several programming languages makes it easier to learn a new natural language, and vice versa. Anecdotal and empirical evidence certainly suggest it: good coders seem to have a fair command of the English language, but not necessarily the other way around. A consensus surrounding this hasn't been reached yet, but we certainly know that it doesn't hurt to know more languages. After all, the latitude of your ideas is arguably only as expansive as the cross-product of all the languages you know.

Languages are not be confused with algorithms. Being good at Java doesn't mean you know how to sort a list of numbers without calling some built-in function. Algorithms are largely language invariant just like ideas in natural languages are. Language is just a way to express an algorithm, a set of instructions if you will, to a computer much in the same way that we use language to express an idea or an instruction to another person.

However, unlike human languages, we tend not to express emotions and feelings via poetry in programming languages simply because computers don't know how to respond to them. If it isn't an instruction to do something, the computer pretty much ignores it.


What does it mean to say you know a language well? Does it just mean you've done it a lot and are fast with it? Maybe. But not entirely. Certainly working with a language a lot will make you faster in it. But the real reason is that the extended practice has made you extremely familiar with the basic expressions in the language. Control structures, for example, are perhaps the most basic concepts in any programming language — control structures like if, then, else, while, do/while, for, foreach, goto, blocks, yields, etc. Knowing a language well means you know how to express the idea of a control structure—the idea of controlling flow in your program—well.

The syntax might just be slightly different between different languages, but the base expressions are pretty much the same across all languages. Just like in all human languages, the base parts of speech are all the same — noun (additionally comprising of gender and number), verb, adjective, adverb, etc. From the outset however, they might look different in different languages.

The invention of new languages is of great interest to me. Why would someone want to invent a language? Natural languages, by their very definition, arise naturally. They arise out of a need to communicate with other humans. There isn't a set of people who sit together and write down the rules of a language like they might do for a Constitution. Well, they tried that once and it ended up being a massive failure. It was called Esperanto.

Computer languages, on the other hand, are invented to communicate with a computer. Therefore, the power of a language is determined by the complexity and sophistication of instructions you can give a computer. Therefore, a language with advanced concepts like recursion, closures, and anonymous functions for example may be considered more powerful than another language without them. Just like a language with pronouns and interjections is more beneficial than one without.

The power of a language is also largely determined by how effective you are at communicating instructions. Today, succinct languages are generally preferred over more verbose languages by virtue of enhancing developer productivity. A language too succinct however may have trouble being adopted since they're harder to maintain in the future. Maintenance is important since almost 90%+ of coding done today is adding features to an existing program, not writing new ones. And what good is a language that isn't adopted by anyone?

It's quite a feat to balance these two tough concepts: expressiveness and succinctness. Language designers are always walking a tightrope when it comes to making important design decisions regarding the complexity of their language's feature set, while at the same time keeping it succinct and definitively unambiguous.


Curious where programming languages come from? There's quite a few sources. They might come from a CS course project in school on compilers which in turn grows into something larger. This is not unlike how Linux used to be Torvald's class project which he then proceeded to open-source.

Some programmers, especially the crazy (good) ones, design languages as a hobby. Partly because designing good languages is so challenging and partly because it can be very rewarding in the end. These hobbyist languages are often the best since their designers aren't on any time pressure. The designers can take as much time as they want to make the right decisions for their language. Unlike the hobbyists, some people are just paid to design languages by big companies like Google (Dart), Microsoft (C#), and Sun (Java).

When it comes to the differences between natural and programming languages, programming languages also happen to be a lot stricter and less forgiving than natural languages. This is because human languages have significant in-built redundancy that allow us to resolve ambiguity using context. Programming languages have virtually no redundancy because that's extra work for the people who write compilers for languages. English is particularly notorious for built-in redundancy. You can easily drop 30% of words (filler words like prepositions, conjunctions and articles), drop all vowels, shuffle around all but the first and last letters of a word, and still manage to make sense of what is being said.

The fact that programming languages are stricter should come as no surprise. Computers are very precise in the instructions they like to receive. Furthermore, computers aren't really trained to clarify the meaning of an expression the way a human would do when in ambiguity. So in a lot of ways, a programming language is gauged by how easy it is for humans to make accidental mistakes (known as "bugs") communicating in it.

Owing to these concerns, programming languages are actually designed and engineered from scratch by either one or a small group of highly talented individuals. The cost of screwing up is high since the stakes are higher. Especially when you know your language could be used to write software that powers a traffic light, a robotic arm on the ISS, a NASA rocket, a nuclear warhead, an MRI machine, or perhaps your next Facebook game. You wouldn't want all your cows in Farmville to randomly disappear now, would you?

Permalink Permalink

« View Older Posts


What's happened in the past year reverse chronologically?

  1. 1 year at Instacart: Completed my 1-yr mark at Instacart, Mar 16 2016.
  2. Tried Soylent: Tried Soylent for the first time (for an entire week), Jan 11 2016.
  3. Visited New Zealand: Spent 2.5 weeks touring both islands of New Zealand by car, Dec 2015.
  4. First century ride: Completed my first century 100mi bike ride in Santa Rosa, May 2 2015.
  5. Joined Instacart: Joined Instacart as a senior software engineer in SF, Mar 16 2015.
  6. 3rd Half Marathon: Completed my third half marathon in SF, Jul 27 2014.
  7. Moved back to SF: Moved back to San Francisco from Toronto, Nov 10 2013.
  8. Got Married!: Got married to Sowmya, Aug 25 2013.
  9. Quit Zynga: Left Zynga to join a small mobile-couponing startup in Toronto called Checkout51. Jun 12 2013.
  10. First Full Marathon! Completed my first full marathon in Toronto, May 5 2013.
  11. Got Engaged! Got engaged to Sowmya, a long-time friend from university. At Chennai, India. Oct 28 2012.
  12. Peru! Travelled in Peru and hiked night and day for 40 km to get to Machu Picchu! Jul 3 2012.
  13. Moved to Toronto! Moved permanently to Toronto, ON. Still at Zynga. Feb 19 2011.
  14. Half Marathon Round 2! Successfully negotiated my 2nd half marathon across the famous Golden Gate bridge and back. Nov 6 2011.
  15. Kenya! Visited Kenya and went on a week-long Safari around the country! Oct 14-24 2011.
  16. Skydiving Round 3! Went tandem skydiving again for the 3nd time. This time also in California. Sep 11 2011.

[ home | about | contact | publications | resume | archives | sitemap ]

Last modified: Wed Apr 20 00:10:28 PDT 2016
© Rajesh Kumar <rajesh@meetrajesh.com>