Programming Is Mostly Thinking (2014)

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.