WORK IN PROGRESS

Situation

You are a software developer.

Approach

Read the book Grokking Simplicity by Eric Normand.

Rationale

I tried to write up a beautiful argument on why Grokking Simplicity is better than The Pragmatic Programmer, Clean Code, TDD and all the other stuff on how to program better. And how the latter books miss the point. But that would be controversial and hard and I just don't have the time. So I'll give you a disjointed list of thoughts. And hope that you have enough confidence in me that you pick up the book and give it a shot.

  • When I look at the code of others, the greatest problems with it stem from not applying the principles in Grokking Simplicity.

  • Oh no, the book is almost 600 pages long! Yes, but it's not that dense. There are many pictures and repeated examples. And the more advanced you are, the more you can skip. It's not the kind of book where you skip one exercise and completely lose track.

  • I don't know whether the book will be compelling to someone who doesn't already know its contents. This is a strange statement. The fact is that I had learned many of the things in the book over time and from various places. This limits my ability to judge whether someone new to them could learn them from the book. I certainly hope so, because it would be tough to persuade people to work through a long list of podcast episodes, blog posts and presentations.

  • After you get a few chapters in, you might start to wonder: ‘This is all nice and good, but I'm stuck at work with this codebase that doesn't follow those principles.’ – Read the last chapter. It will give you some ideas.

  • Growing a language is a skill that I consider very important and which is taught in the book, but not in enough detail.

    – I had learned them from the old presentation When Code Cries, from Eric's podcast and newsletter, from Paul Graham's TK, from Guy Steele TK etc. – And I didn't know any condensed source to point people to. When I read Grokking Simplicity, I recognized it as the thing I was looking for. And I hope that it will do for others what the scattered sources did for me.

When you start wondering, ‘This is all nice and good, but how do I apply this in X codebase, which doesn't follow these principles?’, read the last chapter. Cf. Andri.

It's a big book, but much of it is examples … not like a dense 500 page book.

Then read:

  • Paul Graham's TK
  • Guy Steele's TK └ The book contains the ideas behind these. But these provide another angle, which I find useful.
  • Cite especially the section from Steele about deciding to not add certain things to the language. And about making the words not too long.

Rationale

It contains all the things I wish every programmer knew but few do. It contains the essence of writing good code. For sure, there are many more things to learn. But this is the core. It's the core that many books and concepts like The Pragmatic Programmer or Clean Code or TDD aim at and miss because they haven't understood it. (Cf. domain modeling. Their model doesn't match the real world as well as Eric's does.) edit: They talk around it.

Note that I don't know whether the book will be compelling to someone who doesn't already know its contents. This is a strange statement. The fact is that I had learned many of the things in the book over time and from various places. This limits my ability to judge whether someone new to them could learn them from the book. – I had learned them from the old presentation When Code Cries, from Eric's podcast and newsletter, from Paul Graham's TK, from Guy Steele TK etc. – And I didn't know any condensed source to point people to. When I read Grokking Simplicity, I recognized it as the thing I was looking for. And I hope that it will do for others what the scattered sources did for me.

By the way, the Paul Graham thing and Guy Steele thing are worth reading/watching in addition to the book. They give a slightly different perspective on stratified design.

The next step after learning to program is learning to program well. For this you will find a number of classic guides. Unfortunately, many of them miss the core of programming well. Fortunately, there is one book, Grokking Simplicity by Eric Normand, which hits it. At least as best I can judge from my level of programming skill.

Why do I think so?

What is the catch?

What then?

Many have learned programming to the point where they understand if and for and function calls, and can make the computer do what they want. Few know how to structure code so that it is easy to work with, over time and at large scale. How can you learn to structure code well? For a start, I suggest a book, an essay and a talk, in this order.

Grokking Simplicity

Grokking Simplicity by Eric Normand teaches all the things I wish every programmer knew, but few do. At least judging from the code I've seen. Other sources, such as The Pragmatic Programmer, Refactoring or TDD try to teach these, too, but they don't hit the heart of the matter. Instead they focus on heuristics like function length and proxies like testability. Grokking Simplicity hits the heart of the matter.

It is almost 600 pages long, but those are not the heavy pages of Skiena's to Algorithm Design Manual. Rather, they are light pages with many pictures and repeated examples. And the more advanced you are, the faster you can move. It's not the kind of book where you skip one exercise and completely lose track.

Finally, you can start applying what you learn from this book in any existing codebase. No rewrite from scratch required. If you wonder how as you start reading, I suggest reading the last chapter first. It will tell you.

Programming Bottom-Up and Growing a Language

Growing a language is a skill that I consider very important and which is taught in Grokking Simplicity. But in my experience, two more things are required to make it stick: Read Programming Bottom-Up by Paul Graham. And watch or read enough of Growing a Language by Guy Steele (YouTube) to get the point. (If you have the time, I recommend you watch or read it all.) I'm lazy to argue why these are the things to read/watch. They are short enough to speak for themselves. But I'll leave you with a thought from Growing a Language, which might otherwise be overlooked:

I had to take time to think through how to phrase each thought. And there was this choice for each new word: is it worth the work to define it, or should I just stick with the words I have? Should I do the work of defining a new word such as mirror, or should I just say “looking glass” each time I want to speak of one? (As an example, I was tempted more than once to state the “ly” rule for making new words that change what verbs mean, but in the end I chose to cast all such words to one side and make do. And I came that close to defining the word without, but each time, for better or for worse, I found some other way to phrase my thought.)

I learned in my youth […] that it is better to choose short words when I can. […] I should try to make my thoughts clear; if they are clear and right, then other persons can judge my work as it ought to be judged.

[…] Short words work well, if I choose them well.

clojure.core

tbd

Or structure like this?

  • Grokking Simplicity
  • Programming Bottom-Up + clojure.core
  • Growing a Language
    • Especially for the short words point.

Notes