It's hard to write code for computers, but it's harder to write code for humans
Writing software that other humans can understand, onboard to, and extend is repeatedly described as harder than getting it to run on a machine at all. Commenters debate whether people learn better from examples or core concepts, how documentation should balance tutorials, references, and theory, and why many frameworks, scaffolding tools, and corporate platforms trade clarity for complexity in ways that hurt developer experience. Several point to literate programming, live environments, and empathy for future readers as key to building systems that are not only powerful but also teachable and maintainable.
Learning: Examples vs Core Concepts
- Big debate around the article’s claim that “humans learn from examples, not core concepts.”
- Many commenters say they need concepts first (theory → examples), otherwise tutorials feel like blind copy‑paste.
- Others strongly prefer example‑first (“here’s a working house; now let’s poke it”), then backfill theory.
- Several argue most people need both: quick examples to get moving, and clear conceptual models to reason, debug, and adapt.
- Math and car‑driving analogies are used on both sides to argue that either concept‑first or example‑first works; consensus is that learning styles differ.
Docs, Onboarding, and Developer Experience
- Strong agreement that good DX is mostly about documentation and onboarding, not just clever abstractions.
- Praise for “just run this one command” experiences vs docs that start with deep architecture and hyperlink mazes.
- References to models like “tutorials vs how‑tos vs reference vs discussions” (e.g., 4-doc) as a useful framing, but not a silver bullet.
- Complaint that big companies often ship complex, under-documented systems where “core concepts” leak everywhere (AWS, NVIDIA tooling mentioned).
Tools, IDEs, and Programming Experience
- Some feel IDEs haven’t fundamentally improved in decades; coding still feels the same, only libraries/docs/QA have improved.
- Others counter that editors like Vim/Emacs with LSP, panes, macros, and live feedback already solve many pain points (multi-file views, refactors, error navigation).
- Visual / graph-based programming is viewed skeptically; graphs quickly become unreadable at scale.
- Interest in live programming (Smalltalk, Lisp-style REPL workflows) as a missed opportunity, but concerns about reproducibility.
Frameworks, Scaffolding, and Generators
- Split views on scaffolding and project generators.
- Critics say they hide concepts, generate opaque boilerplate, and make code harder to understand and maintain.
- Supporters argue opinionated scaffolding is invaluable for non-experts and complex domains, enforcing structure and reducing user error.
- Some see heavy frameworks as primarily benefitting employers (commodity hiring) rather than developer craftsmanship.
Code for Humans vs Computers vs AI
- Broad agreement that code is primarily for humans; machines only need low-level instructions.
- Emphasis on clarity, naming, structure, and documentation as the real hard work.
- Some speculate LLMs might eventually bypass traditional languages, but today they are buggy, average-quality coders at best and require strong human guidance.