For junior developers

Survive your first sprint without copy-pasting commands you don't understand.

Your first month on a real codebase is fifty Slack threads of senior engineers casually typing find . -type f -name '*.tsx' | xargs grep -l ... and you nodding like you know what's happening. Most teams don't expect you to write commands like that yet — but they do expect you to read them. learn-terminal teaches the reading part first. The typing follows, with the safety habits built in from lesson one.

Why the shell is the part nobody teaches you

The shell is the part of the job that does not have a tutorial track. IDEs and linters and AI assistants will all hand you commands, and the only skill that keeps you safe is reading them carefully before you press enter. The course walks you through rm, find, grep, pipes, and redirects with the assumption that you will see them in a thread tomorrow — and that the senior engineer who wrote them moved on three minutes ago.

It also covers the part nobody teaches: how to admit you don't know what a command does. The course's verify-first habit — man, --help, which, a dry run with echo — is the shortcut to stop being the engineer who breaks the dev cluster because an AI suggested rm -rf node_modules .next .cache / and the trailing slash didn't register. That's not a hypothetical. It's a thread your team probably has.

What you can do by the end

  1. Read a senior dev's pipe before running it

    tty/example · junior developers
    # from a teammate:
    $ find . -type f -name "*.tsx" | xargs grep -l "useEffect"
    src/components/Header.tsx
    src/hooks/useAuth.ts

    Find every .tsx file (find), pipe the list into xargs which runs grep on each one, and grep -l prints filenames that contain a match. Now you know what it did before you ran it — and you can write the same shape yourself when you need to.

  2. Verify an AI-suggested rm command

    tty/example · junior developers
    # AI said: rm -rf build/ .next/ node_modules/
    $ ls -la build/ .next/ node_modules/ 2>/dev/null | head
    drwxr-xr-x  build/
    drwxr-xr-x  .next/
    drwxr-xr-x  node_modules/
    $ rm -rf build/ .next/ node_modules/

    Always ls before rm -rf. Confirm those paths exist and are what you expect. The 2>/dev/null hides errors for missing directories. Senior engineers do this; juniors who skip it are the cautionary Slack thread that gets pinned in #engineering.

  3. Find when a function was introduced

    tty/example · junior developers
    $ git log -S "computeTaxRate" --oneline
    a4f7d12 add per-region tax calc
    $ git show a4f7d12

    git log -S searches for the introduction of a string. Then git show that commit. You learn how a helper arrived, who wrote it, and what it changed, without bugging the author of a PR from last quarter.

  4. Tail a dev server log while reproducing a bug

    tty/example · junior developers
    $ tail -f dev-server.log
    [12:01:08] GET /api/users 200
    [12:01:09] POST /api/checkout 500 TypeError: cart is undefined

    tail -f streams new lines. Click the broken button in the UI and watch the error appear. This is the debugging loop. It saves more time than any breakpoint, especially when the bug only shows up under a real request.

  5. Inspect what a npm script will actually do

    tty/example · junior developers
    $ cat package.json | grep -A1 '"scripts"'
    "scripts": {
      "deploy": "rm -rf .vercel && vercel --prod"

    Read before you run. The deploy script removes a directory and pushes to prod. Now you know what pnpm run deploy actually does — and you won't run it while you are on the wrong branch.

What you'll be able to do

By the time you finish the course, you will be able to:

  1. Read most pipes and one-liners without panicking.
  2. Verify any command — AI's, a teammate's, a tutorial's — before pressing enter.
  3. Use git from the command line for the day-to-day moves IDE buttons hide.
  4. Tail a log, grep a stack trace, and find a function's git history.
  5. Stop being the engineer who breaks the dev cluster on a Tuesday.

Lessons junior devs tend to start with

Start with lesson 1

The first lesson takes about five minutes and runs entirely in your browser. No install, no signup, nothing to break. You will close the tab knowing where you are, what a command looks like, and what to read next.

Also for