Challenging projects every programmer should try (2019)

Original Article ↗ Hacker News Discussion ↗

A popular list of “challenging projects every programmer should try” — from text editors and toy operating systems to emulators and ray tracers — prompts debate over what kinds of side projects actually build valuable skills. Many argue that reimplementing fundamental systems deepens understanding of how software and hardware work, while others contend that modern software engineering is more about choosing libraries, managing complexity, and working in teams than about low-level implementation. The thread also surfaces broader questions about work–life balance, the difference between “programmer” and “software engineer,” and the risk of both over‑relying on third‑party code and falling into “Not Invented Here” habits.

Projects vs life balance / non-computer hobbies

  • Some argue “every programmer should” lists are grating; work is demanding enough and free time should not be prescriptively filled with code.
  • Several advocate for hobbies completely unrelated to computers (woodworking, gardening, music, hiking), and explicitly remind readers to “touch grass.”
  • Others note that outdoor/physical pursuits and deep programming projects are not mutually exclusive.

Difficulty and scope of suggested projects

  • Disagreement over whether a Game Boy emulator is harder than a “little OS”; some say OS is harder, others say an emulator with precise timing and edge cases is tougher.
  • Ray tracers are seen on a spectrum: a simple weekend ray tracer vs multi-month, production-grade systems. Likewise, “web browser” can mean text-only vs full modern browser.
  • Many emphasize that for learning, you can stop at a minimal, working subset rather than full fidelity.

Additional project ideas

  • Common suggestions: search engine + crawler, CAS (computer algebra system), ray tracer, search engine-like text search, simple HTTP wrapper, web framework, Netcat clone, memcached-like cache, mini-database, file system, basic Docker clone, mini OS via xv6, simple MMOs, robotics, drones, CFD / fluid dynamics, inverted pendulum robots.
  • Security suggestions include buffer overflow and SQL injection labs, Wireshark exploration, and CTFs.

Programming vs software engineering debate

  • One camp: toy compilers/OSes/editors improve “programmer chops” but not “software engineering” (library selection, large-scale design, maintainability, optimization tradeoffs).
  • Counterpoint: you can’t be a strong engineer without solid low-level foundations; implementing things teaches when not to reinvent them.
  • Strong back-and-forth on Big-O: some say rarely relevant in CRUD apps; others blame ignorance of complexity for slow, bloated software.

Not Invented Here vs learning by reimplementation

  • Many defend reimplementing editors, search, DBs, etc. as “recreational programming” and a way to understand systems deeply.
  • Critics call it NIH and argue modern systems (e.g., search engines) can’t be sensibly built fully from scratch and must integrate existing libraries.
  • Several stress balance: write from scratch in hobby projects, but be pragmatic and selective with dependencies in production.

Text editors, data structures, and usability

  • Debate over storing text as arrays vs ropes/piece tables: some report array-based editors are fine up to megabytes; others warn about pathological edits and giant files.
  • Multiple people argue editor usability and correctness matter more than micro-optimizing internal data structures.
  • Rendering only visible text and handling huge/long-line files efficiently are cited as real challenges.