This blog is for all those who have set deadlines for their learning goals and then been discouraged when it took a great deal more time than anticipated.

When we are inspired to set goals, what inspires us are the outcomes not the process. We are never eager to do 50 crunches at the gym — we are eager to walk around with flat abs.

Our wonderful human imagination makes us fall in love with the destination and overlook the path.

This is a good thing. Without this, none of us would start. But the flip side is that because of this most of us quit, or lose momentum. When the reality of the path to our dream is experienced, day in and day out, it’s very easy to slow down and eventually stop. Maybe we don’t want the dream after all. Or, more specifically, we want the result, not the work.

Right?

Sadly, this natural human habit is what stands in the way of many us learning new skills, especially complex skills like coding. Setting outcome goals is what drives people to action, but without process goals, the outcome is seriously at risk.

This is how I set my coding goals the first time I tried to learn to code: I am going to learn HTML this month. Then next month I’m going to do JavaScript.

Sound familiar? Exciting outcome, no process.

That is actually a risky, ineffective way to set your coding goals. Here’s why.

In your head that target date seems reasonable, achievable, and importantly, encouraging. It’s motivating to think you will have results that soon. The problem is that a deadline-based goal like that is arbitrary. Learning a new skill takes a certain amount of time. Some are faster than others, but everyone has to put a minimum amount of time that they need to acquire that skill. The skill doesn’t care which month you want to finish by. It only demands that you put in enough time to learn it.

Therefore, setting a deadline-based outcome goal is incomplete — it ignores some vital math about learning.

For example, if you want to learn HTML and CSS in 30 days (outcome), it is absolutely achievable. But, what does that actually mean? How many hours, on average, does a person need to learn HTML and CSS? And then, how many hours a day or week (process) do you need to achieve that goal? If it takes 8 hours a day, 5 days a week, are you in a position to do that? Which metric really decides success: the outcome or the process? (hint: it’s not outcome).

Simply put: knowing how much time it takes to achieve a goal and how much time you can commit to regularly will decide when you you can expect to achieve that goal by.

It’s like a time and distance navigation problem — if you need to travel 100 kilometres, you cannot know when you will get to your destination unless you know how fast you’re traveling. No matter how sincere you are, you cannot do 100 kilometres in 1 hour if you’re walking. Setting that sort of goal is absurd and will result in frustration if you fooled yourself into thinking it’s possible.

So when you set your coding goals, work out the distance between where you are and the skill level you want, how much time will it take in total, and most importantly how much time you can guarantee you will devote to it every week. Divide total time by weekly time and you get the number of weeks it’s going to take you. That is your deadline.

Most learning resources online make this easy. freeCodeCamp.org makes it super easy — the curriculum tells you clearly how much time a certification takes! Sites like Udacity and Coursera also tell you this, but it’s buried under other course data. Typically they tell you you can complete a course in X weeks if you spend a minimum of Y hours a week.

Even on Udemy this can be calculated. For example, my course is about 3 hours long. You can finish it in a day, if you spend 4 hours (including thinking and assignments). If you spend an hour a day you cannot finish it in less than 3 days. For more technical courses, where you learn by coding along, I would multiply the hours of video by at least 3 to get an estimate of time required to complete the course.

Put this way, it’s pretty clear that deadline-based outcome goals for learning are arbitrary if you don’t focus on the process goals of daily or weekly commitment. “When by” is useless without knowing “how much every day”.

And this one shift in approach will greatly improve your odds of success. This way you will know if something is going to take you 6 or 12 or 18 months. No nasty surprises — and you can build a solid plan around that, and prepare yourself for the journey.

Ultimately, every place is walking distance if you have the time. It’s no different for learning new skills. It takes the time it takes. You just got to be ready to show up and do the work until the math gets you to your destination.


[Update] Quincy at freeCodeCamp has relaunched the freeCodeCamp podcast, and uses his incredible experience as an educator to pull together content that will help you on your journey. I was recently on episode 53 and some of the things in this post are covered in greater detail there. You can also access the podcast on iTunes, Stitcher, and Spotify or directly from this page.


If you would like to talk about your journey, I would love to listen. Tweet me @ZubinPratap. If you think what you just read could be useful to someone, please share it.


If you would like a discount coupon for my Udemy Course get in touch at this link. I cover this and many other techniques to help you not quit coding.