🎓 Things CS Degrees Don't Teach You

Eight practical engineering skills that every CS graduate has to learn on the job — from Git workflows to debugging, testing, operations, and writing for humans.

🎯 The Gap Between School and Reality

A computer science degree teaches you beautiful things: Turing completeness, NP-completeness, the halting problem, Big-O notation, red-black trees, cache coherence protocols.

What it doesn’t teach you is how to ship software.

Not because CS theory is irrelevant — it’s foundational — but because the daily work of engineering lives in a different skill set: reading error messages, navigating legacy code, debugging race conditions, deploying without downtime, and writing PR descriptions that colleagues can actually understand.

Here are eight gaps every CS graduate encounters in their first year on the job.

1️⃣ Git Workflows

CS programs treat Git as a magical git push button. In practice, Git is a distributed DAG manipulation tool, and your university’s “commit → push → done” workflow is dangerously incomplete.

What They Don’t Teach

The One-Liner That Changes Everything

git rebase -i main

This is the single most important Git command for keeping a clean history. Before you merge, you should be able to look at your branch and see one logical commit per change, with a clear message explaining why.

Code Review Etiquette

2️⃣ Debugging

University teaches you to write code. It doesn’t teach you to read code that’s broken, which is where you’ll spend most of your professional time.

Using a Debugger

Most CS graduates have never used a debugger. They use print() statements. While print-debugging works for simple cases, it fails for:

• Multi-threaded race conditions (prints reorder, timing changes behavior)
• Segfaults (can’t print after memory corruption)
• Signal handlers and interrupts
• Embedded or remote systems where stdout isn’t available

# GDB: gold standard for C/C++
gdb ./my_program
(gdb) break main
(gdb) run
(gdb) print variable_name
(gdb) backtrace
(gdb) frame 3

# PDB: Python's built-in debugger
import pdb; pdb.set_trace()  # python < 3.7
breakpoint()                  # python >= 3.7

# LLDB: modern C/C++/Swift debugger
lldb ./my_program
(lldb) breakpoint set --name main
(lldb) run
(lldb) frame variable
(lldb) thread backtrace

Reading Stack Traces

A stack trace is a gift. It tells you exactly where the program was when it broke. The top of the trace is the crash site; the bottom is the entry point.

Traceback (most recent call last):
  File "app.py", line 45, in <module>       ← entry point
    result = process_data(input_data)
  File "processor.py", line 123, in process_data
    transformed = transform(item)            ← call site
  File "transformer.py", line 67, in transform
    return apply_rules(data['value'])        ← crash site (KeyError: 'value')
KeyError: 'value'

Each frame tells you: the file, the line number, the function, and the local state. Read from bottom to top: the crash is at the bottom, the caller chain is above it.

Bisecting Regressions

When something that used to work stops working, git bisect runs a binary search through your commit history to find the exact commit that broke it:

git bisect start
git bisect bad           # current commit is broken
git bisect good v1.0     # v1.0 was working
# Git checks out a commit halfway between
# Run your test, mark good or bad
# Repeat ~log2(N) times
git bisect reset         # return to original state

For a 500-commit range, bisect finds the culprit in ~9 steps. Most engineers don’t know this exists and waste hours manually scrolling through git log.

3️⃣ Reading Other People’s Code

In university, you write your own code from scratch. In industry, you read 10x more code than you write.

Navigating Large Codebases

How to approach a codebase you've never seen:

1. README first — does a setup guide exist?
2. Entry point — where does the program start? (main, app.py, index.js)
3. Tests — tests are executable documentation
4. Commit history — `git log --oneline` shows what changed and why
5. Architecture docs — if they exist, read them before any source file
6. One feature end-to-end — trace a single request through the system
7. Don't understand everything — 80% understanding of 20% of the codebase is enough

The Rubber Duck

Explain the code you’re reading to an inanimate object. If you can’t explain a function to a rubber duck, you don’t understand it well enough to modify it.

4️⃣ Testing

University teaches you to write code that works on your machine with your inputs. Industry requires code that works on every machine with every input.

The Testing Pyramid

        ╱─────╲
       ╱  E2E  ╲       ← Fewer tests, higher confidence
      ╱─────────╲
     ╱  Integration ╲   ← Service-level tests
    ╱─────────────────╲
   ╱    Unit Tests     ╲  ← Many tests, fast feedback
  ╱───────────────────────╲

