With the availability of free online learning resources, it’s now ‘easier’ than ever to learn how to code. But is it really that easy? I can confidently tell you that it’s not. Self-learning is extremely difficult. That doesn’t mean I would advise against trying it.
A self-directed learning process is inherently tough because you need to pick what you’re going to learn and what you’re going to learn from. A degree course or bootcamp handles this for you and so, it’s one less thing to worry about. The sheer quantity of learning materials and resources can become a blessing as well as a curse. Because there’s no structured pathway set out for you, not only will you have to manage finding the best resources but you’ll also have to manage your progression through concepts and topics with increasing levels of difficulty and complexity.
With a degree programme, difficulty usually progresses incrementally over time, in general, you’ll find more foundational concepts and topics covered within your first year, by the second and third years the workload and intensity of learning increases, many of the topics and concepts that you’ll learn will be more complex and often build upon things you learnt at the beginning of your programme. I’m not suggesting that this is the gold standard for effective learning, but at a minimum, it does provide a structured pathway.
Ultimately, this is why self-teaching is tough because you’re not forced by anything – you’re going to have to guide yourself towards coding competency. You’re totally accountable for your own progression, and if you’re learning to code with the intention to land a job, you’ll need to ensure you acquire the skills necessary to become an employable developer.
When you first embark on your code-learning journey there's a conflicting mix of discomfort and excitement. The excitement is often perpetuated by beginner-friendly courses and tutorials that hold your hand as they gently guide you through this strange new world. You’re exposed to new concepts, topics, and syntax in a safe and controlled environment. This is a very support-intensive process that’s very easy to become dependent on. The problem with hand-holding processes is that they don't last forever (at least they don’t if you want to progress).
Tutorials and courses can’t do the work for you, that’s up to you. And so, before long the novelty and excitement that often accompanies starting something new gradually wears off and this tends to happen almost as soon as the hand-holding honeymoon phase ends. Once you begin to tackle concepts and topics that are more challenging, this is when progress begins to stall and motivation levels tail off.
Learners often give up after this honeymoon period not because they lack the talent or capabilities to become a developer, but because of inefficient learning practices.
Learning for the majority of us is incredibly tough. We all learn in different ways, and this is true, but different ways do not necessarily mean ‘effective’. Most of our learning approaches are passive which limits our ability to progress. We’re in a constant battle with our brains. Our brains are naturally hard-wired to pursue the path of least resistance, to find the easier, most dopamine laden routes. It’s your greatest asset but can be your greatest enemy too. Passive learning is an ideal middle ground that seems to appease both parties. It appeases you because you’ve made a deliberate effort to learn, to sink some time into something (your inner-voice is happy) whilst your brain is appeased because it doesn’t have to work too hard to structure any new knowledge or learning.
Let’s define what we mean by passive learning within a coding context:
- Watching tutorials or courses
- Reading articles or books
- Code along exercises
- Learning things you already know
These passive approaches may work for a seasoned developer but for beginners, these approaches are often very ineffective. You’ll find ‘practice’ thrown into the mix to counter passivity but it’s not quite as simple as that. What do we even mean by practice?
All practice is not the same. You’ve probably seen more experienced developers regurgitate the trite expression that “practice makes perfect”. The problem is, it often doesn’t. Practice often follows a standard convention of mindless repetitions over content we already know or we’re already very familiar with. We do this because it makes us feel good, it makes us feel smart, it’s a dopamine trip for the brain. We end up mistaking these positive feelings for growth and progression. We often employ regular, repetitive practice as a means to mindlessly memorise content. Mindless repetition and memorisation cause problems because we fail to solidify our understanding of something. If you understand how and why something works it becomes much easier to structure that knowledge.
Enter deliberate practice. It has a huge amount of research and information behind it. Anders Ericsson coined the term while researching how people become experts. His 1993 academic publication has sparked much research and writing on the topic. James Clear has also written in great detail about this and I’d encourage you to read his awesome introduction on the topic which also contains some useful real-world examples.
To summarise, deliberate practice differs from conventional or regular practice because it is:
In layman's terms, deliberate practice is basically doing things that aren’t necessarily enjoyable. Within a development context, there might be some variations in how we apply deliberate practice but in my opinion, it means figuring out what needs improvement and then focusing on improving that thing until you’re confident with it.
The hardest part of deliberate practice is the frustration and discomfort that comes with it. Ultimately, to be able to grow and improve in a meaningful way there has to be some experience of uncomfortability. This is all part and parcel of growth and we should expect to experience some degree of discomfort – you should in fact welcome it. When you work on something that is outside of your current skill level this naturally comes with a fair amount of struggle.
Frustration and coding come hand in hand. Coding is a constant test of patience. Within a front-end development context, building a performant, accessible, and pleasant experience for users isn’t an easy feat. There are lots of moving pieces, lots of things you’ll need to consider as well as understand, so naturally, you’ll often encounter frustration.
Beginners treat frustration and discomfort as a sign of failure, they become stuck and often become disheartened and unhappy with their lack of progress. A common trait I’ve seen amongst successful developers that I’ve worked with (as well as successful students that I've mentored) is a high tolerance to frustration.
Ultimately, you must accept that frequent points of frustration are unavoidable in this profession. It all comes down to reframing the way you think about coding and how you channel as well as manage frustration. The first step is to readjust your expectations of coding. It's totally normal to feel constantly frustrated. The second, but most important step is to see frustration not as the enemy but rather, as a necessary side-effect of growth. There aren't many situations I can think of where growth in a particular discipline isn't accompanied by some level of discomfort or frustration. With this in mind, see frustration as something to continually seek out. Frustration is a fantastic marker for progress and a strong indication that you’re working outside of your comfort zone – all steps that are a necessity for growth.
Once you've embraced frustration, you'll naturally develop patience and resilience which are highly desirable qualities for a developer. Having the patience and resilience to methodically work through a complex debugging issue is an incredibly important skill, that’s why developers are paid good money!
There’s a great deal to unpack here, and I feel like a lot of what I’ve touched on probably deserves some deeper exploration. For now, I’ll leave you with what I feel are the most important takeaways.
Remember there are different forms of practice. Mindless repetition over content we already know is an inefficient code-learning mechanism. Successful learners often employ a deliberate approach to practicing which is systematic and purposeful – an approach that intentionally seeks out discomfort.
Reframe the way you think about coding, it is a frustrating profession. Try to seek out frustration and discomfort because it’s one of the best markers for learning progression. If you’re frustrated there’s a good chance you’re reaching outside of your comfort zone. This is the sweet spot for learning.
In the end, there’s no one quick trick for achieving success (as with most things in life – coding included) but there are patterns and skills that do often differentiate the successful from the unsuccessful, and within a coding context the successful generally have a high tolerance to frustration and often engage in deliberate practice. What we’ve covered doesn't necessarily just apply to newbie coders, improving your learning practices and reframing the way you see and experience frustration can help developers of all experience levels.
Enjoy coding and embrace frustration!
Thank you for reading!
If you enjoy reading my content and want to support my work, please follow me on Twitter 😊