I fantasized about learning to code for years. When I finally decided to take the plunge I thought the best way to do it would be through a bootcamp. I had taught myself growth hacking and doing this alone, with no-one to bounce ideas off, I constantly felt like I was doing it all wrong, taking everything in the wrong direction, and so this time I wanted to learn alongside others.
I decided to enrol in Maker’s Academy, ‘Europe’s most exclusive’ intense web development bootcamp. The first six weeks of Makers are spend working as a pair on a challenge, swopping who you are with every day. This way of working is known in the industry as pair programming.
The first day I arrived at Maker’s Academy, I, like what turns out to be 80% of the people there, had a hunch that I was the worst coder on the course. That I would need to wing it while pairing with someone else in the day time, pretending that I understood all the stuff I didn’t then go away and stay up all night going over what we had done.
I noticed, or thought I noticed (but again it turn’s out many people also felt the exact same) that the weekend challenges would take me all weekend and I would never get through them.
I set out to try and understand why I wasn’t as good as everyone else and what I could change or do to improve this.
I felt that working with a different person every day, one on one, through pair programming, gave me some pretty good insight into what makes someone good at code.
To try to understand what makes someone better at learning to code I looked into a few things:
- I observed others. Those that I considered quicker at solving coding problems / understand and those who were slower to grasp it. I noticed a key difference in the way they worked. Those that were better simply were those who spent more time at the keyboard, who coding more, who experimented more, who treated the code with curiosity, something they could break. Those who weren’t as good were those that found reasons to distract themselves, to have a spontaneous break, breaks which became more frequent when a problem was challenging. If you didn’t look closely at these two groups you may even have thought the second group actually spent longer coding / at the keyboard, as their working day seemed to be longer. But in fact, they were spending less time doing the work in that day.
- I observed myself. I set myself a coding goal for the day which I wrote on a piece of paper. I marked this paper every time I strayed from my set task. This allowed me to properly notice every time I was doing something which was not coding. In the past I had fooled myself into thinking was productive, as much of the time it was reading around the subject or something else vaguely related. This allowed me to see just how much time I wasted changing direction, thinking up other tasks and goals for that day, and reading / doing anything but writing code.
- I spoke to my coach about what is the best way to think / learn code. She told me that at this early stage in my learning, I would learn best by just doing. Find the smallest possible working programme in the language that I want to learn. Playfully changing one small thing at a time then observe what happens. Learn by doing not by reading or even by watching someone else’s doing. This does not mean don’t pair programme it means be involved in the doing no matter what your role in the pair is.
- I observed my improvement over time. Two months into the course I went back and did one of the first weekend challenges. This allowed me to see exactly how I had improved. This was extremely useful for motivation. It allowed me to combat my head telling me I was terrible at coding, yes I was terrible but at least I wasn’t as terrible as the me of two months ago. It showed me how the simple act of doing coding more had made me better.
From these observations I concluded:
The more you do something, the more you practice, the better you get at it. With no real exception. If you want to get good at something, just keep doing it over and over again.
Those who were ‘naturally’ better at coding were just those who had practiced more. Either directly or in an activity which develops that same part of their brain.
THE BEST WAY TO LEARN AS A NEWBIE:
The best way to learn as a newbie is to simply DO and practice as much as you can.
Start super small and find fun in the understanding, get playful when learning. Get the smallest working programme you can find and take it apart bit by bit. Approach the code with playful curiosity, seek to understand every part of the puzzle for yourself. Change it or write something in small chunks then observe what happens.
Have fun, don’t read just do.
Don’t be put off learning to code by thinking others are better than you.
What I learnt was there was no real difference in natural intelligence or ability to code. It was simple, the more someone has practice or done coding or skills which required the same, logical side, of their brain, the better they were at it.
This means if you are worried about doing a bootcamp or think you aren’t clever enough to code then all you need to do to solve this is practice more.
If you don’t want to start feeling like you are behind other people but worry your past experiences don’t lend themselves to being a good developer then practice as much as you can before starting the bootcamp.
There are so many free resources out there for very beginners which you can force yourself to sit through and endure, satisfied with the knowledge that the more you do that the better you will get, then you will for sure be good enough to be a coder and to hit the ground running starting as a developer or at a bootcamp.