I asked the above question to my local tech community. The following is a curated list of their answers:
Make a project in GitHub with your tutorial. Don't just use the exact code that is given to you. Tweak it, and see if you can apply all the principles to a different application. This gives you a reference to come back to. You can get creative with how you use it. There can be a branch per language or just a directory per language where you do proper PR per tutorial with commits on specific working versions of the thing at different points in the tutorial.
Remember: you don't have to invent the wheel. Make a project for experience. If that project is another URL shortener, then do it. You can figure out how to achieve the functionality of a tool that you use every day.
After you have finished a tutorial, add more features to it. Think of a problem to solve similar to the tutorial and build that problem.
My advice to avoid becoming trapped by tutorials is to find two tutorials based on a technology or concept you want to learn. Immediate following the tutorials, build something solving a problem with that knowledge or redevelop both tutorials while adding additional features. The purpose is to use the preceding tutorials as a guide, test your knowledge, and to find gaps in what you learned. Use those gaps as guides for the next round of learning.
Keep the end goal in mind while building a tutorial and then add it in your personal portfolio.
First thing before I start a tutorial I have to have a result in mind. These days I never start a tutorial because it's neat or someone said it's a hot technology nor anything like that. I've had to completely rid myself of running after every shiny thing which if you look at my 100 Udemy courses it's hard to tell but yeah, have a result in mind. "When I finish this, I can go back and add this piece to my old portfolio" . "When I finish this, I can build X that will be great to talk about in my next interview. "When I finish this"..... You get the point.
Don't worry about the listed time
The next thing is I've had to rid myself of paying any attention to the time listed on a course. Or if I do pay attention, I have to put it in "Lawrence" context. Example, let's say I'm starting a course and it's says 28 hours. That's typically 28 hours of content. I double it. Every time, I double it because for me to deep dive, to practice spaced repetition, to build things along the way, it will at minimum take me twice the time listed to get through it and NOT have to go back to it. This is critical. I've spent way too much time in my early learning days redoing the same content over and over. What that means is I didn't give it enough time to sink down deep into the gray matter. Take your time. Read all the things, do all the things, make no attempt to rush through with any regard to the listed time.
Spaced repetitions and special ability to recall it without looking at material
I mentioned spaced repetition but didn't mention the "how". Anki cards are flexible enough to learn definitions of things or even code syntax snippets. I've used the free version and gotten what I needed from it.
- After you have finished a tutorial, add it to GitHub, and used the lessons learned in another application.
- You don't have to reinvent the wheel, make a project just for the experience.
- After you have finished a tutorial, add more features to it.
- Some great tutorials is Front-end Masters and "You don't know JS" by Kyle Simpson. For React, anything produce by Kent Dodds.
- Keep the end goal in mind while building a tutorial and then add it in your personal portfolio.
- Don't worry about the listed time. Take all the time you need to learn what the tutorial is teaching.
- Spaced repetitions and special ability to recall it without looking at material. Focus on practicing what you have learned by immediately replicating the material.