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.
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#
Several directions, never one. Each says what your training reuses, what graduates typically lack, the real entry conditions, and one thing you can test this term.
Software engineering, entering deliberately
task-level analysis →- What transfers
- All of it — this is the direct path.
- What graduates typically lack
- Not knowledge but evidence of judgement. The traditional first job taught judgement by paying you to write routine code for two years; that arrangement is weakening, so you need to demonstrate review-quality thinking before anyone would normally ask for it.
- Entry reality
- The bottom rung of the ladder is narrower than it was; the top is intact. Read the occupation page — the split between entry-level and senior is sharper here than in any other first-batch occupation.
Take a generated pull request — yours or an open-source one — and write a review that finds a real problem, with the reasoning spelled out. Do it weekly and keep them. That folder is worth more than another finished tutorial project.
Domains where being wrong is expensive
- What transfers
- Failure reasoning and fundamentals, in the places that keep a human firmly in the loop: payments, security, data integrity, infrastructure.
- What graduates typically lack
- Depth in one specific area, which only time produces. Most graduates have breadth and no depth, which is exactly backwards for this path.
- Entry reality
- Fewer entry-level postings, but the ones that exist are less exposed and better paid. Often reached after a year or two elsewhere rather than directly.
Pick one such area and read a real production system's handling of it end to end — an open-source payment or auth library — until you could explain its failure modes to a classmate.
Between engineering and the problem
- What transfers
- Problem modelling plus the ability to read a system, applied where the value is understanding both the machine and what a person needs from it: solutions engineering, developer experience, technical product.
- What graduates typically lack
- Communication treated as a first-class skill rather than a soft one — writing documentation someone can actually follow, and running a conversation with a person who does not share your vocabulary.
- Entry reality
- Rarely advertised at graduate level, usually entered laterally after some engineering time. Worth knowing it exists early so you build toward it.
Write documentation for something you built, hand it to someone unfamiliar, and watch where they get stuck without helping them. That silence is the lesson.
Engineering thinking in a non-software field
- What transfers
- The whole toolkit, applied where almost nobody can both understand the domain and build. That combination is scarce and does not compete head-on with generation.
- What graduates typically lack
- The domain itself, restarting from near zero — and the patience for a first year that feels like going backwards.
- Entry reality
- No standard path, which cuts both ways: no queue to join, but also nobody recruiting for it. Usually starts from a personal connection to the field.
Find one person in a non-software field with a repetitive problem, and build the smallest thing that actually helps them. One person using it beats a hundred GitHub stars.
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.
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.