3 incredibly boring but highly effective ways to learn, and get better at, JavaScript
I always hear people complain that JavaScript is hard to learn, or that it’s just not clicking for them. This frustrates me. It frustrates me because I want to help them learn, help it click for them.
I’ve run a number of workshops in recent years, and whilst there were a few “A ha” moments for people, I think overall, I lost a little bit of confidence in the format and the short time I had to teach people what they needed to know.
So I looked back at my own learning, which began in 2009, and picked 3 ways that I, looking back in 2016, found to be the most effective in the long-term. They each have their own short-term wins, but they also had unexpected long-term benefits.
Refactoring every piece of code you come across
What you do
Every time you see some JavaScript code posted online, via Twitter or Hacker News, refactor it. You’ll likely have no context, but just go ahead, open up JSBin, paste it in and attempt to improve it in some way. Word of warning; some people don’t take too kindly to you replying to them with an arbitrary refactor of their code they’ve put effort into. Some might, but a lot won’t. So use your own discretion as to whether or not you let your refactoring results see the light of day.
Short term wins
Refactoring is a great way to insert yourself into the context of some functionality, and try to make it better. Now, like I said, you likely won’t have context for the snippet of code someone posted on Twitter, but searching GitHub will yield far more complete applications for you to practice on. Clone the repo, run the app, refactor it, run it again, rinse and repeat.
Long term effects
You get good at spotting patterns in good code. You get good at using these patterns in your own code. There’s a saying in software development:
Make It Work Make It Right Make It Fast
Ideally, you’ll be naturally getting better at the first part of this; “Make it work”. But by becoming better at refactoring, you’ll start to reduce the gap between the second and third part of this, ie. you’ll actually begin to write nice, refactoring code a lot sooner in the process. Less skyscrapers built on sandcastles.
Sitting on Stack Overflow’s “Unanswered” page for JavaScript and hitting refresh
What you do
You head over to http://stackoverflow.com/unanswered/tagged/javascript and you attempt to answer as many questions as you can. You then hit refresh and tackle the next wave.
Short term wins
You get good at problem solving. A depressingly small amount of our development time is actually spent building new features, or writing fresh code. It’s spent debugging. If you can get good at that, you can identify and fix bugs a lot quicker, and that can only mean good things.
Long term effects
One of the most frustrating things I’ve found, when learning something new, is not knowing what you don’t know. If you can find out what you need to know, you can actually work on knowing that stuff. Hitting the “Unanswered” JavaScript page on Stack Overflow exposes you to a variety of problems people just like you are having. Problem’s you’re going to have. Problems which you can use to build up an arsenal of debugging techniques. When you spend some time on this page, and start answering these questions, you start to spot patterns and categories of problems people have. Once you can nail these basic, common issues, and how to solve them, you can improve your debugging time rapidly.
Soaking up every technical JavaScript book you can get your hands on
What you do
You head over to somewhere like O’Reilly, and you buy loads of JavaScript books. And then you start digesting them.
Short term wins
A little obvious, but you get content taught to you by incredibly smart JavaScript people. You see really good code and have complex topics explained to you.
Long term effects
Reading books might be your first port of call when starting to learn something new, it’s certainly mine. By doing this in different areas, I’ve noticed something that happens every single time. I’ve started thinking of it as “layered learning”. You attempt to swallow a lot of knowledge in one go, which largely feels theoretical and hard to apply. It happens. You then start practicing whatever it is you’re learning and applying some of that previously learnt knowledge. At this point, my suggestion is that you go back and re-read topics you previously felt were over your head. Now that you’re a little bit more clued up, I promise, this re-read will help certain things to click. It’s like with weightlifting, you may try and jump up in weight too much for where you’re at, and you may fail at it. So, you drop back down and go over previous weights, and build up gradually again. Same thing with JavaScript, go back to topics and re-read them. This will make for a really solid foundation for you to build up on, and this knowledge will stick. You’ll be debugging one day, and you’ll suddenly remember some obscure chapter in a Nicholas Zakas book and it’ll click for you.
Learning is not easy, it’s hard, and it’ll beat you down, but…
“Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led difficult lives and led them well.”― Theodore Roosevelt
Cliche quote included. Medium post complete. Romeo done.
I haven’t got any public workshops booked in for 2016, but I’m available for private training at your company, wherever that may be. Whether it’s JavaScript training you require, or more niche training, like React, drop me a line and we can have a chat ✌️
