Some techniques to strengthen your learning path.
In this article i want to try ans share some of the small “techniques” i found useful when learning how to code. I’m not a teacher or an expert on education and this article is not a step by step guide on how to become a developer, but it’s a collection of little things that can strengthen your learning path.
The notions below can be applied by complete beginners but also by experienced developers. I’ve been coding for a living for the past 15 years or so, and i use these techniques all the time.
Your first step in learning any programming language or framework is to investigate it. Go over to Youtube and find some descend videos that will give you a birds eye view of whatever you want to learn. The key here is to answer the following questions: “Does this solve the problems i’m having?” or “Does this thing enable me to do the things i need?”
Something that you will learn very quickly is that there is a insane amount of things you can explore in tech, and it is very tempting to want to know it all. But that will lead you onto a path of feeling overwhelmed and that you will never be good enough.
Instead try to stay focused and spend your valuable time on the things that enable you to build the things that you, and your clients, need.
When you found the thing you want to learn, go and find a good course on that subject. There are many many courses online, both payed and free. But remember that payed doesn’t equal better.There are a lot of dev’s out there that create amazing free content and courses. If you are not sure, ask around either with friends and co-workers or on socials like twitter. Just make sure that you pick a coherent course that takes you from point a to b, instead of going down a endless path of jumping from tutorial to tutorial. Also called tutorial hell.
During the course, write out the code at hand. Don’t just watch the video’s and think that you are an amazing student. Trust me on this one, if you are not typing you are not learning anything.
Also don’t spend all day on your course. After about an hour your brain will take in less and less information. Try to find a pace that works for you, maybe do one video, write out the code and then go and do something else and come back to your learning a view hours later.
If you struggle with consistency, and haven’t heard about it yet, check out 100DaysOfCode. A lot of advanced and beginning developers find this a great tool of motivation.
Research and explore
When learning new aspects or function of a language/framework i find it very effective to utilize online resources like CodeSandBox or CodePen to play around with new techniques.
This has three major advantages. One: You can solely concentrate on this new material without the clutter of other code that could impact and confuse what you are learning. Two: You can keep these sandboxes around and later use them as a reference without having to go and find your last implementation is some other project or codebase. Three: You can add/try different use cases for reference later when you need to.
As a bonus, you can also easily share your sandboxes or codepens with others to ask for feedback or pass on you newly acquired knowledge.
Sandboxes are also amazing tools for figuring out parts of a project. As an example i was recently fighting with React Router and couldn’t get it to do what i needed inside of my project. So i decided to set up a quick isolated test case in a sandbox so i could only concentrate on that specific aspect, and i got it working pretty quickly. And now i also have a bare-bone setup that i can go back to whenever i need to implement a similar use case.
Disclaimer: I am in no way affiliated with the services mentioned above. There are other great ones as well that provide similar functionality, but these are just two that i like and use. Just so you know. 🙂
Research and practice
The only way to learn how to code is to code. We all know this, and it is called practice. Just think of a project you would like to build and start building it. But…
If you want to build a todo app, please don’t go and google a todo app tutorial and blindly start copying the code. Firstly you are not typing any code and the aspiring developer in you is learning little to nothing. Secondly you are missing the point of being a developer, which is being able to breakdown a project into smaller features and solving coding issues/problems.
A much more effective approach is to figure/write out what features a todo app needs, lay that out in a blank project and then when you can’t figure something out go to the official docs or do a google search for that specific problem or language feature.
When your todo app is done only then google for a todo app tutorial to see if there are things you could have done better. If there are, close the tutorial and implement that refactor on your own again.
Trusting “own knowledge first” is key here.
Disclaimer: When you are on your boss/client’s clock and need to implement a live search by all means google for a live search tutorial/example and save everyone some time. You can always go home and develop your own version later for learning purposes.
No matter how hard you try you will never know everything and you are going to run into problems and bugs. It’s just part of the job that we all need to except. This doesn’t mean you can’t make the most out of these issues.
Bugs are excellent teachers
On very effective way of dealing with these issues is reflection. Reflection can be applied after you finish a project but in my experience its better applied after fixing a bug/problem or after finding a solution to a problem on mediums like Google or StackOverflow.
When after a bit of struggle you fixed a bug or problem, take a step back for a second, figure out and write down which “gap in knowledge” got you into trouble. When you analyze which functions or design patterns etc were key to the solution. Then you can spend some time reading up on that specific topic or language feature.
This is a very effective technique for learning. But i can also, to a large extend, help prevent you from having to ask the same question twice. Which will save you from some annoyed faces from senior dev’s and colleagues.
Something that can help you with this is to create a google doc (so you can add links) or buy a notebook and write down the things that gave you a hard time so you can go back home and do some additional studying.
Sharing and teaching
Besides practice, trying to explain something to others is the second best way i can think of to solidify your newly found knowledge. So i would advise anyone that is, or wants to be a developer, to start a blog, or start writing articles here on dev.to today.
It really doesn’t matter if you are a seasoned dev or if you are just starting out. If you have struggled with something there is a huge chance that someone else will face that same issue. And your perspective or explanation could be the one that makes thinks click with that person
Simply create a small use case around the thing you learned and write it out as clearly as you can so others can understand the solution. Not only will you help out fellow devs you will also deepen your understanding of the topic and have your own personal reference for later use.
Of course you should do your best to make sure the code in you post is correct, but don’t worry to much about making mistakes. When you share your post someone will correct you if necessary. When that happens it will be a learning opportunity in itself, and you can always update your post.
Everyone takes his/her own path when learning and i hope this article contained one or two notions that can help you on yours. If nothing else please remember this quote:
“Having fun is the best way to learn.” –Albert Einstein
Learning to code will be hard work. But if you want to build u long lasting career as a developer you might as well make sure you are excited for the ride and are having fun.
I would love to hear your thoughts and tips on this topic so lets connect on twitter @Vanaf1979 or Dev.to @Vanaf1979 and let me know what you think.
Thanks for reading