Skip to main content

Module 2: Developer Environment & Tooling

Primary text: Missing Semester (https://missing.csail.mit.edu/) 2026 lectures on the shell, command-line environment, and development tools
Selective support: The Linux Command Line for depth and Unix Network Programming for Unix/POSIX professional context

This module is the bridge between "I can use a computer" and "I can work like an engineer." You will learn to navigate confidently in a shell, edit fast enough that the editor disappears into the background, and build a reproducible environment that you can carry from machine to machine.

Before You Start (Diagnostic Prerequisites Assessment)​

Start with the Beginner Route and Practical Checks for shell selection, required evidence and the 18–26-hour allocation. No previous programming or Git knowledge is assumed. Prepare config files here; add their Git history in Module 3.

Diagnostic use​

Allow about 20 minutes as a planning estimate, with no speed cutoff. Attempt the five questions before revealing each answer. Unfamiliar topics identify what to learn next; they do not block entry to the module. Documentation is allowed during practice. Advanced customization is optional.

Diagnostic Questions​

Question 1: Tool Layering​

Which statement correctly distinguishes a terminal emulator from a shell?

a) A terminal emulator displays the interface, while the shell reads and executes commands
b) A shell is the visual window, while the terminal emulator parses commands
c) They are identical and the terms are interchangeable in all contexts
d) The shell manages files, while the terminal emulator manages processes

Reveal calibration after your attempt

Correct Answer: (a)
Why This Matters: If you confuse layers, you will struggle to troubleshoot configuration problems and pick the right tool to customize.

Question 2: Navigation and Paths​

You are in ~/projects/degree-plan/docs and need to move to ~/projects/degree-plan/src. Which command is the most direct?

a) cd ../../src
b) cd ../src
c) cd ~/src
d) cd /src

Reveal calibration after your attempt

Correct Answer: (b) — .. moves from docs to degree-plan; src is its sibling directory.

Why This Matters: Reliable path reasoning is the foundation for shell fluency, scripting, and tool automation.

Question 3: Streams and Redirection​

What does python app.py > run.log 2> run.err do?

a) Saves both output streams into run.log
b) Saves standard output to run.log and standard error to run.err
c) Saves standard error to run.log and standard output to run.err
d) Appends both streams to both files

Reveal calibration after your attempt

Correct Answer: (b)
Why This Matters: Engineers need to separate results from errors when debugging programs, test runs, and automation scripts.

Question 4: Process Control​

You launched a long-running command in the foreground and want to continue using the shell. What is the usual workflow?

a) Press Ctrl+C, restart the command, and hope it finishes faster
b) Press Ctrl+Z, then use bg to resume it in the background
c) Close the terminal window and reopen it
d) Use fg to move it into the background

Reveal calibration after your attempt

Correct Answer: (b)
Why This Matters: Job control is one of the first shell features that makes the terminal feel like a real working environment rather than just a command launcher.

Question 5: Configuration and Reproducibility​

Why do professional developers keep dotfiles under version control?

a) To hide private configuration from the shell
b) To make setup reproducible, track changes, and move environments between machines
c) To prevent tools from reading configuration until explicitly enabled
d) To speed up terminal startup by compressing configuration

Reveal calibration after your attempt

Correct Answer: (b)
Why This Matters: Environment setup is part of professional workflow. If your setup only lives in memory, it is not reliable.

Routing after the diagnostic​

  • Questions 1–2 missed: start with Cluster 1 navigation and tool distinctions.
  • Questions 3–4 missed: study streams and interactive job control, then use the local workshop.
  • Question 5 missed: study environment/configuration concepts and the disposable setup lab.

Even a correct diagnostic is not practical evidence. Follow the local route, preserve your first attempts and repair with fresh cases. Full external lectures, challenge-site quotas, personal dotfile changes and speed targets are not remediation prerequisites. The exit quiz and practical checks determine completion.

What This Module Is For​

This module builds the environment discipline needed for the rest of the degree. Git, compilers, test runners, debuggers, package managers, containers, and remote machines all assume you can work from the command line and keep your tools under control.

You are not trying to become a shell maximalist. You are trying to become someone who:

  • can work without being blocked by the GUI
  • can debug environment problems instead of fearing them
  • can reproduce a productive setup across machines
  • can participate in professional engineering workflows without tool friction

Hierarchical Concept Organization​

Medium Module Structure (8 concept pages in 3 clusters)​

Learning Pathway:

  1. Master shell fundamentals
  2. Build editor speed and low-friction navigation
  3. Automate your environment so setup becomes reproducible instead of manual

How To Use This Module​

This is a medium module with hierarchical sequencing. PRIMARY pages carry the core mental model for each cluster. SUPPORTING pages widen the model into practical technique.

Cluster 1: Shell Mastery (Concepts 1-3)​

Learning Pathway: Navigation and file reasoning -> process control -> command composition

OrderConceptTypeFocus
1Shell Navigation and File OperationsPRIMARYEssential commands and file system interaction
2Process Management and Job ControlSUPPORTINGRunning, monitoring, and controlling processes
3Command Composition, Redirection, and PipesSUPPORTINGStreams, redirection, filters, and shell composition

