# Awesome Minimalism Ideologies in Code

A curated reading list for the kind of software philosophy represented by
[suckless.org](https://suckless.org/philosophy/): small programs, few
abstractions, transparent behavior, restrained dependencies, and complexity
that is visible rather than hidden. This is **not** a list of “write less code”
slogans. Some entries disagree with suckless on portability, UX, or acceptable
trade-offs; all are useful lenses for deciding what complexity is justified.

## Core texts

1. **[The Unix Philosophy](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html) — Eric S. Raymond**
   - **Idea:** Build small, sharp tools; make programs cooperate through text
     streams; prefer transparency and simplicity to cleverness.
   - **Why read it:** The closest broad articulation of the ecosystem that made
     suckless possible. Treat it as a historical and practical catalogue, not
     a rigid law.
   - **Keywords:** composability, pipes, text interfaces, small tools.

2. **[Worse Is Better](https://www.dreamsongs.com/WorseIsBetter.html) — Richard P. Gabriel (1989)**
   - **Idea:** A design that is simple to implement and adequate at its
     interface can spread more successfully than a more complete but complex
     design.
   - **Why read it:** The classic case for implementation simplicity and
     incremental growth. It also explains a risk of minimalism: “worse” can
     become entrenched before its weaknesses are repaired.
   - **Keywords:** simplicity, adoption, incremental design, MIT vs. New Jersey.

3. **[Rise of “Worse Is Better”](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) — Richard P. Gabriel (1991)**
   - **Idea:** A follow-up reflection on what happened when simple, portable
     Unix-style systems won.
   - **Why read it:** Read immediately after the original for the author’s own
     qualifications and the social consequences of the thesis.
   - **Keywords:** Unix, portability, evolution, trade-offs.

4. **[A Plea for Lean Software](https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf) — Niklaus Wirth (1995)**
   - **Idea:** Hardware growth encouraged wasteful software; progress should
     favor economy, disciplined construction, and comprehensible systems.
   - **Why read it:** A direct, forceful manifesto against bloat from one of
     computing’s most influential language and systems designers.
   - **Keywords:** bloat, efficiency, discipline, comprehensibility.

5. **[The Rule of Least Power](https://www.w3.org/2001/tag/doc/leastPower.html) — W3C TAG (2006)**
   - **Idea:** Choose the least powerful language or mechanism that adequately
     solves the problem, because less expressive mechanisms are easier to
     understand, analyze, reuse, and constrain.
   - **Why read it:** A precise design rule for resisting unnecessary Turing
     completeness, configuration languages, and frameworks.
   - **Keywords:** least power, declarative design, analysis, constraints.

6. **[Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-Easy/) — Rich Hickey (2011 talk)**
   - **Idea:** “Simple” means not intertwined; it is different from “easy.”
     Complexity comes from complecting concerns, state, and time.
   - **Why read it:** The strongest vocabulary for arguing that a convenient
     abstraction is still a bad abstraction when it entangles independent
     things.
   - **Keywords:** simplicity, complexity, state, values, separation.

7. **[Out of the Tar Pit](http://curtclifton.net/papers/MoseleyMarks06a.pdf) — Ben Moseley and Peter Marks (2006)**
   - **Idea:** Accidental complexity is overwhelmingly caused by mutable state;
     reduce it with functional core ideas, declarative data, and controlled
     effects.
   - **Why read it:** A more formal companion to “suck less”: it identifies a
     specific source of software complexity rather than merely disliking size.
   - **Keywords:** accidental complexity, state, functional programming,
     declarative systems.

8. **[A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php) — John Ousterhout (book and free notes)**
   - **Idea:** Complexity is the central enemy. Design deep modules with simple
     interfaces, eliminate special cases, and invest in design rather than
     merely adding layers.
   - **Why read it:** An important corrective to naïve minimalism: fewer lines
     or smaller modules are not automatically simpler; a *deep* module can
     hide a large amount of coherent complexity.
   - **Keywords:** complexity, deep modules, abstraction, special cases.

## Short, sharp essays and engineering rules

9. **[The Best Code Is No Code At All](https://blog.codinghorror.com/the-best-code-is-no-code-at-all/) — Jeff Atwood (2007)**
   - **Idea:** Every line has ownership, failure, and maintenance cost; first
     ask whether the feature or mechanism should exist.
   - **Why read it:** The most useful minimalism test before implementing a
     “small” helper, dependency, option, or service.
   - **Keywords:** deletion, YAGNI, maintenance cost, restraint.

10. **[The Law of Leaky Abstractions](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) — Joel Spolsky (2002)**
    - **Idea:** Non-trivial abstractions leak details of the systems beneath
      them; pretending otherwise produces surprises and weak operational
      understanding.
    - **Why read it:** Supports suckless’s preference for visible mechanisms
      and inspectable source, while not claiming abstractions are useless.
    - **Keywords:** transparency, abstraction, operations, failure modes.

11. **[No Silver Bullet—Essence and Accident in Software Engineering](http://www.cs.unc.edu/~brooks/NoSilverBullet.html) — Frederick P. Brooks Jr. (1986)**
    - **Idea:** Software has irreducible essential complexity; tools can remove
      accidental complexity but cannot make difficult domain problems vanish.
    - **Why read it:** A guardrail against cargo-cult minimalism. Remove
      accidental machinery, but model essential domain complexity honestly.
    - **Keywords:** essential complexity, accidental complexity, realism.

12. **[The Power of 10: Rules for Developing Safety-Critical Code](https://spinroot.com/gerard/pdf/P10.pdf) — Gerard J. Holzmann (2006)**
    - **Idea:** Deliberately restrict language features, function size,
      recursion, dynamic allocation, and unchecked assumptions to make code
      analyzable and dependable.
    - **Why read it:** Minimalism as an enforceable reliability discipline,
      rather than as aesthetic preference.
    - **Keywords:** constraints, verification, safety, C, static analysis.

13. **[How do we tell truths that might hurt?](https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html) — Edsger W. Dijkstra (1975)**
    - **Idea:** A program’s intellectual manageability matters; programming
      should reduce the gap between what humans can reason about and what
      machines execute.
    - **Why read it:** A compact philosophical foundation for choosing designs
      that fit in a human mind.
    - **Keywords:** intellectual manageability, rigor, programming practice.

14. **[The Unix Programming Environment](https://archive.org/details/UNIXProgrammingEnvironment) — Brian W. Kernighan and Rob Pike (1984)**
    - **Idea:** Make programs do one job well and join them with a stable,
      simple interface: the shell and text stream.
    - **Why read it:** The practical original for Unix-style composition; use
      it alongside the Unix Philosophy rather than treating later summaries as
      the source.
    - **Keywords:** shell, filters, composition, interfaces.

## Kevlin Henney: enterprise-software perspective

15. **[1968](https://www.youtube.com/watch?v=wi66pDC47J4) — Kevlin Henney (SCLConf 2018)**
    - **Idea:** Much of modern enterprise software repeats problems that were
      already understood in the 1960s and 1970s. Revisit the era’s lessons on
      modularity, structured programming, and managing complexity rather than
      mistaking new tooling for progress.
    - **Why read/watch it:** A thoughtful antidote to enterprise novelty and
      architecture fashion. Henney’s point is not nostalgia or rejecting
      scale; it is that software should remain understandable despite scale.
    - **Keywords:** enterprise software, history, structured programming,
      modularity, complexity.

## Recent sources (2020–2026)

This section is deliberately restricted to material published in the requested
time window. The window does not have an equally canonical successor to the
Unix texts; these are the strongest recent statements of the same values.

15. **[Rediscovering the Small Web](https://neustadt.fr/essays/the-small-web/) — Parimal Satyal (2020)**
    - **Idea:** The personal, hand-made, link-driven web is an alternative to
      centralized, algorithmically mediated platforms.
    - **Why read it:** A warm manifesto for software and publishing that stay
      small enough to be understood and owned by their makers.
    - **Keywords:** small web, personal publishing, independence, human scale.

16. **[Locality of Behaviour](https://htmx.org/essays/locality-of-behaviour/) — Carson Gross (2020)**
    - **Idea:** The behavior of a unit of code should be visible from that unit;
      avoid scattering a feature’s structure, state, and behavior across a
      project’s folders and layers.
    - **Why read it:** A concrete frontend architecture principle that reaches
      the same goal as suckless: make the mechanism obvious to the reader.
    - **Keywords:** locality, hypermedia, frontend, inspectability.

17. **[What is the Small Web?](https://ar.al/2020/08/07/what-is-the-small-web/) — Aral Balkan (2020)**
    - **Idea:** The web should preserve personal publishing and human-scale
      spaces rather than force everyone into surveillance platforms.
    - **Why read it:** Connects technical smallness to agency, independence,
      and decentralization.
    - **Keywords:** small web, independence, decentralization, ownership.

18. **[The Small Web Is Beautiful](https://benhoyt.com/writings/the-small-web-is-beautiful/) — Ben Hoyt (2021)**
    - **Idea:** Favor fast, plain, durable, independently published web pages
      over ad-tech-heavy and JavaScript-dependent sites.
    - **Why read it:** Applies the same values to delivery: a minimal program
      is not enough if its website, documentation, and distribution path are
      bloated.
    - **Keywords:** small web, performance, static sites, durability.

19. **[The Grug Brained Developer](https://grugbrain.dev/) — “Grug” (2022)**
    - **Idea:** Software complexity grows beyond any individual’s ability to
      hold it in mind; choose boring, direct techniques and resist cleverness
      that expands the cognitive surface area.
    - **Why read it:** Comic in voice but serious in diagnosis. It is a useful
      counterweight to architecture astronautics and dependency-driven design.
    - **Keywords:** cognitive load, boring technology, directness, complexity.

20. **[Slow Software](https://www.inkandswitch.com/slow-software/) — Ink & Switch (2023)**
    - **Idea:** Optimize development for reflection, quality, and long-term
      care rather than release velocity and feature throughput.
    - **Why read it:** Broadens minimalism beyond code size: a system remains
      humane when the organization leaves time to understand and simplify it.
    - **Keywords:** software pace, craftsmanship, maintenance, sustainability.

## Operational practice

21. **[The Twelve-Factor App](https://12factor.net/) — Adam Wiggins (2011)**
    - **Idea:** Keep deployable services portable and legible through explicit
      configuration, stateless processes, backing-service boundaries, and
      parity across environments.
    - **Why read it:** Not a minimalism manifesto, but a disciplined recipe for
      avoiding hidden environment-specific complexity in networked software.
    - **Keywords:** explicit configuration, portability, processes, operations.

## A compact synthesis

Use these texts as a sequence of questions, not commandments:

1. **Can it be deleted?** — Atwood.
2. **Can it be expressed with a less powerful mechanism?** — W3C TAG.
3. **Can independent concerns remain unentangled?** — Hickey.
4. **Does the interface hide one coherent capability, rather than conceal
   unrelated machinery?** — Ousterhout.
5. **Can a maintainer inspect, test, and reason about failure without learning
   a framework’s private universe?** — Spolsky, Dijkstra, Holzmann.
6. **Does the remaining complexity belong to the domain, or did we introduce
   it?** — Brooks, Moseley, Marks.
7. **Will the software stay small in distribution and operation, not only in
   its source tree?** — Wirth, Small Web, Twelve-Factor.

## Important tension

Suckless-style minimalism is most valuable when it removes **accidental**
complexity. It becomes harmful when “small” is used to reject accessibility,
security, internationalization, reliable error handling, documentation, or
real domain requirements. A good minimal system has the *fewest concepts that
still make the correct behavior clear and dependable*.