Our most frequently asked questions are: What coding language should I learn? Where can I learn how to code? How do I learn coding? In this series of articles, we will set out our advice and answers to these questions. In this part 3 we collate our favourite hacks concerning how to think about learning to code. Understanding how to go about your studies will pay dividends in terms of your progression, motivation and ultimate success. Learn how to learn!
1. The Ultimate Skill – Learn how to Learn 
We all know how to learn right? WRONG! A lot of people amble through school, college or university and ultimately life not understanding the science behind learning. The good news? You can learn how to learn.
As Daniel Bourke says:
“If you could have any superpower, what would it be? … the superpower of to learn anything.”
Daniel Boukre, An In-depth Review of the Learning How to Learn Course on Coursera
OK, so who is Daniel Bourke? Daniel is an impressive former nutritionist who writes fantastic content about his self-led self-determined masters in coding, machine learning, deep learning and computer science. See here for how he self-taught himself a masters degree in artificial intelligence and got hired as a machine learning engineer!
A lifelong learner with a growth mindset (see below), after learning machine learning via Udacity and Coursera Courses, he realised he could optimise his learning by learning how to learn.
Luckily Coursera’s most popular course is Learning How to Learn. It’s also one of the most popular online courses of all time (1.935m students enrolled, average review 4.8 / 5)!
So what does Learning How to Learn teach and how can it be applied to learning to code? There’s a lot covered in that course and we’d encourage you to dip into it.
For now, we’ll highlight the most immediately impactful tips applicable when learning to code.
Focused & Diffused Thinking
Focused thinking is the completion of a singular task, e.g. reading this article. Diffused thinking is what happens when you’re not focused on anything. For example, if you’re taking a shower and suddenly a solution to a problem pops into your head. So what to do? Simple: combine intense periods of focus with singular periods of nothing.
Sleep is a powerful way to engage in diffuse thinking. Sleep is also critical for cognitive housekeeping. Whilst you sleep your brain repairs brain cells, but also forms new connections and flushes itself free of toxins that build up in the day.
When learning to code, sleep will not only rest you body and soul, it will actually cement together what you’ve learnt during the day. Just like the gym, much of the biological benefits bed in whilst you rest.
Staying up all night will actually lessen your learning rather than adding to it. Get some sleep! For tips on how to do that, we recommend Sleepfully, a website run by a recovering insomnia sufferer.
Procrastination & How to Overcome It
Smartphones and a litany of digital distractions at work and at home have made procrastination worse for most people. At lawtomated we increasingly find it hard to read a good book without reaching for our phones.
But there’s an easy fix: the Pomodoro Technique. It’s a productivity hack. Whenever we feel our concentration abilities slipping, we enforce the Pomodoro Technique.
So what is it and how to do it?
For timers, you can use:
- a physical timer, e.g. a kitchen timer or stopwatch; or
- an app, e.g. browser-based, iPhone or Android based.
At first, you may find 25 minutes a challenge. If so, start with 10 or 15 minutes and work up to 25 minutes. It’s powerful because whilst you cannot control whether or not you solve every task before the end of a day’s work, you can control how much time you put in.
By focusing on process (Pomodoros) you avoid becoming overwhelmed by the product (what you need to achieve, i.e. learning to code). In turn, this will make it easier to start tasks, but also easier to keep going with tasks, and in doing so avoid procrastination. As a result, learning to code will become less overbearing!
Spaced Repetition
If you’ve ever used language learning apps like Duolingo, or flashcard apps like Anki, you’ll have encountered spaced repetition.
Spaced repetition requires you to practice new and more difficult tasks more frequently than older and less difficult tasks in order to exploit the psychological spacing effect.
When learning to code, if you are finding something increasingly easy, move on. Revisit it again in a few days or weeks. If it’s still easy, don’t try it again for a month. If something is hard, keep practising it at shorter intervals than the easy stuff. Eventually, it will become easier and you can safely revisit it less and less without forgetting it.
Don’t Break The Chain
Learning to code is tough. Your confidence can rise and fall. If you’re learning to code around your day job, competing priorities of work, personal and social lives can get in the way.
A powerful method to reinforce your priorities, i.e. learning to code, is the Jerry Seinfeld chain technique.
The famous comedian kept (and possibly still keeps) a calendar. OK, so do most people. But what Jerry does is different. Every day he commits to writing x 1 joke, and marks an X on the calendar for that day. As the X’s add up, it starts to look like a chain.
As the chain increases, it becomes psychologically more and more difficult to break the chain.
Using this technique is incredibly motivating and great for forming positive habits (or breaking bad ones). In other words, use it to change other aspects of your life, e.g. going to the gym, going vegan, giving up alcohol, spending more time with loved ones and so on.
If you don’t have a physical calendar, Habit Hub is a fantastic app in this regard: it allows you to set-up and track multiple chains across a calendar to build or break a variety of habits simultaneously. You can also run some basic metrics on your progress to enforce further motivation.
Top tip: if you use a chain app, put it on your homepage otherwise it's easy to consciously or unconsciously avoid tracking your progress. Failing that, get a big wall calendar and put it somewhere you can't avoid, like your bedroom, kitchen, bathroom or office. The more in your face, the more powerful the reminder to action and maintain your habits.
Eat that frog!
This one is simple: do your hardest task first thing in the morning. Why?
- If you don’t there is a greater likelihood you will procrastinate.
- Having done that thing, everything else will seem easier and more doable.*
“If it’s your job to eat a frog, it’s best to do it first thing in the morning. And if it’s your job to eat two frogs, it’s best to eat the biggest one first.”
Mark Twain
2. Marginal Gains
This is another simple tip: if you code a little every day, you’ll quickly accumulate marginal gains. These marginal gains compound, exponentially increasing your abilities each day.
In fact, the success of British Cycling athletes in recent years has mostly been accredited to marginal gains. Rather than trying to completely rethink cycling, the teams involved focussed on chipping away at marginal improvements to what they were already doing (e.g. rubbing alcohol on tyres for greater grip or finding the massage gels that led to fastest muscle recovery times).
Over time, and in aggregate, these marginal gains combined to create a multi-award winning cycling team.
Just five years into this program, British Cycling dominated road and track cycling events at the 2008 Olympic Games, winning 60% of the gold medals. Four years later at the London Olympic Games, British Cycling set 9 Olympic records and 7 world records…
… long story short: between 2007 – 2017 marginal gains led to British cyclists winning 178 world championships, 66 Olympic and Paralympic gold medals and 5 Tour de France victories. Not bad, for being 1% better every day!
So when learning to code, try and code every day. You might not build an entire app every day, in fact you probably won’t. But you will keep improving.
You should also use the marginal gains mental model as a means to improve how you learn. The ideas in this article provide suggestions, but we encourage you to experiment daily with what works for you.
3. Develop a Growth Mindset 
Carol Dweck’s book, Mindset, is a great read. The book postulates that there are principally two mindsets:
- a growth mindset; and
- a fixed mindset.
Each mindset has different characteristics. Essentially the fixed mindset views intelligence as static whereas the growth mindset views intelligence as plastic, something that can be developed.
As a result, the growth mindset is adaptive, optimistic, embraces / seeks challenges, learns from mistakes and moves on to the next thing. The fixed mindset is the opposite: averse to challenges, gives up easily, pessimistic and sees mistakes as failure and nothing more.
If you are going to go away and learn to code it’s going to be hard. You’ll face challenges, both technical problems to be overcome and crushing collapses in confidence when you get stuck. A growth mindset will power you through, whereas a fixed mindset will cause you to crash and burn and ultimately give up. For any lawyers reading this, some bad news. Lawyers tend to have, or develop, a fixed mindset. Try and break the mould! The good news is that you can.
These differences are nicely summarised below:
OK, so what if you think you don’t have a growth mindset? Well good news, you can develop one. We won’t go into detail about how to develop a growth mindset. Instead, check out Carol Dweck explaining how to build one:
If that whets your appetite, we also highly recommend her excellent book. It’s a great read and we learnt a lot, including how mindset can just as easily ensure success as self-sabotage it.
But please, don’t take our word for it:
“The value of this book extends way beyond the world of education. It’s just as important for business people who want to cultivate talent and for parents who want to raise their kids to thrive on challenge”
Bill Gates
4. Are you top-down or bottom-up? 
The bottom-up approach involves exposure to only the component parts of a particular subject matter, and slowly builds upon those components towards an understanding of the whole.
Learners adopting this approach only move on to the next component once the previous prerequisite components have been identified and mastered. If it sounds familiar, this is because traditional education tends to favour this approach.
Bottom-up learning has a number of advantages, e.g.
- The learner is able to acquire a complete understanding of the subject provided they take time to master each component part.
- Learning is easy to structure, breaking the subject matter down into atomic parts.
However, the learner will often lack any useful context about what they are learning and how it relates to its application in the real world. For instance, in coding you might learn everything there is to know about variables but it will be more or less impossible to apply absent of context and its interrelationships with other concepts, e.g. functions.
The priority of a top-down approach is to provide a wider perspective of a problem or subject area without necessarily going into endless detail about specific components. So rather than learning everything there is to know about variables before learning about operators, you might instead decide to try and build a simple app that relies upon multiple components.
The focus for top-down learning is less of regimen, but more on experimenting and exploration. Top-down learning can be greatly rewarding as it is more likely (and sometimes faster) to produce practical applications of knowledge, e.g. an app.
However, top-down learning is also imperfect. Top-down learning leaves the choice of details to the student. Sometimes the lack of structure can be intimidating, especially if you dislike ambiguity. This lack of structure and discretion as to what to learn in order to achieve the end goal can result in a spotty understanding of a subject matter.
So if neither is perfect, which to choose?
Cliche as it may be, we think the best approach is a bit of both. In fact, we often do just that.
As at the time of writing, we are currently studying Andrew Ng’s fantastic Deep Learning specialization via Coursera, a bottom-up course that teaches in huge detail the underlying mathematics, statistics and probability computations that make neural networks work and places less emphasis on coding. But we are also about to study the top-down FastAI course. For that course, the focus is on experimenting and building real-life AI applications using code libraries (rather than getting into the nitty-gritty of the underlying maths and working up), whilst gradually peeling back layers of the AI onion.
5. Whenever possible, learn by doing 
Coding is a very practical subject. If you work in law and are reading this, the analogy would be the difference between:
- knowing lots about contract law from books; and
- being able to draft a great contract to govern a complex commercial deal.
Expertise in the former, without experience doing the latter, will make the latter pretty darn hard.
You often learn most when doing – also known as active learning. To do so do the following:
- Seek out tutorials that inspire you, e.g. if you like games (as we do) try and find tutorials to make an arcade game. Here are a few we like: (a) Pong in JavaScript, (b) Brickbreaker in JavaScript, (c) various games like Space Invaders in Python, or (d) for the more advanced this excellent course by Harvard teaches several games including Flappy Bird, Super Mario, Angry Birds and Pokemon, and for mobile gamers this fantastic iOS 2D gaming app series or its 3D gaming series (advanced) by www.raywenderlich.com is top quality.
- If you are reading about code online or in a book, don’t just read it – experiment with the code. To do so you will need an IDE (an integrated development environment). More on those in Part 4, but for now think of an IDE as a an interactive playground in which you can write and test code.
- Find projects that excite you and try to define requirements and then build each requirement out from scratch.
6. Crossing the chasm (moving on from tutorials) 
The tutorial trap promises knowledge and understanding. You want to build a twitter clone. You Google “coding tutorial twitter clone”.
Before you know it you have 10s of tutorials stepping you through from 0 to functioning twitter clone. Very quickly you have a glossy app to show friends and family. But often you’ve only succeeded in acquiring very specific knowledge about achieving a very specific task in a highly specific way (i.e. the way the tutor chose to solve the problem of recreating twitter).
What you learn won’t easily generalise. You’ll find it frustrating that you can’t suddenly build something similar from scratch, e.g. Instagram. So you Google “coding tutorial Instagram”… and so the cycle repeats.
So how do we avoid this? Simple – do this:
- Never copy-paste. If you’re doing tutorials, always type out someone else’s code and never copy-paste it. This applies whether you are following a tutorial, an online course or researching an answer to a question on StackOverflow (see below). It forces you to think about what you’re doing, e.g. naming variables, defining or calling functions etc and how the code is working.
- Annotate. Imagine someone reading your code with zero knowledge. Better still, imagine they are 5 years old. Annotating with them in mind will do two things: (1) force you to slow down and really test if you understand what you’re implementing (it’s easy to kid ourself otherwise!), and (2) provide a fantastic aide memoir should you want to revisit your code. Don’t annotate the easy stuff, focus on the stuff you don’t understand or think you’ll struggle to remember in future.
- Spike code. If you really don’t understand what a line of code is doing, try and recreate it separately and test how it works in isolation. Gradually build up from there to the full line (or lines) of code that is causing you problems.
- Extend code. Add new features. If it’s twitter you’re cloning, why not try and add a feature from a different social network, e.g. up and downvoting a la Reddit? It will push you outside the comfort zone of the tutorial but also help you better understand the architecture of what you’ve built via the tutorial, and the new feature you wish to add.
- Change the example. If you find a tutorial on how to build a twitter clone, try to tweak it as you go to create Instagram instead. This will get you really thinking about what you’re learning, but most importantly how to apply it to novel problems outside of the tutorial scope.
7. Ask for help (how to ask, and where to find it) 
Where to ask questions (StackOverflow + Google)
The best place to ask for help is Google, and then Stackoverflow. When you first start learning to code it can be difficult to know what to ask and how to ask it. But once you pick up some basic knowledge it starts to get easier (see the below section “9. Be an Alien”).
For instance, knowing that something is a variable and something else an array is much better than not knowing what either is and trying to ask what’s going wrong with a bunch of code containing both concepts.
How to ask questions (StackOverflow Guide)
Although there is no such thing as a stupid question, there are better ways to ask them. As useful as Stackoveflow is, it is intimidating. Techies can be a bit snarky and often have little time for timewasters. They can also be highly opinionated. But like everyone else, they have stuff to do. Trying to second guess your question makes little sense and is a waste fo their time, so come prepared.
Thankfully, Stackoverflow provides a fantastic but snappy guide on how to ask technical coding questions to avoid getting slapped down by an overzealous Stackoverflow contributor. We highly recommend you read this guide before posting questions to Stackoverflow.
It’s available here.
TLDR: do your own research first, explain and document your problem (including where necessary your code + error messages, which will help someone reproduce it and ideally solve it), and pretend you're talking to a busy colleague to ensure you're getting to the crux of your need.
8. Code is binary, learning is not 
This one is simple: mix it up. Experiment with different learning styles. Don’t rigidly stick to the advice here, nor elsewhere. What works for others might not work for you. What works for you might change as you progress through your learning journey. As with weightlifting, you might need to challenge yourself in new ways as you go to keep stimulated and encourage new growth.
See “10. Learn to Surf” below for how this applies to the various stages a learner experiences when learning to code.
9. Be an Alien 
Imagine you are an alien. You and I are both stood in front of a tree. As a resident of planet Earth I know everything there is to know about the tree. Your job is to ascertain as much information as possible from me about the tree and report back to your home planet on the subject of trees.
According to Nicholas McBride’s fantastic Letters to a Law Student, one of the best books about learning how to learn law, there are two ways you can do this.
Method 1: Osmosis
You could ask me to tell you everything I know about the tree. I’d waffle on for an hour or so about the tree. To be honest, I don’t know what you need to know, so I’ll just guess. I might not even know anything about this tree, or any tree. You’d try and absorb as much as possible and take notes.
The problem is that you’re being passive.
Your attention will wander, you’ll get bored and you’ll miss what I am saying. More importantly, you will miss what I am not saying. For instance, what little you will have heard might be entirely related to this specific tree, and useless for understanding trees in general or in context. So how do you fix this?
Method 2: Question-driven
You ask me lots of open questions and are in charge of the process throughout. Where necessary you dive deeper, following up with closed or directed questions to check assumptions, identify gaps in my answers or your understanding, and to clarify whether answers do or do not generalize to other contexts (e.g. trees in general or trees as a variety of flora, itself a category of biological life and so on). You can also check if I am the right source of information and, if not, decide to move on and find another source.
You succeed at learning more and retaining more because you are being active.
Because you are more involved throughout, you will pay greater attention and learn more about this tree, but also trees in general and their wider context (and how they interlock with other parts of Earth’s ecosystem). You will also be critically examining the sources of information, determining whether they are relevant but also whether they are the right ones for you. As always, it’s best to read / study around across different resources than relying solely on a single source of information with regard to a subject matter.
Why is this powerful?
With this technique, you can know nothing about a subject yet ask 100s of initial questions, which themselves will spur 100s more. Don’t believe us? Think about it:
- What is a tree?
- What kind of tree is this?
- How many different kinds of trees are there?
- What makes this tree different from other kinds of tree?
- Are trees living or non-living?
- How long do trees live?
- How old is this tree? Has it suffered damage over its lifetime?
- Why are trees green?
- Are all trees green?
- Do trees change colour? If so, why and when?
- Hang on, what are those little flappy things living in the tree?
- OK, so they are birds, what are birds?
- Do birds live in all trees?
- Why do birds live in trees?
Many of the same basic questions (what, who, how, when, where and why) can be used to divine increasingly comprehensive questions that quickly build knowledge and ultimately intuition and insight about a subject. The same is true of coding, e.g.
- What is a variable?
- What are variables for?
- How are variables used?
- Why are variables used?
- When do you use variables?
- Where do variables get used?
From these basic open questions, you will start to learn a lot, quickly uncovering deeper questions, e.g.
- How do you create, update and delete a variable?
- How do you store variables?
- How can you combine variables?
- How can you apply operations to variables?
This can be especially powerful when you start exploring some of the computer science behind coding, e.g. “how do computers understand language?” or “what is memory?” etc.
Using this technique you can identify lots of Data – that could mean something – or nothing.
From there you can start to understand meaning or relationships in the data, converting it to Information.
Diving deeper Knowledge is gained when we are able to memorise the information, for i.e. variables are a storage address paired with an associated symbolic name, which contains some known or unknown quantity of information referred to as a value. As we gain knowledge we begin to make sense of things and draw connections between different pieces of information.
At this point we can begin to learn Insights, the ability to synthesise knowledge in order to obtain a deep understanding of a problem, e.g. that variables are similar in construction and purpose to defined terms in contracts.
With insight comes the prospect of ‘Wisdom’ – the ability to use insight to facilitate informed decision making, e.g. that variables and contracts might be overlapped in a smart legal contract paradigm.
The question-driven approach is a fantastic means to guide yourself from data to wisdom.
10. Learn to surf 
Learning to code is like learning to surf. You need to anticipate waves and ride them when they roll high and be prepared for when they come crashing down. You also need to know how not to drown.
With coding, confidence vs. competence will feel vastly mismatched. You’ll experience these in waves. Some days you’ll feel like a coding guru, the next a clueless noob drowning in unknown unknowns.
Don’t worry: this is totally normal and a sign you’re moving forward. So how to anticipate these waves, ride them well and suceed?
Thankfully, Thinkful.com have produced an absolutely fantastic explanation as to why learning to code is so damn hard. But crucially, they’ve mapped each wave and how to overcome it. We highly recommend you check it out.
To summarise their core idea (which we’ve found through experience to be true), see the below diagram:
The key takeaway from the thinkful article is that your coding journey divides into 4 phases:
“1. The Hand Holding Honeymoon is the joy-filled romp through highly polished resources teaching you things that seem tricky but are totally do-able with their intensive support. You will primarily learn basic syntax but feel great about your accomplishments.
2. The Cliff of Confusion is the painful realization that it’s a lot harder when the hand-holding ends and it feels like you can’t actually do anything on your own yet. Your primary challenges are constant debugging and not quite knowing how to ask the right questions as you fight your way towards any kind of momentum.
3. The Desert of Despair is the long and lonely journey through a pathless landscape where every new direction seems correct but you’re frequently going in circles and you’re starving for the resources to get you through it. Beware the “Mirages of Mania”, like sirens of the desert, which will lead you astray.
4. The Upswing of Awesome is when you’ve finally found a path through the desert and pulled together an understanding of how to build applications. But your code is still siloed and brittle like a house of cards. You gain confidence because your sites appear to run, you’ve mastered a few useful patterns, and your friends think your interfaces are cool but you’re terrified to look under the hood and you ultimately don’t know how to get to “production ready” code. How do you bridge the gap to a real job?“
Source: https://www.thinkful.com/blog/why-learning-to-code-is-so-damn-hard/
As we shall explain in part 4 of this series, different learning resources will map to these 4 phases. In particular, notice in the above diagram that resources are at the densest and most plentiful in phase 1, and gradually become not only few and far between, but also harder to find. But don’t take our word for it, please do read the awesome thinkful article. Take some time to meditate for a moment on their suggested solutions to overcome the confidence vs. competence waves.
You’ll thank us and them for it!
Start!
Learning to code is as much about how you learn as what you learn. If you follow these tips your coding learning journey will be smoother, faster and more rewarding. But remember, this is a guide not a set of rules – experiment with what works best for you! You may find this changes over time, particularly as you ride different waves of confidence vs. competence. Good luck!
Please also check out the other parts to this article series: - Part 1: why learn to code? What's your why for learning to code? - Part 2: which language(s) to learn and why? - Part 3: learning how to learn to code (and why it matters!)Coming soon
Are you a lawyer interested in learning to code? Read this first: Should Lawyers Learn to Code?
The post Coding for beginners: 10 tips on how you should approach learning to code (Part 3) appeared first on lawtomated.