Mocking

Mocking isolates the code under test from its dependencies (databases, APIs, file systems). The skill is knowing what to mock and what to keep real:

• Mock external APIs (you don’t control them)
• Mock I/O (files, sockets, network calls)
• Do NOT mock your own code (test the real thing)
• Do NOT mock trivial dependencies (plain data transformations)

Testing in CI

A test that only passes on your machine doesn’t exist. Every test must run in CI. Every CI failure must block the merge. These are non-negotiable rules in professional engineering that are never taught in school.

5️⃣ Operations

“The computer works” is an assumption at university. In industry, it’s a hypothesis you verify continuously.

Deployment

Local dev → Feature branch → CI → Staging → Production → Monitoring

Each step catches a different class of error:

On-Call

You will be woken up at 3 AM. Prep for it:

1. Runbooks: Document every alert and its response. If you’re fixing the same thing twice, automate it.
2. Escalation paths: Know who to call when you can’t fix it.
3. Postmortems: Every incident gets a written postmortem. Blameless. What broke, how we fixed it, how we prevent it next time.

SLOs / SLIs / SLAs

The goal is to measure what matters, target achievable reliability, and tradeoff reliability for velocity intentionally.

6️⃣ Writing for Humans

The most important engineering skill nobody teaches: clear writing.

Code Review Comments

Bad: "This is wrong"           → Unhelpful, demotivating
Bad: "Fix this"                → No context, no explanation
Good: "What happens if `user` is null here? We dereference it on line 42 without checking."
Good: "Consider extracting this validation into a helper — it's repeated in 3 places."

RFCs / Design Docs

A good design doc answers five questions:

1. What problem are we solving? (Context)
2. Why now? (Motivation)
3. What approaches did we consider? (Options)
4. What are we doing and why? (Decision)
5. What are the risks? (Trade-offs)

Documentation

Write docs for your future self, who has forgotten everything about this system. A year from now, you’ll be grateful you left a comment explaining why, not just what.

7️⃣ Trade-Off Thinking

CS teaches you that there’s a “correct” answer. Real engineering teaches you that “it depends” is the correct answer to most questions.

The Halting Problem of Engineering Decisions

There is no algorithm to determine the “right” architecture. Every decision is a trade-off between:

Time-to-market  ⇄  Code quality
Developer speed ⇄  Operational simplicity
Feature count   ⇄  System reliability

Recognizing when you’re optimizing the wrong variable is the mark of a senior engineer.

8️⃣ Reading Error Messages

This sounds trivial. It’s not. Most errors tell you exactly what’s wrong, but engineers panic, scroll past the error, and start guessing.

How to Read an Error

1. Read the FIRST line  → What type of error? (KeyError, NullPointer, etc.)
2. Read the LAST line   → The actual message (often contains the answer)
3. Read the stack trace → Where did it happen? (file, line number)
4. Read the error line  → What was the program doing?
5. Read the context     → What values were in play?

Example

TypeError: unsupported operand type(s) for +: 'int' and 'str'
  File "calculator.py", line 12, in add
    return a + b

The error tells you:

• Type: TypeError (wrong type used)
• Operation: + failed
• Types involved: int and str (can’t add a string to an integer)
• Location: calculator.py:12 in add
• Variables: a is int, b is str

The fix is likely at the call site — maybe a str was passed where an int was expected, or b needs to be converted with int(b).

Most errors contain the answer if you read them carefully enough. The skill is staying calm and reading the full output before reaching for Stack Overflow.

💡 Key Takeaways

1. Git is a DAG manipulation tool, not a “save” button — learn branching, rebasing, bisecting
2. Debuggers are rocket fuel for problem solving — learn at least one (gdb, lldb, pdb)
3. Reading code is 10x more important than writing it — navigational skills are learned, not taught
4. Testing is a career, not a checkbox — the pyramid, mocking, and CI integration are all essential
5. Operations is the forgotten layer — deployment, on-call, SLOs are half of engineering
6. Writing is thinking — clear PRs, RFCs, and comments separate great engineers from good ones
7. “It depends” is a professional answer — trade-off reasoning is the core skill at senior+ levels
8. Error messages tell you the answer — read them before guessing

CS degrees give you the theory. Real engineering is what you build on top of it.

📖 Series Navigation