The Makers precourse — Reprogramming my idea of learning
I have just completed my third week of the Makers precourse, now one week away from the full-time bootcamp, and I’ve learnt as much about learning to code as about code itself. It sounds like the same thing, but I don’t think it is.
Let’s talk about memory. When I first started my coding journey I tried to remember everything, writing detailed notes as I worked through the Codecademy Learn Ruby track. What I know now is that this is pointless when you can have all the reference you need on your screen at the touch of a key. If you try to imagine remembering everything, it’s instantly overwhelming, especially when you consider learning multiple languages, and that doesn’t even take into account that this is a subject that is always changing.
All those years ago, when I did my degree in Biomedical Sciences, I found memory very interesting. Any neuroscientists reading this, please forgive my crude explanation, I’m a little rusty but I’ll give it a go. When you learn something, specific patterns of neurons in your brain trigger, and fire a new pathway (or synaptic connection). The more times you think about that thing, the more established the connection becomes, and the better you have memorised the thing. So traditional learning means going over the same thing again and again until the pattern is so well established you don’t forget the thing, and this is how we memorise and study for tests.
What’s different while learning to code is that it’s ok to forget things, and look them up, and look them up again the next time you need them. That’s because there really are too many things to know, and if you try to remember everything, you actually limit your learning, and therefore what you are able to achieve. Of course, the functions we’ve used a lot are already second nature, and that saves time, but it’s nice to know that when I’ve learnt more languages and almost forgotten Ruby entirely, I can look them up again, and that’s ok.
I think the precourse is actually less about (just) learning code, and more about how to think, and how to problem-solve. Breaking down the problems we were given and troubleshooting the error messages has been of the biggest value for me. It’s nurturing a new mindset and way of approaching learning. As a developer, you are never going to be in a situation where you need to remember code without resources; there is no exam, and Googling is not cheating. So these learning processes are the messages the neurons are firing, rather than chunks of code to be regurgitated on demand. It’s fundamentally changing how I think about memory and learning, in a very effective way. There’s no point in knowing code if you don’t know how to use it.
So, as early in my coding journey as I am, my conclusion so far is that the best way to learn to code is to make mistakes and keep making them until you don’t. And then you might make them again, and that’s still ok, because you have the docs open on your computer, and you know how to read the error messages. And every time I’ve made a mistake, I’m less likely to make it the next time, and I know better what to look for. That’s not to say it doesn’t sometimes feel like you are banging your head against a brick wall, but at least the precourse is teaching you tools to break it down. And when you do break it down, it’s extremely satisfying.
My advice for anyone starting the precourse would be this: forget about remembering stuff, and focus on the process. If you limit yourself to what you’ve memorised, you limit what you can learn, and therefore what you can create in the future.
If you’re interested in my journey so far, here’s my previous blog post. As I start the main course I won’t promise a specific timeline for posts, but I’ll write as I have things to write about, so follow along if you’re interested!
