LO
Computer science
Trains you to model a problem precisely enough that a machine can execute it — and to reason about what happens when it does that at scale, under failure, and with someone attacking it.
Start the weekly code-review folder. Four entries by the end of term is a better signal than any certificate.
A single number for a whole major would hide the thing that matters: this degree trains several separate competencies, and they are not all moving in the same direction. Automation acts on tasks, so any assessment lives on the occupation pages below — not here.
Written for four-year CS and software engineering degrees. Research-track and hardware-focused programmes differ materially.
What this degree actually trains#
Not the course list — the competencies underneath it, and whether each one is worth more or less than it was.
Modelling a problem precisely
Worth more than beforeTurning something a person described vaguely into a specification with no undefined cases.
Generation is downstream of the spec and amplifies a wrong one faster than a person would have. Whoever writes the spec now determines more of the outcome than whoever writes the code.
Reasoning about failure
Worth more than beforeKnowing what breaks under concurrency, partial failure, and unexpected input — before it breaks.
This is where the ceiling on generated code shows up most clearly. Fluent code that is wrong under load looks identical to correct code until it is in production.
Reading an unfamiliar system
Worth more than beforeHolding enough of someone else's codebase in your head to know which observation would be decisive.
As more code is machine-produced, more of the job becomes reading code nobody wrote by hand. Reviewing plausible-but-wrong code is a distinct, newly central skill.
Writing routine code
Worth less on its ownProducing correct, idiomatic implementations of well-specified things.
Well-specified, heavily represented in training data, and immediately checkable by running it — the strongest case for code generation. But note: you cannot judge code you could not have written, so this stays a prerequisite even as it stops being a product.
Fundamentals
HoldingComplexity, data structures, concurrency models, how a computer actually executes.
The part of the degree that dates slowest and that you cannot pick up from a tutorial. It is what lets you reason about a system you have never seen.
Where it can lead#
9 directions, never one. Each is written out in full on its own page — what your training reuses, what graduates typically lack, the entry reality, and one thing to test this term.
- Software engineering, entering deliberately · Junior software developer →
- Domains where being wrong is expensive · Backend developer →
- Between engineering and the problem
- Engineering thinking in a non-software field
- Testing and quality engineering · Software tester / QA engineer →
- Putting AI into production inside a company · AI implementation lead →
- The layer people actually touch · Frontend developer →
- The pipes, and who answers for what comes out · Data engineer →
- Systems whose behaviour is learned · Machine learning engineer →
Read all of them in full — what transfers, what is missing, what to test →
What to add outside the classroom#
This is about what graduates commonly lack in practice — not a claim that your school failed to teach it.
Time in a codebase with real stakes — an internship, an open-source project people depend on, anything where being wrong has a consequence. Toy projects cannot teach judgement because nothing is at risk.
Reviewing other people's code, including generated code, deliberately and regularly. This is the skill the market is short of and the one school assesses least.
Writing. Design documents, incident write-ups, explanations. The engineers who advance are the ones whose reasoning other people can follow.
This term#
One or two actions, each producing something you can show someone. Not a reading list.
Start the weekly code-review folder. Four entries by the end of term is a better signal than any certificate.
Read one production system end to end in an area where correctness is expensive. Depth in one place beats breadth across five.
Common questions#
Yes, but for a different reason than five years ago. The degree used to be valuable because it let you produce code; now the value is that it lets you judge code — and you cannot judge what you could not have written. What genuinely changed is the job market at the entry end: the routine work that used to pay juniors while they developed judgement is the part being automated. So the training still works, but the old arrangement where your first job taught you on someone else's payroll is weakening. Plan for that gap explicitly instead of assuming the first job will close it.
Computer science is the odd case: the tools are best at exactly what the degree teaches you to produce, and the entry-level job it feeds is in the group where employment of the youngest workers has fallen. That is a real argument, and it is not an argument for leaving — it is an argument for entering with a plan for how you will reach the judgement work, because the routine coding rung that used to carry you there has thinned.
It is worth it when it changes what you can be hired to do — research, systems, a specialism with few practitioners — and not worth it as a way to wait out a soft graduate market. A master's that teaches the same production skills one level up competes with the same tools. Check the specific lab or group, not the degree name.
Something you debugged that you did not write. Reading fluent-but-wrong code carefully enough to find what is confidently broken is the task this site marks as newly central, and it is the one thing a portfolio of generated projects cannot demonstrate. One real contribution to a codebase you did not start beats five finished side projects.
Method#
Assessments live on tasks, not on majors. Follow any direction above to its occupation page to see which tasks are changing, how strong the evidence is, and what it does not yet show.