SXSW session Notes: Programming and minimalism

“Programming and Minimalism: Lessons from Orwell & The Clash” by Jonathan Dahl

Programming is defining processes. Be a code craftsman – build good code, that can’t be commoditized. Develop habits and use tools that allow a craftsman do his or her job well. Work with good teams and develop good habits and practices. A good programmer can describe complex processes in a precise way.

Programming and similarities to music

Both work in an abstract way – the musician records the music in a notation that is an abstraction of the actual music, a representation (dots on a page). The coder also works in abstraction.

How music is created:

• Make something simple and interesting (like the hook of a song)
  • {build on it (loop)}
• End up with something enormous, stale and boring
• Trim the fat
• Repeat as necessary

The Dahl went into a musical history, which I don’t think would be as useful without the clips he played. But the gist was, music goes in cycles from simple to complex to simple again.

Simple -> Complex -> Simple -> Complex -> Simple -> Complex

It is operating well between the simple and the complex that leads to beauty.

Minimalism is a positive aesthetic.

Programming and similarities to writing

An essayist writes and rewrites, as a programmer codes and then refactors code to make it better.

Is language ambiguous? Is that the problem? Or is the problem that we don’t realize that language is imprecise, so we don’t take it into account?

There is not a 1:1 correlation between what we want and how it can be expressed in code, this is why coders are needed in the first place.

George Orwell the essayist

Read George Orwell’s “The politics of the English Language” – it connects poor writing to poor thinking.

Example: the US Patriot act. The name does not tell you anything, it co-opts your ability to think intelligently about whether it is a good idea. It should have had a title like “The expanded surveillance act.” The sloppy title inserts the idea beyond rationality into someone’s brain, and demonstrates sloppy, unclear thinking.

Bad writing is more prone to bugs. The presenter gave an example of terribly unclear writing that had a quadruple negative, one of which didn’t need to be there. Clear, direct writing makes it easier to follow the thinking and detect bugs.

Orwell’s rules:

1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
2. Never us a long word where a short one will do.
3. If it is possible to cut a word out, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than say anything outright barbarous.

Application to programming

• Minimalism
• Clear direct writing
• Take simplest approach to coding
• Clever code is bad code
• Any code not doing something is harming your product. If your users don’t need it, get rid of it.
• Accept constraints – work witht he language and framework when possible
• If something isn’t local business logic, it belongs in a library. (In MVC, model should not be huge)
• If it is not local, consider using open source
• Don’t over or under abstract
• Always actively clean up your code – otherwise your code is degrading
• Code tracker – always document what needs to be done
• Apply these rules wisely
• Simple code is beautiful
• Break hard problems down

Consume

• pair programming, hold code critiques, view other people’s code
• read good prose
• listen to good music
• study and learn

Produce

Good programming is:

minimal – direct – beautiful

Questions

Question: How to justify to stakeholders time spent on cleaning up code?
Answer: Don’t tell them. They hired you to do the best job you can, and the best is not broken spaghetti code.

Question: How do you deal with an organization love of complexity?
Answer: I didn’t record an answer for this one. If anyone thinks of something, let me know!