For a few months now, when it came to adding a new skill to my technical tool belt I was under the school of thought that the best way to do so was with a project.
Well maybe I shouldn't say best, but at least I was highly biased towards that line of reasoning. I went down a whirlwind of learning via the deliberate practice strategy but without a clear goal. Eventually I reached a point where I didn't feel any sense of progress. With any habit, you want to make some noticeable move to the needle. After all, with no project how would I even work through the pile of information there is to learn and find what interests me? Why pick up a new technical skill for the unknown sake of it when I could build something that excited me and learn as a natural side effect?
The Problem
My bias ended when that thought process didn't work so well in a project. A few months ago I had an idea for an app that would solve a recurring problem of mine. I had a long term vision, but to prevent my vision getting in the way of an MVP I decided on some key features that absolutely needed to be there to get the point across. I came up with 3 main screens, each of which had 1 or 2 core functionalities. As someone with a background in web development (like that made a difference), this seemed attainable in at least under a month. Right?
Well, turns out it was attainable in about 2 weeks. But like all projects, unpredictable obstacles arose. All of which I was able to debug my way through just fine. Except for one. One that opened my eyes to further nightmares of mobile development.
Thanks to fellow techie friends I started off with the knowledge that learning mobile development might start off feeling like working with an angry dragon. I acknowledged this and continued working. Once I reached 3 screens, I felt like I had conquered the dragon. It wasn't until I needed to implement the next feature that I realized I had just been playing with the tail of the dragon and in fact the dragon was yet to be woken. Being in the weeds of the errors gave me the confidence to recognize the size of the dragon.
This led me to question my aforementioned approach in learning something new. If I had just dabbled in mobile development for the sake of it, could I have foreseen this bug occurring? When picking up a new skill in the field of software, is it better to approach it with some conclusive means? Or does one learn better when there is no conclusion in sight, and rather for the pure joy of being immersed in the knowledge?
This naturally led me to brainstorm some pros and cons for each:
Learning with an end goal in mind
Pros:
- End with something to show for your work
- Motivation might be higher? With the understandable clarity
- Some structure to your learning, you know what trees to traverse in the forest of knowledge for that field
Cons:
- You can get caught up in the product, not the learning (build something small article about side projects)
- If you don't reach the goal, it's easy to adapt the negative mentality that failure of the product is failure in the field
Learning just for the sake of learning
Pros:
- No pressure, no expectations
- Helps you connect what your learning to other things you've learning because by nature learning is the art of connection
Cons:
- Can easily forget what you've learned if you don't revisit it for some time
- Might be confusing where to start
- Can fall into the habit of passive consumption without active implementation - the phase where you actually learn
Discuss
I recently came across Paul Graham's What You'll Wish You'd Known. In it, he had a fantastic quote about recognizing the scope of where your learning can take you:
Writing novels is hard. Reading novels isn't. Hard means worry: if you're not worrying that something you're making will come out badly, or that you won't be able to understand something you're studying, then it isn't hard enough. There has to be suspense.
I suppose then, the answer is not that you should enroll in either of the schools of thought, but rather that learning in general should strain you in the best way possible. If that's not happening, whether you're building something or taking an online class, it's unlikely you're learning.
When you want to dive into a new field of tech, are you more likely to follow one of these schools of thought? Maybe you approach each scenario as a standalone battle, that requires a mixture of both schools? That seems to be where I'm leaning at the moment.
Top comments (0)