What should we teach the juniors?

If you are a novice this post outlines your learning roadmap. If you're the senior carefully think if you're already transferring those concepts to junior devs.

I've been reading Chris Ferdinandi's newsletter Go Make Things for about two years now. I don't remember how I came across it, but I'm glad I did.

In one of his emails, he talks about his struggle off figuring out what to teach the junior developers. What courses/material to develop?

I thought well:

We need developers that can write simpler, reliable software.

Unless we invest time in juniors and teach them how to write:

• production-ready reliable code,
• simple code that's not a superposition of 100 libraries,

we'll end up in a few years in an even deeper mess than we are in right now.

We're all script kiddies

These days every kid with a laptop and five minutes calls himself a software developer. But most of us are script kiddies. We copy-paste stuff together and google until we get a working product.

So to be quite honest I'm surprised that anything works in the software world, and we don't have more accidents like ESA's Schiaparelli crash landing on Mars in 2016 . Here I quote:

Thrusters, designed to decelerate the craft for 30 seconds until it was metres off the ground, engaged for only around 3 seconds before they were commanded to switch off because the lander's computer thought it was on the ground.

As far as I recall from a talk of an ESA engineer at Swiss Python Summit 2018:

• Upon descent, the lander with parachute opened, started to swing back and forth.
• At some point, the lander's height sensor recorded a negative height.
• Craft though it already landed and turned off the descend thrusters.
• Boom.

Software developers didn't predict that edge case and one wrong if statement (for illustration, not actual code):

if (h <=0):
  stop_thrusters(...)

caused a multi-million-dollar probe to crash. The bug crept into the production code despite numerous tests, multiple people cross-checking the code.

Don't get me started on services like GitLab going down for an hour:

Writing high-quality software that doesn't crash is hard. It takes a lot of time, patience and developer experience. And even then, things go wrong.

Yet most people writing software (including me) write crappy code. Mostly because of the lack of proper software education, but also because the web is just full of crappy software, crappy examples and lousy advice. One of the few cases where I wish that the internet had a content quality police.

As a result, most of the code out there is a mess. As always, Xkcd explains it better than I ever could:

I learned the above lessons the hard way. Through my own sweat, tears and sleepless nights.

My informal coding path

I'm a physicist, and I started my coding path in 2010 with some copy-pasting of HTML and CSS in high school, but it wasn't until university when we started with C, then:

• Mathematica
• Latex
• C++
• bash
• python
• JS
• ...

Most of my work involves data analysis, number crunching on supercomputers, occasional GUI in the web browser, and web development for my personal web sites like this one and the other blog Life experiment .

I'm not an expert in any, but I know a thing or two. Despite all my experience, I often struggle. The web development part of my journey nicely illustrates that.

Trust me when I say that web development is a mess and hard to understand. I do physics for a living and still, find web development a tough nut to crack. This web development mess we live in is one of the primary reasons why I started writing this page called Minimalistic software .

When I finally started digging into web development, the HTML + CSS + JS was an extremely wired concept to me. GUI programming and UI design are vastly different in methodology than languages like C, C++, python where I learned my ropes in coding.

It wasn't that much the JavaScript that confused me, but the added option of manipulating HTML elements (DOM) and running JS in the web browser.

Let me illustrate.

How do I print the output of my variables?

In pretty much every language I know you would print a variable in one line:

• bash run:

echo "Hello world!"

• C run:

printf("Hello world!")

• python run:

print("Hello world!")

• C++ run:

std::cout << "Hello world!" << std::endl;

• Mathematica run:

Print["Hello world!"]

But in JS you need to do:

and then go into the web browser console to see the output. Not the command line.

Sure it makes complete sense, but it took me almost two years to figure out that I need to place the consol.log inside the HTML script tags. Keep in mind that I was working with pointers and memory management in C++ for breakfast, lunch and dinner at that point.

But every damn JS tutorial just throws :

console.log("Hello world!");

at you. Huh. Go figure.

If only someone told me the above and things like:

• HTML is for structure of your document/web page.
• CSS is here to make your web page look pretty or ugly. It defines the style.
• JS allows you to change your web site when a user does something. Clicks a button, for example.
• You don't need node.js, jquery, ...

But nooo. Nobody will teach you the simple things. Most will preach how you should learn node.js use jquery or React, Angular, or insert buzzword here.

It took me a while to realize that I didn't need to spend countless hours learning how all those libraries work, but that I could just use plain JS (or any other plain language) for most of my needs.

The day I discovered the vanilla keyword

... a whole new world opened up. I mean, I always hated vanilla Ice cream but vanilla code ... That was something else 🙂

C++ made sense for me because it's low level and if you don't understand the basics, you can't do shit. But in CSS, JS you can do so much without having a clue what you're doing.

So once I started googling things with:

How to * with vanilla python/JS/HTML?

I realized that most problems could be solved with a few lines of simple code and not a goddam library. But most of the blog posts/courses/tutorials teach how to use tool X from big company Y.

Now I want to outline based on my own experience the manifesto for what we should teach. I hope I convinced you by now that I know a thing or two about software.

What should we teach?

We need to teach the juniors what's under the hood of the car. They should know what's inside the car, how the engine works.

Not how to use tools (beyond basics), not the nitty-gritty details of writing whatever the fastest sorting algorithm in the world is. We should teach the craft of writing good simple code that doesn't crash. And that's hard.

Too few programmes are systematic and rather focus on technical puzzles instead of facing the real issue. Software is meant to solve a real-world issue. Yet all the time we end up with:

