I wrote a post talking about the topics you should know. While writing that post, I realized there were a lot of topics I’d like to put on the list, but couldn’t. My criterion for inclusion in the list was that the topic needed to be taught in some shape or form by an NYU CS course, ideally a core one. If one professor taught the topic but not others? Fine. But it needed to be something that an NYU student could have conceivably stumbled upon. In the spirit of kvetching about NYU, here’s some of these topics I wish NYU taught.

Programming Languages

Anybody who knows me personally is probably rolling their eyes. I happen to be rather interested in PL, having written my own programming language. Until recently I had accepted that my interest was just a niche area that not everybody needed to know.

What changed? Well I started working on a project to compare CS curricula (more on that in another post). As I trawled through the various requirements and course offers, I began to realize something. Hey, programming languages is a pretty damn common requirement!

There’s good reasons for this. For one, programming languages is a foundational pillar of CS. There’s debate about the exact pillars, but I’d say it goes: Systems, Theoretical CS, Programming Languages, Artificial Intelligence and Software Engineering. Maybe Human-Computer Interaction too.

Every programmer interacts with a programming language. No matter what company, no matter if it’s front end, back end or middleware, you’re dealing with a compiler or interpreter if you’re writing code.

What is programming languages? Programming languages is the general study of the languages you use to write code. This can mean implementations such as compilers or interpreters. This can mean theoretical topics such as type theory, formal methods for proving correctness or program analysis. This can mean different paradigms of programming languages such as functional, logical or imperative.

Programming languages has ties to many other areas in CS. You’ll need to know some systems development to work with compilers that generate assembly. You’ll need to know some theoretical CS to analyze your PL algorithms (cf Swift Typechecking is Undecidable). You’ll need to know some software engineering to write a compiler and design an effective language. You might even need some machine learning knowledge if you’re writing the right sort of compiler.

A lot of problems become easier to classify when you think of them as programming language problems. Dealing with formats like XML, JSON, FIX? That’s a parsing problem. Automatically creating scripts and templates? That’s a code generation problem. Validating data? That’s a typechecking problem.

If you want to learn more about programming languages, I’d recommend the following resources:

• Crafting Interpreters is a wonderful book on how to write an interpreter for a language. It teaches from the ground up. All you need is some Java experience.

• Beautiful Racket is a great intro to creating mini programming languages to solve your problems.

• Learn You A Haskell is an often recommended book to learn Haskell. Some people aren’t a fan, but hey, it’s free.

• Lambda Calculus is a fundamental concept in PL. Computerphile has a great video on it.

Networks, Databases & Other Systems Stuff

I actually consider NYU’s systems classes some of the more interesting and informative classes that I’ve taken. However they lack a few areas. We don’t learn how databases work and we don’t learn about networks.

Both are fairly essential. Databases are at the center of every application. Everybody needs to store data somehow. Networks are crucial for communication; you can’t have the internet without networks. They’re also the application for graph theory.

We do have a databases course, but it appears to be a very introductory one without any real meat. Which is a shame because databases are an area where a little knowledge can go a long way. Whether it’s using tools like indices or views, or understanding relational algebra, database knowledge can pay off in making your data simpler, easier to understand and easier to work with.

NYU also omits distributed systems for the most part. While they’re not as ubiquitous as databases, distributed systems are pretty common in large companies. Most large tech companies like Amazon or Microsoft operate distributed systems in the form of S3 or Cosmos. If you work at a big N, you’ll likely have to use some distributed systems knowledge.

I’m not an expert on this areas, but here’s some resources I’ve been meaning to look at myself:

• Use The Index, Luke is a great site for understanding database performance

• Networking Zine by Julia Evans looks wonderful for understanding networks.

• Computer Networks is a classic text on networks.

• SQL for Web Nerds is something I found on the internet just now, but hey Hacker News recommended it, so how bad could it be?

• Paxos Made Simple is an explanation of Paxos, one of the most important consensus algorithms for distributed systems, from the creator themself, Leslie Lamport. It miiiight not be as simple as it claims, since Lamport is a rather brilliant person.

Software Engineering

This is a commonly mentioned one. Many NYU CS students graduate with little to no software engineering knowledge. Those that do often get their knowledge from outside sources.

