Who This Post is For
This is primarily for educators who deal with new programmers regularly, as a way to rethink how typical programming courses are structured. If you are yourself a new or novice programmer, you will likely gain some knowledge by reading through this article and doing some further research of your own into the topics at hand whenever an unfamiliar subject appears.
The Problem
A great number of software development courses out there are aimed at crafting students into the next generation of great web developers. Software engineering is a very well-paid industry, and it makes sense that there are so many people who want to get into these positions. However, many of these courses taught in formal education settings such as high schools or colleges are failing to properly prepare these new programmers for the web-driven ecosystem that they will be thrown into. Software education is stuck in a place where creating an HTTP server and learning graph algorithms are expected to be taught in the same semester, that is, much too late. I’m not arguing against all that Dijkstra stood for, but standing up a server needs to be a 100 level course instead of a 300 level course, if their equivalent use cases in the industry are any kind of indicator.
The Existing Fundamentals
Variables, Comments, Control Statements, Functions, Objects. All of these things are taught right now, and are necessary. Just sprinkle the rest of the subjects within this article in as those things are taught.
Using Libraries
Libraries are the crux of modern development, as shown by the ubiquity of them in languages such as JavaScript and Golang. Learning how to find, manage, and use libraries for your language should be an early lesson, especially for languages where it is not as simple, such as Java.
Python and Go are as simple as it gets for installing packages. After installing the language, each has their own function one can call, accompanied by the name or location of the package. Boom. Downloaded, installed, ready to use. JavaScript has it nearly as simple, just requiring you to install a separate package manager tool such as npm or Yarn before getting into anything.
Both npm and Yarn have their own commands to memorize, so they can be a little more daunting for new developers, who are probably already intimidated by that blinking cursor on a black background that summons The Matrix.
Other languages, like Java, have soooooo many steps involved with just installing a 3rd-party package. Try including a new library through your IDE, such as Eclipse, and you’ll have to go digging through multiple menus just to get it working.
All that to say, teaching these library installation methods for whatever language is being taught is critical. Learning how to find these libraries is critical as well. Installing libraries are basic requirements for all the sections that follow, as it is unlikely that any language’s standard library can handle all of these things in the best way.
Making HTTP Requests and Using API’s
Nearly all frontend or backend code will have to make some kind of web request to an API somewhere. HTTP APIs are the number one citizens of the internet, and ignoring them in programming education isn’t helping anyone. There are plenty of free APIs for learners to play with, including my favorite, the Star Wars API. You can find thousands of public APIs to mess around with at public-apis.io!
Making an HTTP Request is easier in some languages than others. This is also a chance for us to make use of those Libraries we talked about above. JavaScript libraries like Axios make things a bit simpler, while the Golang “net” package is part of the standard library and more than capable of making any kind of HTTP Request out of the box.
Creating A Web Server
Starting a web server that can serve your own responses is the next logical step from the last section. The term “web server” brings up intimidating visions of bearded devops engineers having debates while slinging magical phrases at each other like “jen-too”, “en-gin-ecks”, and “load-bal-an-sir”. In reality, a web server for our purposes is simply any program that can receive and respond to simple HTTP requests.
I would even argue that the modern version of the “Hello World” program for languages should be handling a GET request and returning an HTTP 200 Response with the body “Hello, World!". Point your browser to that localhost address and fire away, refresh for a new response. Much more modern and expected for a budding programmer than having to go into the terminal, with its “old-school” feel.
This concept can even be introduced all the way back with your Existing Fundamentals, as defined a few sections above. Just have their code templates always include code to start a server, and they can do basic variable work inside a handler function.
Many brand-new students begin with a boilerplate file that contains all the required elements: the famous public static void main(string[] args) function for Java comes to mind (I didn’t truly understand what it all meant until I had been in Java classes for 2 years). We can take a similar approach, and add in some function that creates and serves a web browser, with a separate handler function where the student’s code goes. When you send a GET request to the server root, the equivalent of your main function runs like it would have done in a straightforward command line application. The student doesn’t need to know the exact details of what is going on, they just know that //CODE GOES HERE and the results show up when they refresh their browser page.
Serializing and Deserializing Web Data using JSON
JSON is king of the internet. APIs read and return JSON, configuration files are in JSON, NoSQL DBs usually include JSON, and some data just exists as big JSON blobs. Show your students how to read and understand JSON, and even how to edit existing JSON (or write it from scratch if they seem like they can handle it). Put it into some online JSON viewer that can collapse the document into a tree, and let them poke around with the nesting features. Showing off a huge JSON document with hundreds of nested fields could give them an idea of what actual production JSON can look like.
After that, we move into reading JSON. In this, we can either deserialize and access it through dot notation, or we could unmarshal the code into an accompanying object or struct. Both are useful to understand, since sometimes writing the necessary type can be a bit too much if you just need to fetch a single field from the file.
Maybe it makes more sense for some languages to go in the opposite order, first serializing an existing object to JSON and inspecting that. Either way works, just as long as it is understood by the students that this is a two-way street, that anything which was marshaled can be unmarshalled, and vice-versa.
For extra credit, show off some other easily read and consumed file types, like YAML, TOML, or even for a challenge… ⚡ XML ⚡
Writing and Reading From a Database
Databases are ubiquitous. Databases can be complex, but they can also be simple. One might argue that a CSV file can constitute a simple database if it is formatted correctly.
Even starting with a simple SQLite DB is good. SQLite drivers and libraries exist for every language out there, and many free database programs can connect to them (my favorite is DBeaver).
Doing some research beforehand and finding a simple ORM library for your language which doesn’t require too much setup means you don’t have to spend too much time learning any SQL. Everything gets abstracted, which means we can get stuff showing up in a table that much quicker!
You might say to me, “but setting up a MySQL database is too much work for a novice student!". My response is that you don’t require the students to set up the database. You do what any employer will do for a new engineer on the team, you give them credentials to log into a database that is already running. Make a simple account (it could even be a shared account) that has SELECT privileges only. This will be enough to let them poke around with simple SELECTS and JOINS as they get their footing with SQL. When the training wheels are ready to come off, grant them UPDATE and DELETE access, but set up a script to automatically restore the DB and all of its tables to some initial state every 15 minutes or so. Make sure this initial state is seeded with lots of real-looking data that includes many referential IDs so that JOINs can be executed with real results.
Conclusion
I don’t know if this is an instructional post or if it is just a brain dump of all the things my formal education didn’t teach me, but I hope it is helpful!
ERRATA: The Frontend vs Backend vs Full-Stack vs Classical Distinction
Originally this section was included between The Existing Fundamentals and Using Libraries, but it felt a little out of place in this whole piece. I was going to delete it all, but I put it here instead.
Before we go any further, I want to clarify my definitions of the different types of “focuses”, or software and tech-stack specializations, that developers tend to get lumped into. Most developers have heard others use the terms “Frontend”, “Backend”, and “Full-Stack” before, but I am also suggesting a new term: the “Classical” development focus.
These focuses all start with fundamentals, but it is important to realize the distinction early on so one knows what to focus on. A doctor and a mortician both take the same basic anatomy classes, but their end application of the knowledge will be very different.
Frontend: React, JS, Mobile App UI, etc. User Interfaces with GUIs that connect to a server somewhere, typically through HTTP requests, and show data to the user.
Backend: Any kind of web server, NodeJS, .NET/C#, Golang, Flask, anything that exposes an HTTP API or even some RPC protocol such as GRPC. Usually also involves some level of database administration.
Full-Stack: A focus that combines both Frontend and Backend, typically used by someone who really wants a job, or by a company looking for someone who can do two jobs at once.
Classical: Apps that can entirely exist without any external connections (besides those handled by the OS itself), such as a simple Desktop application that functions as a timer, a Mobile App that lets you make stop-motion video, or a command-line tool that operates on files.
All developers can benefit from the “Using Libraries” and “Writing and Reading From a Database” sections, while most Classical developers can get away with not “Making HTTP Requests”. Frontend/Backend devs will certainly need to know “Serializing and Deserializing JSON”, and a good case could be made that Classical developers can gain the benefits of using JSON format for storing data in files over using some more esoteric formats like XML.