Ultimately we all need to write software in a way that is professional and extensible. This skill is something that will be developed over time; don’t expect to write perfect code on your first attempt, or even your 400th attempt. Constant improvement is the goal. Even professionals do not write perfect code. Constantly improving in a self paced course with minimal feedback can be difficult, but is not impossible.

Focus on the point of the assignment

If the assignment is focusing on Javascript, don’t spend 10 hours on styling. Focus on the task at hand and keep moving through the curriculum. This will keep things fresh and ensure you are constantly learning things rather than tweaking the font size for 2 hours. That doesn’t mean you should totally ignore other tasks around the main task, however. Spend some time styling your projects to some extent; just don’t waste your time on it. You’ll still want to practice other skills as you move through the curriculum so you don’t get rusty. Remember that TOP is meant to constantly build on the previous lessons.

Your approach should be different if you’re using a project as a portfolio piece, however, In that case, spend a good amount of time polishing and making sure it’s your best work. There is more about portfolio pieces in the “Strategically building your portfolio” section.

Run every piece of code you come across

Examples in TOP are meant to be run and played with. Try to pick each example apart yourself and see how it works. Modify it, break it, fix it, run it, bop it. Doing so will help you understand the concepts that are being shared during your readings.

One strategy to doing this effectively is to make assumptions about the code, and then check those assumptions. You should NOT make assumptions that you do not check. If something behaves in a way you do not expect, ensure you spend a bit of time trying to understand why. Avoid rabbit holes: sometimes things are explained later, often even in the next section.

Avoid rabbit holes

It can be tempting to go deep into a subject and feel like you need to become an expert right now. Avoid these feelings. There are a lot of chicken/egg problems in programming where you won’t be able to fully understand something until you understand something else first, but you can’t fully understand that something else without understanding the first thing. Do a bit of research, but if you’re finding yourself following a bunch of links, or on the 3rd page of Google, it may be time to move on from the subject. You can always ask in the chat.

Plan your projects on the macro level, use pseudocode on the micro level

Plan out, avoiding too much detail, how your project will look and function. Try to identify a few major pieces of the application and their interactions and create a wireframe to help with the visual aspect of the app. You should do this with every project; it’ll keep you on track and out of the weeds. It’s a mistake to go into too much detail in your application before writing it, but outlining some of the major systems that you’ll need to build can help in keeping your code organized. Resist the urge to over plan. You cannot predict everything you will run into in your application, and trying to stick to an over-planned project is going to slow you down.

Once you are at the implementation phase, pseudocode your functions before you write them in code. Pseudocode helps you think about a problem separately from thinking about the code. Separating the “problem” from the “code” is an effective strategy for preventing stalls. It also has you get thoughts down if you have to step away unexpectedly. Check this article out for more information: https://www.unf.edu/~broggio/cop2221/2221pseu.htm#:~:text=Pseudocode

Don’t look at solutions until you’ve completed the project

Wanting to look at a solution to get yourself started is a normal inclination, but it’s one that should be resisted. Giving yourself the opportunity to struggle through something will help to build the pathways in your brain that will make problem solving easier in the future. Not allowing those pathways to be built means that more difficult problems (that likely will not have solutions for you to peek at) could become insurmountable. Instead, if you get completely stuck, ask in the Discord chat. People there can help guide you to an answer, rather than give you a solution outright and circumvent a learning moment.

Read Others’ Code

After you’ve completed a project, you should spend a significant amount of time reading others’ code and trying to understand it. Read good code, bad code, and everything in between. Ensure that you are looking at solutions that are NOT the top rated as well. At first it may be difficult to see the difference between good and bad code, but over time you will start to recognize the patterns that are strong, and those that are weak. Compare pieces of code to yours and identify the differences that make something easier or harder to read. Try to understand what was going through someone’s mind while writing the code, and what kinds of trade-offs they made. Make sure you run the code and tweak it and play with it as well, as this is where most of your learning happens.

It is also beneficial to read and review code to the best of your ability in the showcase on the Discord server. You can also spend time discussing why someone decided to do something a certain way.

Refactor your own code

Now that you’ve finished your project and have looked through others’ solutions for a while, spend a bit of time refactoring your own code using the lessons learned. This isn’t a process that has to be exhaustive, but spending time implementing some patterns that you found effective can really help you learn why those patterns were used, or how someone discovered them. Be sure you are not spending too much time on this instead of moving on. Additionally, don’t use anything from someone else’s code if you don’t understand it; either seek to understand it or move on for the time being. You never know when you’ll be asked about it.

One mistake people make is throwing their code out when they find they’re running into difficulty. Instead, try to refactor the code you have into the shape you ideally want it to be. There are times where throwing code out is useful, but that is usually in the beginning sections of TOP, on the very early projects. In general, avoid throwing code out as much as possible.

Be OK with OK

You’re likely new to writing code, so resist the urge to spend too much time trying to write things perfectly. If you have completed the requirements using the topics introduced in the sections prior to a project, you can consider the project complete. Being a perfectionist is a direct route to burnout and potentially to not finishing the course. If you are unsure if your project is complete enough, make sure that you post it in the showcase.

Write your unit tests

When you hit the sections of the curriculum that teach you how to write unit tests, write them. They are important. If you have not reached the point in the curriculum where tests are talked about in detail, remember they are something to spend extra time with. In addition to helping you write cleaner code, having unit tests in your code makes you appear more professional if a potential employer takes a look at your GitHub.

Use Git

Use it, it’s used everywhere, it’s one of the easiest ways to make yourself look like a professional, and makes it very easy to share code when you need help. Spend time writing good commit messages and using it as it’s intended. Read this https://cbea.ms/git-commit and come back to it often. Make sure your projects are pushed to GitHub enabling you to easily share code with helpers in the Discord server, or even to employers. Learning to effectively use git will also make life a lot easier when it comes to experimenting with code (which you should do a lot of).

Strategically building your portfolio

There is no degree or certification for finishing The Odin Project, but it does leave you with the potential for a killer portfolio. There are times when you should spend extra time on a project, and times when you shouldn’t. Not every project should be a portfolio piece.

Foundations isn’t a strong portfolio generator

People tend to spend a lot of time on the first few projects expecting them to be portfolio pieces; the problem with this approach is that you will be building more impressive projects very soon after Foundations. Save your time and energy for those projects. The capstone project for Foundations, however, is worth spending extra time on to ensure you are demonstrating the best of your abilities at that time.

Pick projects you like and use them as portfolio fodder

You will like some projects more than others. Building a portfolio can be a lot more effective if you spend the time on projects you are enjoying. Pick a few projects past Foundations that you really enjoy, go the extra mile, and make them your own.

Always spend extra time on capstone projects

Spend the most time on the final projects for each course. This will ensure you have strong portfolio pieces and will help you understand if you need to go back into the course and refresh.

Use git properly

Git is very underrated among budding developers. Don’t be afraid to experiment on your code; if you’re properly using git, you can easily go back to a working state (which helps immensely with refactoring). Use branches for experiments; if they’re successful, merge them with your main branch, otherwise, toss them out! Writing good commit messages means you will know what you were doing when you come back to the project in 2 weeks. This is a great resource on commit messages: https://cbea.ms/git-commit/.

Next up, Applying to jobs!