Maybe you went the extra mile and coded along with the tutorial to recreate the project, and put it on your portfolio.
By the way, don’t use a line for line tutorial as a portfolio project.
First off, kudos to you for getting started on your developer journey. You should be proud of yourself for actually doing something. There are many who never do, and only talk.
Secondly, you’re now probably at a place where you’re not sure where to go next.
Should you do another tutorial or learn from another course?
Maybe you have the sinking feeling that you don’t really know everything that’s going on within the technology of tutorial that you just watched.
How can you get real experience and confident in your own coding ability?
As someone whose been where you are, I’ll highlight what’s allowed me to keep learning beyond what tutorials and courses could teach. Hopefully the information will fast-track your learning and help you grow as a developer.
From what I’ve experienced personally, being a self-taught developer and learning from tutorials will give you a false sense of confidence in your developer abilities.
Once you try to take what you’ve learned and build a project for yourself or someone else, you’ll realize there are many more moving parts, and the project will take much more time and energy than you thought.
If you haven’t experienced this already, hopefully this post can keep it from happening. It’s not a good feeling.
Coding tutorials are great because they give a predetermined course to follow and you can go from zero to hero quickly. This strength is also their greatest weakness, though, since it cuts out the detailed thought process that goes into deciding between technologies and evaluating best practices.
A tutorial abstracts away all of the documentation reading and searching that goes into learning a new technology.
Fortunately, even small deviations from a tutorial’s predefined path will make the project more realistic and give experience in the hard work that occurs off-screen.
This experience is what’s necessary to truly come into your own as a developer.
There are countless ways to go beyond tutorials and get this experience. Here I’ll give you three such ways. I encourage you to find something that works for you and get your hands dirty.
1. Add extra features to what the tutorial gives
You already have a working project. But what’s missing from it that could make it more useful?
How would you deploy it to a server and make it easy to change the code?
How could you make it accessible to other people to try out?
How could you solve a real world problem that you or someone else has and turn it into a real product?
If you have a To-Do app, for instance, try adding Authentication and user accounts.
Maybe add a Calendar View to it and date tags to each task. Now it’s a Scheduling app.
Maybe add in real-time chat. Now you have a Productivity tool.
If your feeling extra peppy, try adding audio messaging, or short-clip video messaging. This makes your project truly unique, impressive, and portfolio-worthy.
If you’re the entrepreneurial type, try to market and get users for your project. Even if it’s a small amount, having real people pay to use your product transforms your time spent working on it into real work experience, and will make you immediately stand out from the pack.
Even without those extra steps, though, adding extra features will give you a much deeper experience into building a real world app for someone to use.
You’ll gain experience researching different technologies, evaluating different approaches, and learning best practices. You’ll work with the entire stack and boost your confidence in building something from the ground up.
Perhaps most importantly, you will be able to speak confidently about a what you’ll learn in the process.
You’ll be able to say, “This framework is great. I could get up and running in a couple minutes with just a few lines of code.” Or you’ll say, “Yea, I tried that framework and it felt like it was fighting me every step of the way.”
What’s important is that you’ll be able to say more than just, “Oh I’ve heard of that framework. It looks pretty cool.”
This signals to those that you’ll be working with that you’re someone who gets things done, and someone who really knows their stuff.
2. Read the docs
This is one that I still find hard to make a default habit. A lot of the time, reading through documentation can feel like reading a dictionary or a textbook.
But it gives you the confidence of really knowing a technology.
You’ll also feel liberated by it. It’s an amazing feeling to dive deeply into a technology and apply it, without needing a predetermined course to lean on.
Using a framework, based only on its documentation as a reference, gives you the confidence to build anything, whether a trail has been blazed or you’re cutting your own path.
To make this work, you have to write code based on the documentation. Just reading the documentation won’t allow the knowledge to sink in.
Experimenting with the code also gives the deeper knowledge of how easy or challenging the framework is to use when the moving parts are all tied together.
Once you get used to building projects using only documentation (and the occasional StackOverflow or Medium post), you’ll truly feel like you can build anything and learn any technology.
If you’re like me, you’ll need to create a project around the pieces of documentation you want to learn. Applying what you’re learning to a project will help keep you motivated, and give context to what your learning.
Another way to do this is to create a mini-project just to test the small snippets of the documentation. This can be helpful, but I recommend using it around other code to get the full understanding of how you would use it in a real project for a job or client.
Bonus points if you create your own post, video, or podcast audio based on what you learn.
This documents the knowledge for you when you’ve forgotten it 6 months after you’ve learned it, increases your understanding of the concepts by putting them into your own words, and creates a tutorial for someone else to learn from. Warning: consistently creating quality content from the things you learn could accidentally make you a thought leader or subject-matter expert.
3. Create time estimates and time track your learning
A key skill for any developer, inside a company or working for his or her self, is to accurately guess how long something will take to do.
The good news is that this is a skill that can be learned. So why not build the skill while the stakes and expectations are relatively low.
This works as an extra on top of #1 and #2. Before you add a new feature to your project or test out a new concept, make a guess of how long it’ll take.
It helps to break the task into as many smaller pieces as possible and estimate the time needed for each one.
If you have absolutely no clue how long something will take, then put down any number, as long as you put down something, and actually think you could finish it in that time-frame.
If it’s something small, feel free to guess an hour. If it’s a project that uses completely new concepts, feel free to put 100 hours or more. Whatever works. What’s important is to get a baseline, and mentally create time constraints for yourself.
If your doing this for someone else or a job, always go higher than you need. Preferable as far into the future as they’ll accept. It’s better to make them sad at first and then delight them with an early completion, than to make them excited, but ultimately lose their credibility when you can’t hit the deadline.
As someone whose notoriously bad at estimates, and worked on this skill for several years, I always take whatever time I think it’ll reasonably take, multiply by 3 or 4 to account for unknowns, then double it again, just to be safe.
This may sound extreme, but, like most people, my natural tendency is to be overly optimistic in my coding ability. As you get used to creating estimates, you may find that you need to do something similar to protect yourself, from yourself.
Once you have your estimate, build the thing. Remember to time track while you’re building. The more accurate the better. Once you build your project check how accurate your estimate was and why it went over or under. Rinse and repeat until it becomes second nature.
I use Toggl Plan and Toggl Track for estimates and time tracking, but there’s also Harvest, Clickup, and countless other time tracking software.
You can also keep things super simple and use your phone’s stopwatch app, and record all your work times afterward in a notebook, Excel file, or Google Sheet. Whatever works for you.
I recommend not being neurotic about the timer though. If you stop coding to get up and stretch your legs for 5 minutes, you don’t have to stop the timer. Have the mindset of being at an office.
In an office, even when you’re there the whole day, you’re not coding for 8 solid hours. The breaks and stretching are an important part of the coding process, and allow your mind to rest and make connections that’ll improve your code when you get back to the keyboard.
Writing good code requires a great deal of mental energy, making the breaks to recharge that energy a necessary process.
And there you have it.
Mix and match these strategies however helps you learn best.
Keep learning. Put yourself out there. Create cool projects.
Keep raising your expertise and being useful and there’s no way you can lose.
Now get out there and build something.