programming and minimalism — lesson from orwell and the clash

[SXSW Bio]

  • @jondahl


Programming is writing. A programmer’s job is to express abstract ideas in a specific language – just like the poet, the essayist, and the composer. But while writers and composers spend years improving their style, many programmers think style stops with “two-space indentation”. This needs to change. This presentation will discuss style in music, writing, and software. We’ll look at such diverse sources as George Orwell, Mozart, and punk music, and will find that much of art revolves around complexity and minimalism – just like software. Finally, we’ll look at specific patterns and tools for writing software that is not just effective and efficient, but stylistically beautiful.


  • Pragmatic Programmer (Hunt, Thomas)
  • Politics and the English Language (Orwell). “Sloppy writing” is a key tool of propaganda (and is more prone to error.)


Programming is about process. Defining complex processes in a precise way. “Computers are where our programs live, but not what programming is.”


An engineer uses rigorous thought toward building things (design instructions; noun) but programmers are engineers that build processes (verbs). Defining stuff that makes stuff happen. Solves problem through design, invent new tools.


“Craftsmen” focus on tools and skill (look to build things better not just to code). Work in teams. Develop habits and practices that bring out their “best”. Creates environments in which hard problems can be solved.


Writing is transcribing ideas into language to effectively communicate; programming involves composition that turns into a running application. Language requires an awareness of its ambiguity and imprecision, and requires context and delivery to discover meaning. (Vichtenstein?). In the same way, there are many different ways to write code (as there are many different ways to reflect ideas in language). Therefore, style matters. Style matters (art, music, writing, and programming). What is good programming style?

Style goes through a cycle of simple idea that’s built upon (over and over) until it is weighty and must be trimmed back to simple while retaining “the best”. A continuous cycle between simplicity to complexity and back. The artists that can navigate this cycle well are the ones that create beauty. Minimalism is not “less” it’s a positive growth where you have something better than before.

Music Cycles

Baroque -> Classical -> Minimalism. Growth of symphonies. Change in abilities of instruments. Change in idea scope compositions are based on. Change in length of music. Rock: Beatles Pop -> Led Zeppelin -> Rush -> The Clash (Punk).

Clear writing leads to clear thinking. Take a minimalist style. Using complex styles to express complex thoughts contains no beauty/elegance. Use clear, direct (active voice) code to enhance understandability.

  1. Always take the simplest approach to a problem.
  2. Clever code is bad code.
  3. Any code that isn’t doing something is harming your project.
  4. Accept constraints (of a language/framework).
  5. If it isn’t local business logic, it should be in a library. And consider using an open source library when things are not critical to core functionality.
  6. Don’t over-abstract. (When to create a method)
  7. Always actively clean up. Constantly. Code will stagnate and become incomprehensible as the language moves on.
  8. Apply these rules wisely. Use your judgment on when to break these rules in the right circumstance.
  9. Simple code is beautiful.
  10. Break hard problems down (into simple ones that you understand or have done before). Writers approach to complexity.

How do you become a good writer/programmer? Consume good writing/code (Crucible). Seek for good composition in many realms (art, writing, music, etc.) to influence yourself. Study how to program well. Produce (practice by production). If we aren’t actively writing code, we aren’t going to get better.


Code Critique/Review? Every bit of code (or a diff) should be looked at by at least one other person. Or a global diff before each release.

Justify code improvement to non-technicals? Don’t tell them. Non-technicals shouldn’t be approving the process it takes to improve/write great code. Build all the habits and processes that built a craftsman’s environment into the contract/timeframe.

User experience of developers writing code inside a language/framework. “Dialect” of individual programmers/teams.