Here’s what I learned after my first time building a full-stack web app without following a code-along tutorial
Do you remember what it felt like the first time you rode a bike without training wheels on? It feels slow at first. You’re falling down a lot and you’re struggling to gain your balance.
Whenever you’re learning something new in programming, it’s like learning to ride a bike all over again. You have your training wheels on, which usually involves following someone code and repeating after that person in your own code editor. This is a such common experience in the programming world, that there’s even a word for it — “code-along” tutorials.
Following code-along tutorials is a great way to jumpstart your programming journey. They help give you an overview of what you can do with the language or frameworks they talk about, and after going through them, often, you would have a finished product in your hands, like as a to-do list or a blog app.
At some point though, the training wheels must come off, and you actually have to start making your own projects with that tool. This is where it gets complicated (not that it wasn’t complicated following all those tutorials). How do you know if you’re ready? What app should you build? Should you start with frontend or backend? Does it need an authentication system? Where should you deploy it after? Starting a new programming project involves asking a lot of questions like these, and the benefit of code-along tutorials is that they take care of all your questions. However, to become a good developer, you have to learn how to answer these questions on your own.
Two months ago, I challenged myself to finish a web development project without following a code-along tutorial. I wanted to become more confident in developing on my own and hopefully develop more apps in the future.
Disclaimer: Although I didn’t follow a code-along tutorial. I didn’t restrict myself from looking at the documentation of the tools I used or going to Stack Overflow or using Google whenever I have a question. In real life, experienced programmers also rely on these resources when developing apps. By code-along tutorials, I meant tutorials which guide you in doing a programming project from start to finish.
For this challenge, I just chose a really simple and unoriginal idea. I actually crowdsourced it online and this is what I got. It is from MWins’s list of project ideas on GitHub. It is for a movie ranking app.
I finalized the idea with the following set of features.
- Users can create multiple lists of movies
- Users can delete list.
- Users can rank the movies in order of their preferences.
- Users can delete movies in the list.
- Users can add titles to list.
- Users can search for the movie using search bar.
- Users can view all the list created in a dashboard.
The finished app has a separate frontend and backend. For the backend, I used Django to render the server and Django REST framework library to create an API on top of it. For the frontend, I used React to create the user interface and CSS to style it. To connect the two, I added CORS headers to Django and used axios in React to communicate with it. The database is stored locally using SQLite during development and on the server using PostgreSQL during production.
I used Heroku to deploy my Django backend API and Vercel for React frontend. You can check both out with the following links:
The total project took around 10 days to complete. On the average, I think I spent around 3–4 hours a day working on this.
What I Learned
Develop Feature First
One of the first questions I had when I was starting the project is if I should work on the frontend or backend first. After searching for suggestions online, I ultimately decided on developing on a per feature basis. Instead of finishing either one first, I would work on the frontend and backend side by side for each feature. I liked this approach best because it made it easier to create a schedule based on the features I needed to accomplish on a certain date. I also liked how I could gradually see my app come alive with each accomplished feature.
Write More Tests
Before I worked on the project, I’m glad that one of the code-along tutorials I read was Percival’s Obey The Testing Goat, which taught me about functional and unit testing. I used what I learned there to create the tests for this project, and it helped to automate having to check whether a certain function worked or not. For example, to test the feature of searching a movie, I didn’t have to go through the trouble of opening the app, locating the text box, writing some words on it to determine whether or not it would trigger the search results to show. For this project, I used selenium to do that for me. Next time though, I would like to explore React’s testing framework as well. All my test were written purely in Python and it had limitations. Initially, I didn’t think much in testing my user interface and it was tricky managing when a component would appear and disappear on the screen.
Read Library Documentation and Source Code
For the project, most of the code I’d written is based on another library’s syntax. To get most out of the library I was using, I referred to it’s documentation and source code to understand what was going on under the hood. Although most often you could get away with finishing an application just using the documentation, reading the source code gives you more flexibility. This came in handy when I was designing the logic behind the ranking system of the app.
You Aren’t Going To Need It
Another concept I learned from Obey The Testing Goat that I applied to the project is the concept of YAGNI or You Aren’t Going To Need It. Initially, I was deciding whether to include a page where users would be brought to if ever they couldn’t find the movie that they wanted in the search results. The current search results only queried the first page search results from the API. If I included this option, I would have to implement a way to get the other page results as well for it to have added value to the app. I didn’t think it was necessary to include this feature for now. It was something cool to have but, ultimately, the search function wasn’t the main feature of the app — it was to create lists of movies. If ever I do want to add that feature in the future, I could, but for now I prioritized the other features I’d written above. This help kept me focus on what was important for the app.
You Probably Don’t Need a CSS Framework
Most often code-along tutorials would lead you to use Bootstrap at some point. Bootstrap is great for quickly adding read-to-use components to your site, and at first I also planned on using Bootstrap. They provide very clear documentation and I could have easily imported their library. The truth is I didn’t think I needed to use Bootstrap for my small project. I was only hesitant to go Vanilla CSS because I’m not really confident in my design skills. I told myself to try using CSS first and if it didn’t work out, I could always use Bootstrap. I’m glad that I trusted myself because the finished app turned out better than expected. I had help from the online color scheme generator Coolors, and the rest just fell into place through experimentation. Don’t knock CSS till you try it!
Spend Time to Learn Git
Before the project, I only knew 3 git commands: “git status”, “git add”, and “git commit”. After coding every feature, I would execute these 3 commands. At one point, I had to checkout a previous commit in my frontend. When I did this, I didn’t know what a detached HEAD was and that I was now working on one. I just kept continuing executing “git commit”, not knowing that I needed to save the changes I made to a new branch. This would soon come back to haunt me when it came time to push it to Github. I was able to push my backend seamlessly but encountered a “fatal: Invalid branch name” error in my frontend.
When I searched online for a solution, I didn’t bother reading the whole article, I just executed the first command offered to me “git checkout master”. Big mistake. You don’t know frustrating to see all the changes that I made suddenly disappear from your working files, and since I hadn’t save the changes I made to a new branch yet. I couldn’t see it in “git branch” or “git log”. I wanted to give up at that point. I didn’t know if I would have to code it all over again or if I should just move on to a new project. I frantically searched Stack Overflow for a way to undo what I had done. I learned about commit hashes in the process and that as long you were commit-ing your changes, it was still available somewhere in your .git. I retraced “git log” and “git reflog” to find the commit hash of the changes I made. Luckily, I found it and I checked it out and got all my files back. I quickly saved it to a new branch and merged it to my master branch then and there. It was such a scary experience, but I learned a lot from it, which brings me to my next point.
Learn by Making Mistakes
Although I do not wish you to make the same mistake I did, there are just some things which you learn best after not doing it right the first time. Don’t prevent yourself from writing imperfect code. You can always refactor it after. Programming is not about getting it right the first time. Most of the time, it is a lot of trial and error. That is normal.
Deploying is Not That Scary
I think most beginner developers find deploying their projects a daunting task. Before this project, I was one of them too. When you read online, there’s all these steps you have to follow. If I am being honest, I don’t think I followed all the step. I just wanted to see my project live. When I did that, I realized that it wasn’t as hard as I thought it would be. Heroku was really easy to use as well as Vercel. It just took a couple of steps. Although, it did not come without problems — Initially, I wanted to put both frontend and backend to Heroku, but I couldn’t get my React app working on Heroku, so I opted for Vercel instead. I think, generally, most tools nowadays make it easy for you to deploy your projects. Don’t be scared to try deploying your project. The reward of seeing your it live is worth it.
When you’re learning to program, you are basically teaching yourself how to build ideas. It’s easy to find yourself stuck while starting a new project, but take it slow and keep at it. The challenges we give to ourselves, even the small ones (like this projects) can end up teaching us a lot. After this project, I am more motivate to build more ideas. I might do a few more simple ones before I try working on hard ones, and that’s okay — progress over perfection. I hope to see you build your own ideas too.
Cheers! Code on!