Fundamentals Of Programming
Sandi Loisel
Computer programming (often shortened to programming) is a process that leads from an original formulation of a computing problem to executable computer programs. Programming involves activities such as analysis, developing understanding, generating algorithms, verification of requirements of algorithms including their correctness and resources consumption, and implementation (commonly referred to as coding) of algorithms in a target programming language.[1]
This course comprises nine lessons on the fundamentals of computer programming. Each lesson includes a combination of Wikibooks, Wikipedia, and Internet-based readings, YouTube videos, and hands-on, interactive learning activities. Examples are provided using flowcharts, pseudocode, and a wide variety of computer programming languages.
This is a second-semester, college-level course. Learners should already be familiar with introductory computer concepts and have advanced or proficient-level computer skills. Learners need to have access to the internet readily available to them.
I've been meaning to write an article about computer science fundamentals and how it can improve a programmer's career for a long time, but I always had trouble finding a good way of introducing this topic. The reason I'd like to talk about this is first that, well, I really like this field and I feel that most of my programming ability today is a result of having studied this, but also because I feel like there's a lot of misinformation around this topic and I've been hoping I could address that in a way that could be convincing even for those who can't stand hearing the word "algorithms" anymore.
The context, for those who are unaware, is that part of the tech community hates this topic so much that they actively fight against it, particularly due to how the interview process of large companies like Google are shaped. When regular-sized companies hire programmers, they usually look for people to perform a specific role on a specific platform (such as iOS development). In this case, it's very common for the interview processes to focus on the practical aspects of these platforms, such as understanding how the platform works at a high-level, the details of certain APIs, and the person's overall ability to work with that platform's tooling.
Traditional large companies, however, focus more on the theory of computer science, asking questions not about what you can do in a specific platform, but about your understanding of the building blocks that allow such platforms to exist in the first place. You are tested for your understanding of the functionality of basic data structures, your knowledge of the fundamental algorithms that accompany said data structures, your ability to explain the functionality and impact of your code in a very low-level/theoretical way (often in the shape of a programming puzzle), and sometimes even your knowledge of your software's underlying layers, such as compilers. The theory we're talking about here is composed of many major fields, but is usually referred to as Computer Science Fundamentals.
The thing though is that these companies tend to run puzzles so hard that even talented engineers would have trouble answering them without preparing in advance. They require you to have extensive knowledge of very specific pieces of theory that are usually unrelated to the position being interviewed for, and while people used to be unbothered by this in a past where we had way fewer layers of abstractions and that the only way you could learn engineering was by going to a traditional college that would require you to study those concepts, in today's modern world where most programmers tend to be self-taught and work with platforms that are extremely abstracted (e.g iOS/Android development) this practice became considered unfair and outdated, and is now heavily frowned upon by the tech community. This interviewing practice is referred to by the community as "LeetCode", in reference to the popular interview training website with the same name where most of these questions tend to be pulled from.
Yes, I hate LeetCode interviews as much as everyone else. But the problem is that the community misplaces this hate in dangerous ways. The negativity around this interview format became so large that developers today now feel resentment towards the theory itself, even though it has nothing do with with the obscure programming puzzles that these companies employ! To this day this misunderstanding has been causing both beginners and experts to actively avoid learning the theory, which in my opinion is a big career mistake I have seen countless developers regret in the long run.
I believe it's critical for us to separate our disdain for those outdated interview practices from the theory itself, so I've written this article as an attempt to fix this misunderstanding and to prevent further developers from making the mistake of skipping learning the fundamentals.
To do this, I'd like to show you how the theory is used in practice using an analogy, and follow-up by explaining why large companies care about CS fundamentals (despite their outdated interview practices). I hope that this will give you the tools to not only understand how the theory can make you a better programmer, but also to help you determine if this is something you should be studying right now to achieve your personal goals.
This is not an attempt to convince you that LeetCode interviews are a good thing; much to the contrary. At the end, we'll wrap-up by using what we learned to see how we can design better interview processes.
I can see why someone would have these views. If you have never been introduced to this field, it can definitely look like it's all about pieces of obscure knowledge that aren't relevant to the actual role. They are called fundamentals, but you can learn how to code without them. Are they really that fundamental?
To explain this, I would like to draw an analogy with a person's journey of learning a musical instrument. This is because musical instruments are accompanied by music theory, and I find the relation between them to be very similar to the one between programming and CS fundamentals.
Music theory defines the fundamentals of music, providing a theoretical explanation of what things like notes, chords, and scales are, how to find and manipulate them in a particular instrument, and how it all ties together in the songs you hear today.
A person who wants to learn an instrument like the electric guitar will be introduced to the concept of music theory, but also be told that they don't really need to learn it to learn how to play the guitar. Although they will need to learn some of the basics in order to be able to use the instrument, they can generally skip the deeper details if the student isn't interested in that. The student will be perfectly capable to learn how to play their favorite songs, and maybe even play in a cover band with their friends. You may notice that this is very similar to what we see in programming today.
But ask expert musicians what they think of this, and most would say that skipping this knowledge is a mistake the student will regret in the long run. How can this be? If you can learn how to play the guitar without the theory, why would they regret it?
The problem is not that the lack of it prevents you from learning something, but that the student will be making their life harder for no good reason. Although they can learn how to play the instrument, chances are that they won't really have any idea of what they're doing in practice, which will prove to be a constant obstacle in that student's journey.
If the student were to decide to dedicate some time to understand the fundamentals of music, they would greatly simplify their journey, because people who learn music theory are better musicians overall. Even if the student might not be interested in composing their own songs, their understanding of music would greatly speed-up their learning process in general. Why? Because they would understand what they're doing. They will have a much easier time learning how to play new songs and figuring out what they need to do improve further, because they wouldn't require as much external help as someone who didn't study the theory.
Another benefit of learning music theory is that it applies to every instrument. People who understand music theory usually have a much easier time mastering different instruments because most of their knowledge from previous instruments can be applied to new ones. All they need to learn is how the instrument is played.
I find that this analogy translates perfectly to programming and CS fundamentals. Just like the musician that knows music theory is generally better at playing an instrument, the programmer that knows CS fundamentals is generally better at coding.
Many developers today believe that the purpose of theory is to teach you extremely specific structures and techniques that are pointless for most roles. But again, this is a misunderstanding caused by the outdated interview practices. The theory has nothing to do with that!
Similarly to the music example, the purpose of programming theory is simply to allow you to understand your code. People don't study data structures and algorithms so that they can go and start literally adding them to their projects like those outdated interview practices might imply; they do it because most of the problems we face today are essentially more abstracted versions of those same fundamental concepts, and being able to notice that can provide you with many insights on how your code should be designed. Developers who know theory may not necessarily make less mistakes, but they will have a much easier time finding solutions to difficult problems and determining what they need to study to improve at their work. Just like in the musician's example.
c80f0f1006