On the Road to Learning - Part I

Raju Gandhi
  • November 2014
  • Learning

We, as developers, live and thrive in an industry which not only sees its languages, tools, and techniques change every few years, but one that also regularly experiences tectonic shifts in the very paradigms upon which these tools are built! From desktop to web to mobile, from object-oriented to functional programming, we are not only expected to keep abreast of these changes, but also be proficient in them. How can we keep up? How can we best leverage our time to learn and retain knowledge effectively? In this article, we will consider a few strategies to help align ourselves with being a better student, and we'll also take a look at some tools and techniques that can make our learning more meaningful, insightful, and long-lasting.


I was a good student throughout my academic life; after graduating and entering the workforce, I struggled. I found that I missed the structure and the single-minded focus that the education system architected around us. I found my ability to master new methodologies and techniques took longer, and that I had less retention. I had to keep revisiting what I had learned, which needless to say was wasted effort, as well as incredibly frustrating. So I started studying how those whom we deem experts, such as chess grandmasters and professional tennis players, manage to not only maintain, but also continue to hone their skills. How did these individuals, despite year round tournaments and public appearances, continue to achieve excellence in their chosen fields?

After pouring over several books, including those written by psychologists, talent consultants, tennis coaches, educators, and even the experts themselves, I found several common threads among their practices. These commonalities existed regardless of the skill type, be it mental, physical, or kinesthetic. As a result, I started applying these techniques to my own learning and have found the structure that I missed from my early school days. My understanding and recollection of the material also dramatically improved.

In this article series, I will aim to highlight some of these techniques. I will explain why they are important, and how you can go about applying them to further enhance your own learning experience.

Although I posit that these techniques are applicable to just about any skill or expertise that an individual might want to develop, my examples will be specific to subjects close to our hearts -- perhaps learning a new programming language or a new framework.

Ready? Well, buckle up! I assure you this is one road trip that you do not want to miss.

Getting the lay of the land

You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down and the level of everything you do will rise.

- Michael Jordan

