The Fullstack Development Journey Part III: Tying It All Together

If you haven’t already, it will be helpful to read Part I and Part II of “The Full Stack Development Journey” before diving into this post.

The learning plan outlined in this three-part series follows a path quite opposite from what you find in traditional education: here we are first learning the most practical skills and then moving on to the foundational skills. The idea is that nothing will get your skills quite as polished as actually coding and building apps (no matter how simple they are), so you might as well get started as soon as possible.

For inspiration, check out this developer who made 180 websites in 180 days.

After you’re comfortable with some of this “practical knowledge,” you should start to build a stronger foundation with computer science fundamentals, such as using the terminal, understanding the operating system and application architecture (Big O Notation), and writing good quality code.

The terminal

Once you’re comfortable with the terminal, also known as bash or command prompt, you will be able to execute operations much faster. You should use a terminal to navigate your file structure, open up projects, and run scripts. Also, I recommend doing all of your git operations directly through the terminal: this will force you to truly understand how repos, branches, and forks work.

The operating system

I personally learned just enough about operating systems to gain an immense appreciation for the machine running my code and for the developers who build and maintain it. At the same time, I learned enough to understand that this type of engineering is not for me.

Learning the basics will give you perspective on how processes are run on your computer, and just how abstract a lot of the work you do as a modern software engineer is. In a lot of ways, we are really quite lucky. Another upside to learning about operating systems is that it can give you an idea of what vertical of software engineering you want to go in, such as Android, iOS, or web.

Big O Notation

You’ll often hear developers gripe that Big O is one of those things you spend many hours on in school but never use in real life. This is true in many ways; however, having an understanding of Big O will give you a better intuition in building functions the right way and will serve you well in interviews.

When I was first learning Big O, I remember having a tough time with the fact that it’s all about ‘the proportion of increase’ as you add scale, rather than the absolute increase. Remember, even a function with a poor Big O score can actually perform more quickly than a function with a decent Big O score.

If you ever feel overwhelmed when first learning, it helps to think about the clearest example: O(n) linear time. A function that performs in O(n) is directly proportional to the size input we are dealing with. For example, finding an integer in an unsorted array is linear- if we have 9 integers in our array, it can take us up to the 9th integer in that array of search to find our integer. Always assume the worst-case scenario (that the integer we are trying to find is in the last index in the array).

The other aspect I found counter-productive was that you always should “drop the consonants.”

Consider an example where you need to search for an integer through each of two unsorted arrays, each with a length of 9 like the previous example. In the worst case scenario, you will need to check each index, up until the last index of both those arrays. This will take just about twice as long as checking one array, so this equates to 2(n). However, if asked in an interview what the time complexity is, the correct answer is just O(n), the same as checking one array. But how can this be? It literally takes twice as long! Again, it’s all about the proportional change. Increasing input size from 9 to 900 will go from originally taking 1 millisecond to 100 milliseconds, and likewise, for checking two arrays it will go from taking 2 milliseconds, to 200 (time amounts here solely illustrate purpose).

For more details on Big O, and good interview prep in general, I would recommend the classic Cracking the Coding Interview.

Code quality

A large component of how quality your code will be is simply due to how good of a coder you are. That will primarily come with experience; there’s no way around that. However, there are a few principles that you can follow from day one:

• Legibility over conciseness. Variables should never be single characters. Functions should always be named. Never write code for yourself, always write code assuming someone new is going to be reading it for the first time.
• DRY – Don’t Repeat Yourself. In general, if you ever notice repeating code, it’s a good sign that you need to refactor. DRY will make your code more legible and concise, and it will make it easier to fix bugs. If the same function is written out in many places in your application, a new developer may fix a bug in one of those locations, which doesn’t fix the other portions of the app.
• Comments. If you find yourself rarely leaving comments because you think that your functions are obvious, then you should recognize this as a flaw and make it a point to leave comments (I am guilty of this!). Your function may be clear enough for developers to eventually understand what it does, but that doesn’t mean that comments won’t allow them to more quickly and fluidly pick up on it.

—

This three-part blog series is meant to give you a framework for your fullstack learning journey that is both practical and manageable: something concrete that outlines topics you should tackle and how long you should spend on each. From here, keep in mind that two key skills for success are your own resourcefulness and persistence. The path to fullstack looks different for every person and you ultimately shape what it looks like for you.