Not everything school teaches you is useful
About 6 months ago I decided that I was fed up with people telling me which jobs were and weren’t within my reach because I wasn’t a ‘technical’ person. So I started learning to code. After an intensive (and free) coding bootcamp, I’m now building apps for early stage start-ups for money – and you can too.
Throughout the learning process I found that nothing I’d come across in formal education had introduced the skills or concepts I had needed to be able to build something that worked. In fact, I feel like I’ve spent the last few years un-learning those ways of working. Here are some of the things that surprised me.
At school, exam success revolves around your ability to memorise as much content as possible. Then, if you throw all this out in the practised format you’ll receive those all important grades, acceptance into university, a management consulting career, and a house in the suburbs. When you start learning to code nobody cares what you can memorise. You need to learn where (and how) to look for the information you need as it’s definitely not in your head.
Even for developers with years of experience, using the internet to search for solutions is a big part of their day-to-day work. They’re switching technologies and languages at a pace that means memorising the exact way a function works isn’t the best use of their time. As a beginner, that programming language you just got the hang of will be updated without notice and you’ll feel like you’re starting again. But this time you’ll be better at knowing how to look for the answers.
School teaches you that plagiarism is bad. Copying something exactly and not crediting the source will get you a fail and maybe even booted out. Learning to code, meanwhile, teaches you that copying chunks of code from Stack Overflow is the only way your first site is going to work. As you gain experience, building on top of solutions that other better qualified people than you have made is still the recommended practice.
For example, yes, you could make your own login and securely store your users’ ‘unique’ passwords. But why would you when Google will let you add a ‘login with Google’ functionality to your site and handle it? They definitely have a bigger team of developers than you do tasked with making sure this works, leaving you to focus on creating new things by combining the blocks other people have made.
School teaches you to keep re-drafting your work until you have something perfect enough for review. It’s time consuming but delivers the best results. However, when you’re creating a new technical product you need to build something that you can show to users and get feedback from as soon as possible. If it’s perfect then you spent too long building it. As you receive feedback, new features will become a priority and those old features will be binned or re-drawn. So there was never a need to make it scalable to your first million users in version 1 when your first 100 users can tell you they won’t ever use that.
At university there were always a few people who managed to have a hard drive implosion and lose their dissertation. The thought of having to re-write that was enough to make everyone else run and make another copy of theirs. With software, starting again isn’t the result of spilling a cup of gravy on your Macbook (this actually happened to someone from my course). Often the most valuable thing you’ll get out of your version 1 app is how to build your version 2. You could spend a month or two trying to re-write and remove those poorly constructed ‘just ship it’ areas of the code, or you could build v2 from scratch, with all that knowledge and without any legacy bugs in a few weeks. And you’ll know which features you can scrap too.
You’re not all competing for a finite number of ‘firsts’ any more. When you’re learning to code, having conversations with people about the subject will only help you. If your conversation partner is better at this than you are, you’ll hear their take on the problem and improve your method for solving it. If they’re less knowledgeable, then explaining your methodology will only improve your ability to break down the problem into its simplest form. Which leads to my final point.
OK, so school does teach you this one. Structuring the things you write in a clear and logical way is how you get your point across. A developer friend once told me that you’ve never felt frustration like having to handle unreadable code. You shout and insult the person who wrote it before checking the history to realise it was you. All those months ago. At a level of obscurity that meant you hadn’t even recognised it as yours.
Your code needs to be well-structured and readable in the same way an essay does. Writing all your code on a few lines without naming any of your functions is like using a thesaurus on every word; very annoying and makes you look less intelligent for not realising how useless this is going forward.
I’ll be writing soon about how I became a developer in such a short space of time, but in the meantime, the full-time and free) course I took is accepting applications now.