Learn programming for good instead of profit

Manifesto

I have a very good reason for creating a new tutorial when there are so many existing ones. It's obvious even to non-programmers that there are pervasive problems with modern software. When I was a kid, I had a computer with 256MiB of memory, and it could run all the apps I wanted. Today my laptop has *64 times* that much memory (and its processor is more powerful by a similar factor), but do programs run 64 times faster? Can it run 64 times as many programs at once? Absolutely not. Somehow, simple things like chat apps still lag, even when there's nothing else running. It's no secret that since the start of this millenium, software has become much less efficient.

It has also become less reliable. Nearly every graphical program I use has regular bugs. When I have to fill out web forms for government or commercial purposes, I often find the form is buggy or fails to submit with an error message as helpful as "Something went wrong, try again later". It is amazing that these institutions with their massive resources and huge teams of programmers can't make a working web page.

I attribute these problems to the culture of modern software development, and partly the ways it's influenced by capitalism. There are a few aspects of the cause.

Good software is hard to monetize

How do you make money as a software company? You need to do something new, stand out, attract users with hype. Reliability and efficiency don't generate hype. What generates hype is lofty promises that can't be fulfilled and fancy features that no one's ever done before for good reasons. So, that's what programmers are paid to do.

Low-level software is hard to monetize

Many of the problems in software stem from the bad design of platforms they're built on top of. The operating systems and software development tools we use have many design flaws. But fixing those flaws is much harder to do and to monetize than making new apps, because there are no users you can sell it to. People will pay for an app or a web service, but no one will pay for an app development toolkit or a new, better-designed operating system with no apps yet.

In general, the only things you can monetize are end-user applications (and software-as-a-service in particular), so that's what most programmers focus on, and may be all they know how to do. Many web developers don't know basic facts about how operating systems work. They may not know what a file descriptor is or the difference between heap and stack memory.

Getting something to work temporarily is easier than understanding it

This one isn't related to capitalism, but rather the accessibility and easy searchability of information via the internet. This is of course a good thing, but has a bad side effect: it's easier for a programmer to find an immediate solution to a specific problem than to gain a deep understanding of the system the problem is with. When your code doesn't work and you can't figure out why, you can search for other people who've had the same problem and often find a solution on a website like StackOverflow, that you can paste into your editor without understanding why it works or why it was necessary in the first place. Often, these quick solutions are not really "correct" and lead to more problems in the long term.

I guess this was less true before the information revolution, because the only way to find a solution would've been to read the manual of the system you were using, which would open your eyes to the correct, robust solution.

Our response.

I think the way people learn programming needs to change. Programmers need to learn how systems work before they try to build on top of them. It won't be as satisfying, because you'll have to do a lot of reading and hard thinking before getting your hands dirty with code, and it's not optimal for getting a job as a programmer, but if you're interested in helping solve these pervasive problems with modern software, this is the way.

This work in progress will be somewhere between a curriculum and a study guide for everything I think programmers should understand. I link to resources made by others when I don't think I could write a better one myself, or when I haven't had time to do so. Also, I sometimes include overlapping resources, because they each contribute some unique information or explanatory angles.

I recommend starting at some of the basics of computer science.

Video explanation of binary, the way computers count and store information

Anatomy of a computer

How computers store text

Unix and Internet Fundamentals

The Unix and Internet Fundamentals is very old and some of the details are outdated, so I'm working on replacing it with my own writings, but for the time being I still recommend it. Also, despite the name, most of it isn't specific to Unix or Linux. And don't worry if you don't understand everything it says; you'll get at least something out of it.

What it covers that I don't yet cover myself: booting (BIOS -> bootloader -> kernel -> init), IP, TCP, DNS, HTTP.

If you use Windows or Mac as a daily driver, I want to bring up that you should switch to Linux or a similar operating system. For ordinary people I say it's okay to use Windows or Mac, but if your goal is to help fix fundamental pervasive problems with software, I think this is not optional. We don't need more software that only supports proprietary platforms and more programmers that only understand proprietary platforms.

Use Linux

How does an operating system work?

Historical note on Unix, POSIX, and Linux

Filesystem concepts

The Unix permission system

How does programming work?

What is a library?

What is a syscall?

How do graphical and windowed programs work?

Anatomy of a Linux system

The Ubuntu command-line tutorial

My short appendix to that turorial

Linux command reference

Process environment

How processes communicate with each other

A broad intro to networking

Processor architectures

Memory allocation

How software development works

Data structures

How concurrency works

Don't feel obligated to learn all of these things before you learn to code. I won't define any specific point at which I think you should do that; I'll encourage you to decide when you're ready (or impatient, or just curious) and go here:

Choose a language