Overviews are essential for new programmers December 27, 2021 on Kenneth Dodrill's blog

Background

At my community college, I was in a class for Java. I knew nothing about programming but figured I would try. I tried very hard and managed to get a C (a just-passing grade). In college, I was a computer science major for two semesters. The first semester, I was in a C++ class which went over programming fundamentals like variables, loops, and functions. The second semester I had a data algorithms class. I swear that each time the professor taught us a new algorithm he would announce that we would never use it. I then went on to learn by myself using online classes from Udemy. I learned HTML, CSS, Sass, JavaScript, VueJS, and PHP from Udemy in a year.

I am a very different person than the person I was in college. After the C++ class, I really thought I knew a lot about programming. I was very wrong to think that. I went through many different stages in my “I know a lot about programming” phase, until a couple of years ago when I realized that I actually know very little. The arrogance I had was mostly due to my desire to make something of myself and know everything, but I also believe that the way I was taught programming had something to do with it.

The Java class was taught online by a foreign professor (nobody at our community college taught programming) who had an extremely thick accent and often sent me puzzles by way of email that I had to decipher (some people call these assignments). I had no previous knowledge of programming. The textbook was not beginner-friendly, but I honestly don’t remember too much of it.

The C++ class was in-person at my university. The instructor was excellent - she had the knowledge, taught in a way that was easy to understand, and also cared about her students. I don’t really remember the book at all, but the instructor was so good that I passed with flying colors.

The algorithms class initialized my hatred of how systems within a university work. The professor was not very friendly and would often scoff at questions. Learning effectively was not a priority. It was a very strict “here’s your book, figure it out” type of class. I stopped going after being yelled at by the professor for asking a simple question - “hey I found this other compiler that works on macOS, can I use it?”.

When my interest in programming started, and perhaps during the three first years of learning and doing it, I didn’t care much for the why and how. I cared more about the end result - making code do something neat. I started out with simple code, like in the C++ class or writing HTML for a website, but once I found things like Bootstrap, VueJS, Laravel, etc, I immediately thought of them as the pinnacle of web development. I switched over to using tools that made it easier for beginners to develop a good looking web application. These tools also make projects larger, make projects dependent on many third-party packages, can introduce bugs into the project, and typically define a set of rules or mechanics that are exclusive to themselves.

Problem

The fine details and internal problems facing the industry don’t appear before you until after many years of practicing a craft. It takes a long time until you have the slightest idea of what the hell you’re doing and how incredibly fucked it is. Web development is an extreme example in this case. Being someone who wanted to be a “web designer”, realizing that most jobs were full-stack, and then programming mostly backend web with some front-end design made me realize what an absolute mess it is. There are so many languages, extensions, plugins, scripts, frameworks and libraries that it’s very easy to get lost. It’s so bad that you can guarantee that every job application out there for “web developer” lists entirely different technologies. For someone who was new to the field, I can’t tell you how many times I switched from this framework to that for CSS and JavaScript. Every time I found something new (so maybe twice a week), it would claim that it’s better, faster, smaller than X thing I was currently. Time to change everything over to that new one.

This mindset, where you see new things and switch to them is mostly caused by lack of knowledge. You don’t fully understand the mechanics behind the toolset, so you keep switching to the new fad. Surely enough, that will die and you’ll keep going. Unless you eventually get interested in the mechanics, you will continue to fail to realize that you’re doing a lot of work for very little gain. How can you get someone interested in the mechanics who really doesn’t care? I think the most practical thing to do is to give them an overview.

Proposal

An overview of programming doesn’t mean you list out every single language. It means you take languages that you have experience with (or at least knowledge of) and discuss with your students or peers how they work and the pros and cons of each one. Other people can then throw in their opinions, ideas, and questions. You will also want to take a few languages and discuss the toolset of each, including optional (but popular) frameworks (like Laravel or React). Then, walking through those libraries, tools, and frameworks, discuss how they could impact projects of different scales. Ask things like:

Most students never think of these things until many years into their career. I believe the “fresh out of college programmer wants to come in and change everything” stereotype is largely because they don’t learn these kinds of things in college. Sure, you work with classmates sometimes and deliver a project of some sort. But you aren’t involved with a company.

An overview and discussion of programming languages, frameworks, libraries, tools, and other programs is absolutely crucial for programmers today. I believe it can simplify understanding of the large world of programming and impact students and peers in a way that makes them think more about the inner workings of computers.

If you are a professor at a university, or you’re an instructor at a programming bootcamp, or you are simply teaching yourself, please consider what I have said. You have a duty to provide people (or yourself) with the best knowledge possible, and you are responsible for future programmers. You can provide an overview and let students know how important it is to think about the tools they use, or you can let them run wild. With heavy technologies like Electron, Laravel, and the wide array of JavaScript frameworks, I don’t think running wild is a valid solution.