Chapter 3 — The Basic Tools
Topics 16–22 | Pages 143–187
Core Idea
Tools amplify your talent. Like a craftsperson’s physical tools, software development tools must be chosen carefully, learned deeply, and customized to fit your hand. Invest in your toolbox; let need drive what you add.
Topic 16 — The Power of Plain Text (p146)
Tip 25: Keep Knowledge in Plain Text
Plain text = human-readable, self-describing data. This includes JSON, YAML, HTML, Markdown — not opaque binary formats.
Why plain text wins:
| Advantage | Explanation |
|---|---|
| Insurance against obsolescence | Data outlives every application and format; partial knowledge of structure is enough to read it |
| Leverage existing tools | Every tool in the ecosystem — VCS, editors, shell, grep, diff — can operate on it |
| Easier testing | Synthetic test data is easy to create and modify without special tooling |
The Unix philosophy (small, sharp, composable tools) is enabled by the common denominator of plain text. Config files, protocols (HTTP, SMTP), system databases — all plain text.
Key distinction: human-readable ≠ human-understandable. Field19=467abe is readable but not understandable. <SOCIAL-SECURITY-NO>123-45-6789</SOCIAL-SECURITY-NO> is both.
Topic 17 — Shell Games (p152)
Tip 26: Use the Power of Command Shells
The shell is your workbench. GUIs are limited to what their designers envisioned (WYSIAYG — What You See Is All You Get). The shell lets you compose tools, automate workflows, and operate beyond any single tool’s capabilities.
Customize your shell environment:
- Color themes
- Meaningful prompts (current directory, git status, time)
- Aliases and shell functions for repetitive commands
- Context-sensitive tab completion
If you do all your work through GUIs, you can’t automate, can’t combine tools, and can’t scale your productivity.
Topic 18 — Power Editing (p156)
Tip 27: Achieve Editor Fluency
The goal is to eliminate the friction between thought and code. When you’re fluent, editing becomes unconscious — like an experienced driver who doesn’t think about gear changes.
Fluency checklist (without touching the mouse/trackpad):
- Move/select by character, word, line, paragraph
- Navigate by syntactic units (matching delimiters, functions, modules)
- Comment/uncomment blocks with one command
- Multi-cursor editing
- Sort, search with regex, repeat searches
- Split panes, navigate between them
- Run tests from within the editor
How to build fluency: Notice repetitive actions → find the keyboard shortcut → practice it consciously until it becomes muscle memory. Then repeat.
Extend your editor with plugins. If you can’t find what you need, build it.
Topic 19 — Version Control (p161)
Tip 28: Always Use Version Control
VCS is a project-wide undo key, a time machine, and a collaboration hub. Use it for everything — code, docs, config, scripts, even personal projects.
What VCS enables:
- Full history of every change, by whom, when
- Ability to reproduce any past release
- Parallel work in branches without interfering
- Rollback if a deployment breaks production
- Automated CI/CD pipelines triggered by pushes
VCS ≠ shared folder on a network drive. Shared drives cause race conditions and corruption. Use a proper VCS with a central (hosted) repository.
Branches isolate development work; merges/pull requests gate integration. The branch workflow your team uses should match the team’s style — there’s no universal “right” answer.
Good VCS hosting should provide: security, CLI access, automated builds/tests, PR support, issue tracking, and team communication tools.
Topic 20 — Debugging (p168)
Tip 29: Fix the Problem, Not the Blame
Tip 30: Don’t Panic
Tip 31: Failing Test Before Fixing Code
Tip 32: Read the Damn Error Message
Tip 33: “select” Isn’t Broken
Tip 34: Don’t Assume It — Prove It
Mindset
Debugging is problem solving, not ego protection. Turn off defenses. Don’t say “that’s impossible” — it happened, so it’s possible.
Strategy
- Make it reproducible — ideally with a single command. A test that reliably triggers the bug is the first step toward fixing it.
- Read the error message — seriously.
- Use binary chop — for large stacktraces, datasets, or regression ranges: find the midpoint, see if the bug exists there, halve the search space. Repeat until isolated.
- Use logging/tracing — for time-dependent bugs (concurrency, events) where static debuggers can’t capture history.
- Rubber ducking — explain the problem out loud to another person (or object). Verbalizing assumptions often reveals them. The duck doesn’t need to respond.
- Assume the OS/framework is fine — “select isn’t broken.” The bug is almost certainly in your code. Exhaust your code before blaming the platform.
- Prove your assumptions — when surprised by a bug, an assumption you held was wrong. Prove things in this context with this data.
After fixing
- Write a test that would have caught this
- Check if the same bug exists elsewhere in the code
- Understand why it wasn’t caught earlier
- If it took a long time, ask what would make the next fix faster
Topic 21 — Text Manipulation (p181)
Tip 35: Learn a Text Manipulation Language
A general-purpose scripting language (Python, Ruby) or shell tools (awk, sed) is like a router in woodworking — powerful, fast, and essential for transformations that don’t fit any specialized tool.
The value: tasks that take days in conventional languages take 30 minutes in a scripting language. The time multiplier matters enormously for experimentation.
Applications: file conversion, code generation, testing automation, report generation, build pipelines, index creation, code search/rename.
Topic 22 — Engineering Daybooks (p185)
A paper notebook (not a file or wiki) where you record:
- What you worked on
- What you learned
- Meeting notes
- Debug variable values
- Ideas, sketches, reminders
Three benefits:
- More reliable than memory
- Captures ideas without interrupting current focus
- Acts as a rubber duck — writing forces explicit formulation, which often reveals flaws
Prefer paper: the physical act of writing engages different cognitive gears than typing. Use it for at least a month before judging.
Key Takeaways
- Plain text is the universal substrate — it outlives formats, works with every tool, and enables automation.
- Shell fluency multiplies productivity; GUIs cap it.
- Editor fluency eliminates the gap between thought and code.
- VCS everything, always — it’s your safety net, history, and team hub.
- Debugging is methodical problem-solving: reproduce, read the error, binary chop, rubber duck, prove don’t assume.
- A text manipulation language turns hours of work into minutes — learn one.
- A paper daybook captures thinking and serves as an external brain.