My computer science degree taught me how to build. Two courses covered why anyone should care.

Looking back at my course list, the technical ground was solid: calculus, probability and statistics, algorithms and data structures, Python, C, C++ and Java, databases, networks, operating systems, functional programming, HCI, AI, compilers, mobile applications.

I'm not complaining about that list. You can't build anything serious without it, and I used a lot of it.

My complaint is about what the list leaves out.

Where "why would anyone pay for this?" came up

Across all those courses, only two touched it at all: Software Engineering and the final year project. They worked the same way. You pick a problem, research it, build a solution, and document the whole process. The closest thing to business was the communication phase: pitching the problem, explaining the concept, showing how it differs from the system that already exists, and arguing that it's feasible.

That's useful, and it came late. Everything before it was about making the code correct. Almost nothing was about making the code matter.

What worked

My software engineering lecturer did her best here. Her practical group project, and her strictness about it, forced students to actually work together, including people who had no drive for programming. The final year project did something similar, except solo. Those were the closest the degree came to real work.

Even so, neither one taught the economic side: pricing a project, selling it, negotiating what you're worth.

The graduates who leave

From what I saw, most graduates from my program end up working in unrelated fields. Some lose interest in tech along the way, or were never passionate about it. Others can't find work in it. I understand both.

But here's what I can't stop thinking about. In a paid workspace, I met someone with no tech school education. I believe his background was in law or medicine, and he had only recently gotten into tech. He was building an AI agent for emergency lines. It answers the call, takes down the emergency, follows the protocol, asks the right follow-up questions, documents the case, and triggers the matching response. Say you call for a fire. Instead of waiting in a queue, the agent logs it and sends the closest available crew.

I can't tell you how far that system had got, or how well it would hold up. Emergency systems fail in ways that matter, and that's exactly where a computer science foundation (reliability, security, testing) earns its keep. But he understood the problem and the people who would use it, and he was already building. My question is a simple one: why wouldn't a CS graduate with no feel for the problem get outpaced by someone like that, especially now that AI tools make building easier?

One change I'd try

I'm no curriculum designer, but here's a fix that doesn't mean cutting the technical core. Take what Software Engineering and the final year project did, and spread it across the whole program, starting earlier:

• One small project a year that starts from a real problem, not from a textbook exercise.
• A short pitch, a feasibility check and a rough running cost attached to each project.
• One pitch to a real local business at some point in the program, with their honest feedback.

None of this takes away from the foundations. It changes what the foundations are for.

What you can do now

If you're a student, you don't have to wait for the curriculum to catch up:

1. Pick a real problem near you. A shop, a clinic, a school office.
2. Write down who has the problem, what they do today, and what your fix would cost to run.
3. Pitch it to one person who has the problem, and listen to what they say.
4. Treat your final year project as a real product. It's already the closest thing to this in your degree.
5. Put your code on GitHub, and talk to people outside tech. The person who impressed me came from outside it.