Learning any skill takes significant practice. In my research, almost every resource I came across mentioned the notion of 'deliberate practice'. But how does one go about practicing programming? Or learning a new programming language? It was not until recently that the answer dawned on me (thanks to Daniel Coyle's The Little Book of Talent: 52 Tips for Improving Your Skills). Every area of expertise, be it a physical or a mental endeavor, can be broken up into two major categories: hard skills and soft skills. Hard skills are those where being consistent is key -- for example, how to strum a guitar, or a roundhouse kick in Muay Thai. Soft skills, on the other hand, require context; they require you to react to a particular situation -- for example, a public speaker telling a joke to liven a bored audience, or applying a pattern to solve a specific programming problem.

Now let's consider some examples close to our hearts. Can you think of a hard skill in the context of a programming language? How about its syntax? How about a hard skill relative to a source control system like Git? How about creating and switching to a branch in one go? I realize that it's hard for us to view certain traits of our profession as "hard". This is mostly because we have long approached software development as a "right-mind" or "creative" undertaking rather than a physical skill, such as juggling. In this context, we can now approach programming like you would any other skill -- building it piece by piece, incrementally.

Any skill is a result of our practicing both the hard and the soft skills, but the key to performance is hard wiring the hard skills so that they become automatic and reflexive, almost intuitive. It is only when the hard skills are drilled into us that we can free up our minds to deal with the "softer" situations. For example, good magicians realize the value in being able to palm a coin effortlessly - only then can they proceed to build more and more elaborate tricks to awe their audiences. Similarly, if you get the fundamentals right - the syntax, the idioms, the "right" way of doing things in a language or framework, then you can proceed to add more and more complexity to the problem space.

Too often we brush aside the basic fundamentals -- the hard skills -- because practicing them comes across as boring. It's way more fun to jump in with both feet and attempt something more complex. In the short term, this may seem like making progress, but in the long term, your ability to build your skills will quickly plateau. Furthermore, even as you build your skills, regularly returning to practice the basics is important. There's a reason why Tiger Woods, even after achieving remarkable success as a professional golfer, spends over four hours every day just practicing his swing!

There are two points that I glossed over. First, hard skills usually require no context -- in essence, they are "stateless" -- which makes it easy for you to practice them. Second, soft skills, which involve reacting to a situation, are a combination of several hard skills coming to play at one time. Think about driving a car -- if you suddenly had to swerve and brake because someone had just cut you off -- do you have to think about where the brake pedal is or how much you ought to have turned? Now compare that to your early days of driving. Without the necessary hard skills, do you think you could have reacted just as competently?

The next time you decide to learn a new skill-set, try to identify the hard skills involved so that you can isolate, practice, and get them right (we will talk about deliberate practice in the following sections). Only when you are proficient in these skills should you attempt to add more complexity to the problem. Remember, the secret is to keep practicing the hard skills.

Are we there yet?! Are we there yet?!

It is good to have an end to journey toward; but it is the journey that matters, in the end.

- Ernest Hemingway

Carol Dweck, a world renowned psychologist, in her ground breaking book Mindset, identifies two attitudes of intelligence - the "entity" theorist and the "incremental" theorist. The entity theorists tend to view skill, or intelligence, as a fixed entity. They link success and failure to an ingrained ability, and prioritize only the results of their work.

The incremental theorists, on the other hand, tend to view skill as something that can be incrementally improved or mastered. For incremental theorists, success and failure are merely functions of their efforts, and a negative outcome does not imply that they eventually will not be successful. Just so we are clear, that is not to say that incremental theorists only value the process. They realize that eventually they will have their feet to the fire: their code will go into production, or they may have to perform the violin in front of a live audience. But unlike entity theorists, their focus isn't necessarily only on the final conclusion, but rather the steps that lead them there.

These mindsets, or attitudes, are often the result of an individual's upbringing. Both parents and teachers may unknowingly encourage an entity mindset by praising the intelligence of children rather than applauding their efforts and persistence. The downside to being an entity theorist is that they tend to shy away from any task or challenge where failure might be an option.

The bad news is that the entity mindset is a major roadblock in your path to learning. In the process of learning, failure is not only expected, but also encouraged! The truth is, in order to be a good student, we need to focus on the act of learning, not the results. We need to be aware and appreciative of both the journey and the destination.

As a learner, it is imperative that we assess our own mindsets and discern if we are an entity theorist, or if we have have more of an incremental attitude. Learning who we are may help us better adjust ourselves to new challenges. If you do find that you align more with being an entity theorist, I come bearing good news! The truth is that you are not "stuck" with any particular mindset, but rather you can work toward being an incrementalist. In fact, the very fact that you are willing to accept that you can change is an incremental mindset!

As a student of any discipline, it is absolutely necessary for us to realize that getting lost along the way is not only inevitable, but the only way for us to extend our current skills. This requires us to be incremental in our mindset -- allowing us to relish the journey, be patient with ourselves, learn from mistakes, and in effect, be better students.

Getting Directions

If you don't know where you are going, you'll end up someplace else.

- Yogi Berra

Every journey has a beginning and an end, and in that regard, learning is no different. Unfortunately, most of us often attempt to undertake our skill building endeavors with no idea of where we stand or where we want to be. But fear not, for we can take some advice from the Dreyfus brothers and their research in skill acquisition. The Dreyfus brothers identified five stages that any student can pass through while acquiring a new skill: [1]


Novices operate in a world that is rules-driven and context-free. That is, they have no "big picture", and they don't care to have one (yet). They need quick wins and detailed instructions. A good example here would be a recipe for a cooking newbie. Getting flustered is a common reaction for novices, because no recipe can be detailed enough, and things are bound to go wrong. At this level, checklists, beginner "101" tutorials, or blog posts are ideal resources.

Advanced beginner

Advanced beginners are similar to novices, in that they still do not have an understanding of the system. But rather than checklists, they can be provided with some guidelines. Again, when things go wrong, they are invariably lost. Good resources for advanced beginners would be the first few chapters of a beginner's book or high-level documentation of a language or framework.


So far, individuals have been rules-driven, but it is this phase where they start to develop some context. They can start to see the big moving parts of the system, and given some advice, are able to plan and apply that advice to solve problems. They might still trip over exceptional cases, but they know how to go about solving them. Good resources are pet projects, or perhaps helping someone on an existing project.


At this point, individuals are relying more on context than rules. Abstractions become a key asset which allow them to consider the system holistically rather than in individual pieces. Proficient individuals also have the "rules" imbibed and can now use their intuition to guide them. Good resources for proficient individuals might be writing or contributing to a library or a framework.


The easiest way to explain an expert is by considering an example like driving. How often have you travelled from home to work and back without remembering the drive? For the expert, intuition drives what they do and how they do it. There are no rules -- the system is merely an extension of who they are. They just 'know' when something is not right (think of that time when you just 'knew' another driver was going to cut you off), and can naturally come up with solutions without any deliberation. To expand their skill set at this level takes a lot of effort and creativity. Artificial constraints (Code Golf) and writing books may be some ways to improve their skills.

When deciding to acquire a new skill, it will serve you well to objectively look at yourself, establish where you stand along the five stages of competency, and gauge where you would like to end up. In some instances we may be novices and prefer to keep it that way. A great example here is tax preparation. Then your journey starts and ends with a checklist (for example TurboTax)! Move on, nothing to see here!

On the other hand, perhaps Clojure has caught your fancy, and you may have had some experience with a Lisp dialect, say Scheme, so you mark yourself as an Advanced Beginner. You also realize that you may never get to use Clojure at work; being competent in Clojure will suffice for now. There, you have your start and end points.

With this information in hand, you can now proceed with finding resources that will help you get from where you are to where you want to be. You realize that reading a Clojure 101 tutorial on prefix notation and the power of homoiconicity is not going to buy you much, but perhaps reading The Joy Of Clojure will be more appropriate. You can now confidently tune your learning material. As an added benefit, you can move on to other areas of interest once you find yourself sufficiently competent in Clojure, knowing that you have reached your destination.

A word of advice before we conclude this section -- it is absolutely imperative that you be objective when assessing your current skill levels. It's tempting to overestimate our skills, especially if we have a lot of experience, but that is short-sighted, not to mention detrimental to your progress. Often times areas that look similar are often quite different once you get to know them (think Java vs. Ruby, or Spring MVC vs. Rails). My take on this - if in doubt, err on lower side of the skill graph. That is, if you think you might be Proficient, pick up the resources that are catered towards a Competent. At best you might actually realize that you _were_ actually only just Competent, at worst you will have reviewed a few concepts.

Mile Markers

A goal is a dream with a deadline.

- Napoleon Hill

Now that you have a destination in mind and have decided to approach learning with the right mindset, the question remains: What next? You might respond with something like, "I want to be competent in Clojure." That is admirable, but that answer begets another question: How will you know when you are done? You see, being competent or an expert is a vision, and a vision lacks tangibility. Andy Hunt, in his remarkable book Pragmatic Thinking and Learning: Refactor Your Wetware, suggests that you break up your vision into several goals, each goals acting as a stepping stone to the next, until you finally attain your vision.

He goes on to argue that goals alone are necessary, but not sufficient. You need S.M.A.R.T goals:


For example, you may decide to read _The Joy of Clojure_ as the first step to achieving Clojure nirvana (in essence, you should be able to know when you are done).


You may decide to read a section every evening or a chapter every week


You goal needs to be within your reach, that is, the goal need to be realistic. Aiming to write a production-ready application in your first week with Clojure may be aiming too high if you are an Advanced Beginner.


Your goal needs to be aligned with your destination. Tweaking your Emacs theme for Clojure bliss might be a S.M.A.R.T goal as well, but it gets you no closer to being competent in Clojure.


Too often, especially when learning on our own, we think we will find time to pursue our goals. This is a misnomer, since the everyday humdrum of our work and personal lives can easily overtake our best intentions. By timeboxing your goals, you are planting a stake in the ground that will give you the urgency that you need to make your goal a reality.

When it comes to goals, it's best to lay them out so that you can work through them within the time frame of a week, or at most 10 days. Any time frame that exceeds a week loses its specificity, and it is hard to avoid slippage.

Daniel Coyle, in his book The Little Book of Talent: 52 Tips for Improving Your Skills suggests that it is better to practice for five minutes every day, than an hour at the end of the week.

Now, I realize that in most contexts taking that advice literally is not only meaningless, but a sure waste of your efforts. Regardless, there is value in the implicit meaning of his statement. Keeping up a regular ritual towards your learning efforts not only allows you to keep the subject matter fresh in your mind, but you also get the chance to chew on it.

This can often lead to many realizations of the material and your understanding of it.

With that in mind, Andy Hunt further proposes breaking up a (S.M.A.R.T) goal into mini, bite-sized (S.M.A.R.T) objectives; potentially ones you can tackle everyday. This helps you ascertain the "achieveability" of the goal itself. It also ensures that you stay on track.

This may seem a tad excessive; how much time do we spend planning to learn vs. actually learning? Truth be told, once I establish my purpose with regard to a new skill, I need only minutes and a sheet of paper to lay out my action plan. Remember, your goals should not have an extended timeline. The usual reaction is to over think it. Please do not; just start with one goal. Then, once you surmount it, figure out the next one. As long as each goal surpasses it's predecessors in it's "achievability" quotient, you are slowly and surely progressing toward your vision.

In addition, the notion of S.M.A.R.T goals and objectives can be universally applied to pretty much any task that you would like to accomplish. I have lately been making everything from cleaning my apartment to doing my taxes (including writing this article) S.M.A.R.T. Goals help in knowing what needs to be accomplished; putting a deadline on when it needs to get done not only makes the task seem less overwhelming, but once you hit your time constraint, you can freely put it away (perhaps for the meantime), and concentrate on other things that vie for your attention.

Commonly we think we should 'make time' because we are interested in expanding our expertise. Unfortunately, you can never make time -- you have to proactively allocate it. Furthermore, just having a open slot on your calendar is not enough; an action plan needs to be in place that will take you, in small steps, from lesson to lesson, milestone to milestone.


Learning, just like any other ability, is a learned skill. Approaching our learning with the correct mindset and a 'game plan' can make our attempts at autodidacticism both efficient and rewarding.

In the first part of this article series we have aimed to establish where we are, where we want to be, and finally, establish a game plan to get there. In the following piece, we will continue our discussion, focusing on the notion of 'deliberate practice'. We will also see some tools and techniques that we can employ to aid our learning efforts.

Until then, surakṣita yātrā mērē dōsta! [2]



  • 1 There is some contention in the terms used by the Dreyfus brothers in their research vs. the popular terms in literature, but I believe that that teeters on the edge of pedantry.
  • 2 "Safe travels, my friend" in Hindi :)