When people talk about software engineering knowledge, they often mean stuff like knowing how to build a front-end app, or being able to write a back-end API. That’s great and stuff that you should definitely know. If you’re interested in learning more, join Spark, Torch’s mentorship program.

However, this is not the software engineering knowledge that I’d like NYU to impart. Practical knowledge is hard to teach and requires teachers who are perpetually up to date—ideally in industry themselves. Instead I’d love NYU to teach software engineering technique. As any programmer can atest, software engineering is more than just writing code. It’s about code quality, team management, product, infrastructure, dependency management, user experience, and a whole slew of other factors.

How do we teach these factors? Easy. Reading! I know, some of you don’t like reading. Some of you would rather debug raw hex code than read Joseph Heller. Unfortunately there’s a lot of knowledge hidden in books and the only way to retrive it is to read them.

I’d love for students to learn about concepts like Brooks’ Law: Adding manpower to a late software project makes it later. That way when your boss talks about hiring 2 more developers to help ship the behind schedule, over budget project, you can flash back to your software engineering class and jump ship.

It’s incredible to me that we teach programmers without any real respect given to our predecessors. They encountered many of our problems. It’s only fair of us to listen.

Here’s some more resources:

• Jeff Atwood’s book list is a great starting point. Definitely take a look and read some of these.

• The Mythical Man Month. It’s on Jeff Atwood’s list, but hey, I know some people don’t click links. Brooks’ law comes from this book. It’s probably the most influential book on software engineering. Read it.

• Smart And Gets Things Done is a book on hiring. Why would you read a book on hiring? How your company hires determines who your company hires determines your experience at the company. If you apply for a job at a company and their hiring process is less than ideal, don’t work there.

• Joel on Software and Coding Horror are two classic blogs on software engineering. They’re a little old, but their knowledge is still really useful.

• Spark is Torch’s mentorship program. We’re mostly teaching the nitty gritty details, but you’re working on a team with other people, so you’ll get to pick up the technique as well. Plus you get to be mentored by me!

• Get A Job. Ultimately this is the best way to learn. Get an internship and you’ll learn more about how to write software in three months than in four years.

Security

Security is another area we woefully neglect. Which is odd since security permeates every programming job ever. Even if you don’t end up in tech. Even if you give up CS to pursue your dream of a PhD in mid-to-late-20th century LGBTQ+ Spanish film, security is an essential part of modern life.

Forget CS students. We should be teaching everybody how passwords work. Everybody should have a working understanding of password hashing, of password complexity and of how people can brute force passwords. Everybody should know enough that if a website emails them a plaintext password, they should delete that account and change all of their passwords. Everybody should know about phishing scams, about social engineering, about verifying identity.

We should be teaching people to use password safes and not create passwords from their kids names and birthdays. We should be teaching them to, yes, use two factor authentication. Sorry but NYU got this one right¹.

For CS students, we shouldn’t stop there. We should understand how classic symmetric and asymmetric algorithms work. Asymmetric encryption powers the internet. We should learn about elliptic curves and key generation algorithms. We should learn about SSH keys, about HTTPS, about how to create secure systems.

But wait, there’s even more! We haven’t even covered the really technical topics like buffer overflows or speculative execution attacks. These aren’t the easiest to understand but hey, Spectre literally affected almost every computer around.

This is only the tip of the iceberg. I’m not an expert on security, far from it. Here’s a few resources to help you:

• Troy Hunt blogs a lot about security. He has great recommendations on passwords and general web security.

• The Spectre Paper isn’t a bad read if you know your computer architecture.

• Diffie-Hellman is super super foundational for the internet. I’d recommend understanding it.

Keep Learning

If you read this and think “geez, there’s a lot of gaps in NYU’s education”, you wouldn’t be wrong. NYU doesn’t teach a lot of subjects that I believe are essential. However the same is true of all schools to some extent or another. Nobody leaves college knowing enough. It’s not like your professors coordinate and figure out exactly what to teach so that every student gets a perfectly seamless and comprehensive education. No, they teach their course and if they run out of time and some material falls through the cracks, well so be it. Not to mention, each and every person’s definition of enough is different—and changes as time passes.

What’s an ambitious student to do? Don’t take school as the be all end all of knowledge. School is but one place where you can learn. Don’t use “it wasn’t taught” as an excuse for not knowing something. Read books, watch videos, ask people about different topics. You may surprise yourself with what you discover.