So do your homework and:

• 1.) Nail down what your problem is. In technical and non-technical terms.
• 2.) Sketch out your code. What technical debt you really need (which shitty libraries you have to live with).
• 3.) Do the first prototype and figure out what it's missing.
• 4.) Fix the prototype and improve it based on what's really needed.

• 5.) Repeat number 4.) until software stops crashing (so forever).

Figuring out how to follow the above process is hard. It does take the experience to execute it properly, but it helps a hell of a lot if someone teaches you a few tricks.

Now we come to the point where a large part of developers will disagree with me. As a physicist, I was trained to question everything. I'll dig and dig until I get the bigger picture and figure out how pieces fit together.

So let's invest more effort into ensuring that juniors have the bird's-eye view of the whole filed.

We should cover the full stack but not expect anyone to be a full stack developer.

We should help juniors construct a table of content/map in their head. Help them understand where they can find the best tool, why to use it and when they should look into a specific corner of the web. Truth be told the amount of information out there is too vast for any other approach anyway.

Cover full stack or not?

Yes!!

I had the privilege of working with a few less experienced/beginner coders. And I realized that it's far more essential to teach them how to build a few integrated HTML + JS + CSS projects then first teach them everything about HTML, JS, CSS and then assume they'll connect the building blocks. They won't.

Yes, cover all the core technologies from front-end (HTML, CSS, JS) to back-end (git, Linux, bash, python server, ...). Not in-depth, but every developer, in my opinion, should have a basic knowledge of how things fit together.

For example, during the first COVID-19 outburst in March 2020, we were building a web site for information sharing related to the COVID-19 crisis, and a less experienced developer joined our team. Her first task involved to fiddle with: HTML, CSS, python, git, bash, package manager, GitLab, .... She had basic experience with python and had seen git at that point.

Her task was to slightly update the UI of the admin dashboard login. She had to use a couple of CSS classes and throw some old HTML out. That's it. But it allowed us to expose the junior developer to the whole stack. She was able to make a lot of connections about the entire software landscape. None of that would have happened in a vacuum.

It's not about juniors becoming experts in everything. I mean, no one can be an expert in everything. But it's about building a mind map of what you don't know that you don't know.

But we can't teach all this? It takes years to grasp all those concepts. True. But that's doesn't mean we shouldn't try.

The more detailed Curriculum

Most crash courses teach how to use tool A, B, ... how to write algorithm X, Y, Z, ... But software development isn't just about writing code in one language. How command-line, operating system, web browser, version control, data structures, databases, ... work are all concepts most programmers never hear about during their training but need to learn on the job. Some pick it up, and most stay the script kiddies.

The fact is that a large proportion of people in software never received any proper software training. They are either self-taught or have a non-CS engineering degree. Yet they write a lot of very crucial business code. However, it's important to note that this varies from country to country.

So where do I see the most significant knowledge gap? In things like:

• How HTTP works? How do other communication protocols work?
• How to write an HTTP server from scratch?
• How to write a JS, CSS framework from scratch?
• How password encryption should be performed?
• How command line works?
• How to write reliable code?
• How to write a command-line tool from scratch?
• How Linux works?
• How the web works? DNS, IP-s...
• How to build your own google analytics/music player/....?
• (For ML folks) How a minimizer works? How Gaussian Processes work?
• ...

Surprisingly, if you google how to do the above things, you'll mostly hit dead ends.

I'm not saying that you should always reinvent solutions to above "problems". But figure out how things are done then use the tool that fits your problem. I mean, it would be kind of dumb not to use the open-source projects others wrote before you.

Remember: A fancy open-source tool from FANG company is not always the answer.

So if you are a junior bug the experts to explain to you how things work. If you're the expert: start writing simple, minimalistic tutorials for god sake.

Libraries

OK, if it's not apparent by now, I'll try to avoid using libraries as much as I can. OK, I hate them. However, I love sifting through the library code to figure out how specific technical details are solved.

Libraries have been the source of most of my problems, pain and bugs. I'm no fan of libraries because I have too many bad experiences already. But as I said, if a library fit's your pattern, use it.

But don't go down the dependency rabbit hole:

During my undergrad, I was working on a larger Physics experiment in Japan. As an enthusiastic student, I wanted to compile the collaboration software on my Mac. How hard could it be right?

Well, official support was only for Linux, and it took the whole software a few hours to compile from scratch on a reasonably powerful PC. How? Well, we used around 100 dependencies ... I gave up compiling the software after two days.

Oh, and I had to fix my code every few weeks because some other developer changed something in his part of the code. We had tests, but tests can't catch everything.

If you have the luxury, try writing simple solutions on your own. In most cases, it will make your life way simpler.

Now what?

Maybe it's just that because I started coding on the lower end of the spectrum C, C++, ..., that Web Development confused me so much. I know that most people start with JavaScript and then some venture out of it. But no matter where developers start their coding journey, they should become:

Developers that can build reliable, world-class software.

Not script kiddies. I know that a proportion of people will stay in the second camp. But if we can get a few more developers to the first camp, the real world and the software world will be a much much happier place.

Knowing the basics of computer languages is easy. Piecing things into solutions that work is another story.

If you know basic HTML, CSS, JS, you can create a simple website.

But before you can run a page that will gather user information, do something when users interact with your page, withstand high traffic, make money. That's another story.

There's a grand canyon between the basic web site and the money-making software. No wonder it took me 10 years to get a basic grasp of the whole field. Hopefully, I can help shorten the time it takes new developers to be capable of writing reliable production-ready code.