Programming Is Mostly Thinking (2014)
Programming work is argued to be far more about understanding problems, exploring designs and iterating on ideas than about typing code, with many noting that the final diff often represents only a tiny fraction of the real effort. Commenters debate how much planning should happen up front versus through prototyping and refactoring, how domain knowledge and maintainability shape good solutions, and how misconceptions—like measuring output by lines of code or overusing abstractions and DRY—lead to bad systems. Interruptions, meeting-heavy cultures and the rise of tools like Copilot and LLMs are seen as changing the balance of “thinking vs typing,” but not eliminating the need for deep, human reasoning.
Nature of Programming Work
- Many agree programming is largely thinking: understanding problems, designing solutions, and deciding what not to build.
- Several distinguish “programming” (design, reasoning) from “coding” (typing, boilerplate, CRUD scaffolding).
- Others argue most industry work is glue/integration and routine changes, so the “90% thinking” framing fits only a subset of jobs.
- Debugging, reading code, and building mental models are described as central, high‑effort activities.
Planning vs Iteration
- Strong tension between heavy up‑front design (especially in safety‑critical and regulated domains) and iterative, exploratory coding.
- Some claim extensive specs, diagrams, and reviews are essential before any code; others say that leads to brittle plans and fear of change.
- Many describe a hybrid: sketch the architecture and risky parts, then iterate in code, often rewriting 2–3 times as understanding improves.
- Writing code (including prototypes and tests) is frequently framed as part of thinking, not separate from it.
Simplicity, Abstraction, and DRY
- Multiple comments emphasize maintainability over cleverness: simple, decoupled code, minimal abstraction, and “dumb but durable” designs.
- DRY is often misapplied: people abstract similar‑looking code that represents different concepts, leading to brittle, over‑general frameworks.
- Performance‑aware design (appropriate data structures, avoiding quadratic patterns) is seen as both a simplicity and correctness tool.
Domain Knowledge and Communication
- Domain understanding (finance, medical, etc.) is seen as crucial; you can’t reason well about systems you don’t conceptually grasp.
- Good engineers are compared to translators: they bridge business language and technical implementation, often via diagrams and discussions.
- Some note non‑compete clauses and politics can disincentivize deep domain specialization.
Tools, LLMs, and Copilot
- Copilot and similar tools are said to compress the “typing” portion, making the thinking proportionally more dominant.
- Commenters stress that LLMs help with syntax and boilerplate but not with “wisdom”: architecture, trade‑offs, and domain reasoning.
- Debate persists over whether LLMs “think” at all; participants describe them as probabilistic text engines that can simulate algorithmic reasoning but also hallucinate.
Productivity, Interruptions, and Metrics
- Frequent interruptions are widely reported as devastating to deep work; long, quiet stretches (often at home or at night) are seen as vastly more productive.
- LOC as a performance metric is heavily criticized; tiny diffs may represent days of valuable analysis or debugging.
- Stories of lost work due to bad version control or bosses deleting code support the claim that re‑typing is fast compared with the original design/debug effort.