Cluster Mastery Check: Can you inspect files, predict redirection and control your own practice job, explaining each result? Accessibility tools are permitted.

Cluster 2: Editor Efficiency (Concepts 4-5)​

Learning Pathway: Modal editing -> editor tuning and navigation habits

OrderConceptTypeFocus
4Modal Editing with VimPRIMARYEfficient text editing and navigation
5Editor Configuration and Fast NavigationSUPPORTINGSearch, splits, configuration, language support, and repeatable editor habits

Cluster Mastery Check: Can you make small edits, move around a file, search, replace, and save without stopping to think about mode?

Cluster 3: Environment Automation (Concepts 6-8)​

Learning Pathway: Environment variables -> dotfiles and setup -> real workflow integration

OrderConceptTypeFocus
6Environment Variables and Shell StartupPRIMARYPATH, exports, profile files, and shell initialization
7Dotfiles and Reproducible SetupSUPPORTINGVersion-controlled configuration and bootstrap workflow
8Workflow Integration, Remote Work, and AutomationSUPPORTINGSSH, tmux, scripts, and environment choices that scale into professional work

Cluster Mastery Check: Can you explain how your shell starts, where your config lives, and how you would recreate your setup on a fresh machine?

Practice Integration (After completing all clusters)​

OrderPractice PathFocus
1Command-Line Proficiency WorkshopPredictions, shell operations and explainable results
2Editor Mastery ChallengeModal editing drills, search, replace, and navigation with saved/reopened evidence
3Environment Setup Automation LabDotfiles, bootstrap scripts, and reproducible setup
4Code Katas: Development Environment FluencyProfessional workflow integration and productivity optimization

Learning Objectives​

By the end of this module you should be able to:

  1. Navigate file systems and manipulate files confidently from the shell.
  2. Use streams, redirection, and pipes to compose multi-step command-line workflows.
  3. Inspect, suspend, resume, and terminate processes using the right level of force.
  4. Edit text efficiently with Vim or Vim-style editing, not just basic insert mode.
  5. Explain and modify environment variables, startup files, and PATH without guesswork.
  6. Prepare reproducible configuration and setup notes, adding version history during Module 3.
  7. Build a reproducible local workflow and explain how remote work differs; a remote deployment is optional.
  8. Troubleshoot environment problems systematically instead of reinstalling everything blindly.

Outputs​

  • one shell workflow cheat sheet
  • one editor workflow cheat sheet
  • one working small shell config fixture, demonstrated in an isolated child shell
  • one prepared dotfiles folder; add version control during Module 3
  • one bootstrap script or setup checklist that recreates your environment
  • one short automation script for a repeated task
  • one written troubleshooting checklist for broken environment issues
  • one practice log showing repeated command-line and editor drills

Completion Standard​

Close the practical checks and score at least 18/20 on the quiz before marking the module demonstrated. A high quiz score cannot replace observed practice; repair missed concepts on fresh variants.

You have completed Module 2 when you can:

  • inspect and reorganize project files from the shell with an explanation of paths and effects
  • redirect output intentionally and explain where stdout and stderr are going
  • use ps, jobs, bg, fg, and kill appropriately
  • make routine search/change/delete/save/reopen edits in Vim or an accessible equivalent, and explain Vim mode distinctions
  • explain where your shell configuration loads from and how PATH affects command discovery
  • recreate the small configuration fixture in a fresh directory and shell from documented steps
  • automate at least one repeated development task instead of repeating it manually

Reading Policy​

  • The concept pages are the main path.
  • Use the reference section only when a concept still feels unclear after practice.
  • Missing Semester is the backbone, but you should translate every idea into your own workflow immediately.
  • Build your environment in layers. Do not try to perfect everything in one sitting.
  • Prefer reproducibility over aesthetic tweaking. A fast setup that can be rebuilt matters more than a pretty prompt.

Missing Semester Integration​

This module directly implements the 2026 Missing Semester material most relevant to early engineering work:

Lecture 1: Course Overview + The Shell​

Lecture 2: Command-line Environment​

Lecture 3: Development Environment and Tools​

Selective supporting references​

Suggested sequence (not a seven-day deadline)​

DayWork
1Diagnostic plus Concept 1
2Concepts 2-3 and the first workshop block
3Concepts 4-5 plus vimtutor or equivalent editor drills
4Concepts 6-7 and dotfiles setup
5Concept 8 plus the automation lab
6Module quiz and correction review
7Code katas, cleanup, and environment rebuild check

Why This Matters Later​

  • Module 3 assumes you already know how to work in the terminal while using Git.
  • Later systems modules assume you can inspect processes, edit config files, and survive on remote machines.
  • Cloud and DevOps work eventually expects scripting, SSH, environment setup, and reproducibility as baseline skills.
  • Hiring teams often read environment fluency as a proxy for engineering maturity because it reveals how you work when the path is not pre-built for you.

Use Reference and Selective Reading when a concept still feels fuzzy after practice.

Rich Learning Pages​

Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread