How to create a learning plan you can actually stick to

How to create a learning plan you can actually stick to

Attempting to learn something deeply on your own is difficult no matter what the topic is. I mean, there's a reason why we have formal education as an option, right? The guidance is there as an attempt to keep you focused with a structured curriculum approved by educators and experts on the subject. Reviews and tests are thrown in to make sure you really understand the knowledge, but what if that's not a viable path for you? Formal education is ubiquitous, but practically it doesn't work for everyone, so logically those that choose an alternate path choose to teach themselves with all of the vast information out there. The issue with that is there's just way TOO much info out there, and it's free floating without any real cohesive structure.

Obviously there are almost infinite online courses on various subjects to take, but putting courses together in a way that cohesive is still a lot of work. The responsibility of creating that structure to learn rests on the student's shoulder, and that's where I think the student struggles most.

I'd like to give some advice on how I've created and navigated an independent learning curriculum for myself that allowed me to learn software engineering at a level where I've been able to work as a professional, and (in my opinion) be pretty successful at it.

  • I deeply understood the path I wanted to be on and why.

Setting your sights on the path you want to go down and why is so important. You have to have focus as a driving factor to stay disciplined and achieve your goal of learning whatever it is you're setting out to learn. In my case, I knew I wanted to be a software engineer, so I knew that I had to learn about how the web worked internally, HTML, CSS, Javascript, SQL, and a server-side language that allowed me to create and interact with third-party API's.

Map out the topics that are critical to the end goal, and organize them according to what needs to be learned first, with the more complex topics positioned further along your plan. A helpful way to do this is think about each topic as a building block, and visually create a foundation of the basics, moving up into the more complex topics that build off of those fundamentals.

Knowing and understanding what you need to learn is obvious, but be honest with how much work that's going to be and commit to learning it all from the beginning or else you will very easily succumb to obstacles in your way. Constantly remind yourself why you're doing this, and what you need to focus on.

  • I was realistic with how much time I needed to spend daily, weekly, and monthly.

Putting a time dimension on your learning is just as important as understanding what you need to learn. Just like honesty matters with what and why you want to learn something, it matters even more with how much time you can dedicate to it.

For me, I knew that my life changed a lot when I was first learning how to build software, so I knew I could only dedicate an hour a day, four days a week, so I stuck to that until I realized I could squeeze out another 30 minutes a day towards learning, so I bumped it up to an hour and a half a day Monday - Thursday and rested Friday - Sunday. This was a good routine for me until I got my first big boy job, that gave me a more predictable work schedule, which allowed me to dedicate much more time in the evenings to learning. I increased my time to three hours a day for four days a week, and quickly found out that was my limit, so I coasted there until I felt like I needed to pull back.

Life happens, establishing time commitments therefore need to be flexible, but not too flexible to the point where you're changing how much time you spend learning every day, try to re-calibrate every week, that way you set the expectation at the beginning of the week and fulfill your commitment, that will help keep you focused.

  • I set hard monthly goals, but loose yearly goals.

Go big or go home, but don't be hard on yourself if you go home. Learning takes time, and setting goals can be tricky especially when you put a lot of emotion and expectation behind them, but they are necessary to give that much needed validation when we crush them.

I set my goals monthly because I knew that I needed to understand certain things about the web before I took on another subject, for instance I knew that I needed to understand what a DOM was before I even attempted to really work on understanding Javascript, and I needed to really understand HTML and Javascript if I was going to learn React. Knowing which building blocks were needed before others helped me understand what I needed to set my monthly goal at realistically.

My yearly goals were loose, a collection of my monthly goals wrapped up into a nice package, like creating a full stack application, or a command line application that automated something I did at work everyday. A yearly goal should serve to wrap up and include all or most of the hard monthly goals you set, and it doesn't have to be a large project, it just needs to be something that allows you to actively incorporate all or most of your monthly learning's.

I'm just going to go ahead and say it, your monthly goals matter more than the yearly ones, because the near term goals are the ones you can more clearly see and focus on, they shouldn't intimidate you as much as the yearly goals. The monthly goals also build habits and routines much better than yearly goals, proximity to the goal pushes you harder and motivates you a lot more.

This post is already getting pretty long, but I think these 3 points really helped me shape a learning curriculum for myself that allowed me to make meaningful progress to becoming a software engineer. And while the journey was long, it was incredibly worth it because I knew that I had crafted this plan and stuck to it while dealing with outside life occurrences. Remember, you don't have to have life lined up in a certain way to start, you just have to start and deal with life as it comes, good luck.

Thanks for reading

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by JESHOOTS.COM on Unsplash )