Why doing projects is not the best way to learn to program…
…and what to do instead
We’re hearing it a lot. It’s probably one of the first pieces of advice you will get when starting your journey as a software developer. “Just pick a project and do it. You will learn things along the way”-they say- “Then you can put it in your portfolio!”.
This is understandable. The hype for project-based learning is huge as more and more schools worldwide adopt this student-centric approach claiming its countless benefits such as better engagement, improvement in problem-solving and critical thinking skills, and more. Don’t get me wrong, as someone who comes from an educational background and who taught in pre-school that based their curriculums almost entirely on project-based learning, I can see and appreciate its advantages. However, I’m able to see that it is not a holy grail, one fit-all method. Certainly when it comes to learning or self-teaching to become a software developer. There are certain dangers that come with focusing entirely on doing projects as the only way of learning, especially when we treat them as something we want to show to future employees. And here are some of them:
You Fight the Monster Before Learning to Hold a Sword
The time has come and you finally know how to write a for loop. You feel so excited about it and you feel ready to jump in and do your first project. You are not sure what it can be, so you search online and ask around. ‘Do something simple at first” — You hear — “Do a Tetris game!”. That’s it! You’ve played that game so many times! It’s no “World of Warcraft”, how tough can that be? And this will look so great on your portfolio! So you sit in front of your computer, you open VSCode and you create a file called tetris.js. You maybe even create a git repo and push it to GitHub — the world’s biggest repository of unfinished programs.
Forgotten, abandoned, passed into oblivion projects of those of us who truly believed that they are ready to conquer the beast but got slaughtered with no mercy at the first attempt of writing the function declaration. You sit in front of the screen and your mind goes blank. “Where do I start?” -you ask yourself. “Where do I put all those if statements that I’ve learned from ‘JS in 5 minutes or less’ Udemy course?”. You go to YouTube and search for “How to code Tetris Game for Dummies”. You watch the tutorial. You understand nothing. You copy and paste… Is it really your project if you copied everything from the tutorial? You decide that it’s not and you don’t push the final code to GitHub. But you don’t remove the repo because you don’t want to lose the precious green contribution square. Your project dies out just as your excitement.
We might laugh now but let’s be honest, we’ve all been there! We learn a concept and we immediately search for ways to create something that may be of value for someone. We all have this vision that our Tetris whenever, it’s done, will be one of the most viewed websites just after Google and played by generations.
The truth is that it’s very difficult to be self-aware enough to realize what projects we actually are able to make and finish. Especially if it comes to code, something that may appear very simple, in reality, hides a tremendous amount of complexity and requires a great deal of both skills and effort. There are no shortcuts to get those skills other than doing a massive amount of exercises, starting from really small and fundamental concepts, leading our way gradually and steadily towards more advanced subjects. There is really no flashy learning technique that will magically teleport you from being a programming novice to a professional software engineer in 2 weeks (or less). It’s time to reconcile with the fact that it may take a while before you produce something that you can actually put in your portfolio. No, really. Just let it go!
You Kiss the Frog When it’s Already Dead
This takes us to the next point. Let’s say you are really stubborn. You don’t give up like most people, you persevere and you are determined to keep those git commits going and finish your Tetris. And you do. You make a beautiful, shiny front-end with flashing buttons and kitschy chiptune background music. You spend a lot of time making it look perfect so that those millions of fans who will play it have nothing to complain about.
You look at your program with pride. Then it hits you. Your code is a mess. There are so many dependencies between the functions that it’s really hard to wrap your head around what is what. It’s no problem. You jump in and refactor. And there is also this new library called “A shiny library that makes coding Tetris a blast” that you’ve heard about and you think that it would look good in a portfolio. So you implement some of those methods too. Then you find out that there is something like OOP and you think you should probably code your game using that. After the neverending process of changes and improvements, you decide that you are finally done.
It’s all great, except it took you four months to finish. Well… You were supposed to already be on the job hunt by that time according to your master plan. Instead, you became a master in coding a Tetris game using a library, which during this time became overshadowed by another one called “An even more shiny library that makes coding Tetris a piece of a cake”. You have however no idea how you would actually build, let's say a snake game, not to mention a web app, that you ideally would like to develop in the future. Also, you’ve just read an article from this famous software engineer claiming that “putting a Tetris game on your portfolio is the worst idea ever and no one should ever do that”.
Doing a project takes time. After all, it took you four-month to finish this one and while you were learning so much during this process, there were always new things to add and improve. Especially in the beginning, by the time you finish one project, you look at it and you cannot believe how rubbish your code is. You could have done so much better if you just knew what you know now, couldn’t you?
The thing is, and most aspiring ‘bootcampers’ will lynch me for that, becoming a software developer takes time. A lot of time. Not three months kind of a time. It takes so much time, that before you are finished (actually you never are truly finished) all the things you have learned may be obsolete. Instead of learning specific technologies that come and go, it’s better to take time to master the fundamentals that don’t get outdated and to focus on developing a better understanding of how things work. After all, it’s more useful to be able to program any game and not only Tetris.
You Choose a Pigeon Over an Ugly Duckling
Ok. You’ve learned your lesson. No more long projects with fancy libraries and frameworks. You decide to do some simple, exercise projects with vanilla JS and you come to peace with the idea that it will take some time before you can produce something that you are not afraid to show to anyone. There will be no millions playing your Tetris, and it’s ok.
You leave the book and you decide that it doesn’t make sense and that it’s so hard to focus on and understand. You go on YouTube and watch a tutorial that presents a concept and jump right away into using it in practice. You watch it, you decide that you kind of get it. You learn a couple of things like that while the book gets eaten by bookworms. You go through some online tutorials because you decide that “this is the way you learn best” and you jump into projects again. After all, learning should be fun, right? That’s what it was at school as you went to one of those fancy high schools driven by a project-based approach, where all is fascinating and engaging and where new technologies were used for the school material to compete for the rest of the attention that teenagers have left after scrolling through hundreds of 30-second videos on YouTube shorts.
You finally do it. Tutorials help you go through difficult concepts well enough to develop some projects and put them on your portfolio. It took a while to get where you are but after some months basically scrolling through all job ads on LinkedIn and sending more than 1000 CVs you finally get an interview for a small company doing software for other small companies that do services for small companies. You are not sure how but you finally get an offer and you accept the job.
You are excited about your first day at your new job. You are finally there! You are a software developer just as you wanted. You must have done everything right this time. On your first day, you get a list of things to do. You have to read through the code… You have to read the documentation… You have to read… Oh and there is also this new framework that you will work with, that is so new that there are even no YouTube tutorials or Udemy courses on yet, so you will have to read through that documentation and learn it from the e-book they gave you. No videos, no funny games to practice the concepts, no time for doing projects. Just you, the book, and your 3 minutes and 45 seconds attention span.