Want to Code? A University Degree Might be a Huge Waste of Time

A lot of people think they need a university degree to get a job as a software engineer.
A few days ago, I published a post called “Learn to Code: 13 Tips that Could Save You Years of Effort”. Tip #1 was “Forget university programs.”
Here’s the full tip:
Forget university programs. Unless it’s from Stanford or MIT, your degree will mean a lot less than having some apps to show off. In fact, most university programs struggle to keep up with changing technology. A degree will buy you a few thousand dollars more for the first 1–3 years. After that it makes exactly zero difference. Unless you like flushing time and money down the toilet…
I’ve talked about this a lot, but I’ve never written a detailed, data-backed blog post on the topic. If I’m gonna make a strong claim like that, I’d better back it up.
Here’s reality. (Data from the 2016 Stack Overflow survey of 56,033 coders):
- Mentorship programs have a stronger correlation with higher pay than a university degree
- There is less than 1% difference in pay between masters degree holders and bootcamp graduates
- 69% of working software developers are self-taught
- 43% cite on-the-job training as their primary learning resource
- 25% used online courses
- Only 19% have a masters degree related to CS
- Only 8.5% have a B.A. in CS
- 6.5% graduated from a Bootcamp (this number is growing fast)
When it comes to software engineering jobs, “or equivalent experience” is expressed or implied about 96% of the time. (About 4% of developer jobs require advanced math and science work).
After 3 years on the job, and a track record of building great products, nobody cares anymore if you went to school, and for that reason, the pay difference evaporates as you pick up more experience.
A college degree will earn you a few thousand dollars more per year, but only for the first 3 years. After that, it doesn’t make any difference at all.
A Degree Won’t Open More Doors than Faster, Less Expensive Options
The only thing employers really want to know about your education is whether or not you know how to code. All evidence of that will be considered (including a degree if you’re junior), but employers have a strong preference for proof of skills in real code, not a piece of paper.
The best way to learn to code is to code. The best way to prove you can code is to code.
Degrees Give You A Good CS Foundation in Theory
Yes, university CS does give you a solid foundation of algorithms, data structures, and computer science fundamentals. That is absolutely true, and it can certainly be valuable. You’ll get a much stronger foundation in theory.
The key here is in theory.
The trouble is, most universities don’t help much at all with actual software engineering. Engineering is about applications, not theory.
Most universities teach a variety of well-known cookie-cutter algorithms, many of which are not commonly used in modern programming languages because better alternatives are built into the language or standard libraries.
What students really need to learn is how to solve problems with their own brains, rather than studying solutions out of textbooks whose first editions were written 30 years ago when applications were much, much different than they are today.
When it comes right down to it, data structures and algorithms are really about finding performant solutions.
Higher Ed and Sort Algorithms
Intro CS courses are obsessed with teaching sort algorithms. You’ll probably spend the better part of a whole semester on them. Is that because you need to know 6 different sort algorithms to choose the best one?
No. Absolutely not. It’s because there are lots of different sort algorithms with wildly different performance characteristics, which makes it an interesting study in performance profiling, and a great way to learn about big O notation — a way to understand the performance characteristics of an algorithm.
The problem is, while big O notation is useful, you can sum it up with some simple intuition: More work = worse performance:
- Iterating and operating over large lists is slow
- Increasing the number of iterations will slow things down
- Multiplying the number of iterations will slow things down a lot
- Multiplying iterations by orders of magnitude will make things crawl
Here’s the catch: Unless you’re talking about very large collections, or very bad algorithms, teaching students that network, disk, and render are expensive is much better than teaching them 6 different sort algorithms which are all slower than the built-in `Array.prototype.sort()`.
I know it’s useful to study existing algorithms and compare them, but really… this is ridiculous:
Yes, they’re teaching a lot of different lessons with all those sorting algorithms and different data structure strategies, but by the time the student gets through all this and they finally get to the trusty quick sort, they’ve run out of attention. They miss the point, and they’re left wondering:
“If quick sort is so much faster than merge and heap sort, why did we learn merge and heap sort to begin with?”
And that is a totally legitimate question.
The Real World
Meanwhile in the real world, it turns out that none of those algorithm choices will make anywhere near the performance impact as conserving your network or disk access, lazy evaluation or streams.
And when you get to web scale and reach collection sizes where algorithm efficiency is really important, network, disk access, and streaming throw a big monkey wrench in analyzing the performance of your solutions — and the feasibility of any algorithm that relies on shared memory in the first place.
When it comes to real applications, nothing is really as cut and dry as the theory describes.
By concentrating on theory at the expense of concentrating on applications, students get a warped idea of performance profiles which doesn’t take the physical realities of modern computation into account. Students learn to obsess over performance characteristics of things that don’t make any practical difference to the performance of real apps.
The good news is, you can skip some of the less valuable crap from CS courses and learn about concurrency, streams, working with machine clusters, and lazy evaluation instead of implementing yet another textbook, impractical, shared-memory sort algorithm that’s already been implemented 10 million times, and is optimized for long-obsolete 1980 machine architecture.
Don’t You Need to Know Lots of Data Structures and Algorithms?
Universities love sort algorithms. The trouble is, there’s really only one sorting algorithm you need to know anything about: the one built into your language or standard library, and what you really need to know about it is the API.
The fastest sorts for in-memory, general case sorts are built into the languages and standard libs, and other conditions are much more important for performance in almost all applications (network, disk access, lazy vs eager evaluation, etc…).
I have only needed to use an alternate sort algorithm once in the last 20 years. Chances are, you never will.
For almost all cases, if anything, I would consider knowledge and conscious consideration of lots of sort algorithms a distraction from most real world application performance issues. “The Paradox of Choice” is relevant here:





