Eric Normand Newsletter 476: The start of a book

Free Beginner Workshop

From OO to Clojure Workshop!

Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.

Reflections 🤔

The start of a book

When I first started Grokking Simplicity, I was on a phone call with the folks at Manning Publications. They told me that they wanted me to begin with something that I thought should be done at the end. It really surprised me. And it was really difficult for me to do. They said it was important to their process. I should give it a try.

So I did. I gave it a try. I did my best. I put together everything I had thought about. I organized it as best I could. And I gave it to them to read. I thought it was pretty good. They didn't. It's not that they thought the book would be bad or anything. It's that the work I gave them did not really tell them what they were looking for.

They had a million questions. They were good questions, like "what are you going to teach about sets and hashmaps?" I had an answer. I had thought about it. But it was totally foreign to them. They liked it and saw potential. Just potential. Nothing we could use without a lot more work.

The thing they asked for was the table of contents (ToC). I complained: "I did what you asked! I listed all the topics and organized them." I asked them: "Why would you want me to do the ToC first, when it's obviously easier to do at the end?" They did answer: "You have an idea of what you want to write, and we do not. The ToC gives us at least an idea of the completed work before you start writing." But the deeper answer didn't become clear until several months into the work.

I see now why a ToC is helpful. That's why I started Domain Modeling with the ToC. I've completed a draft of the ToC for my new book and I've published it on my site. Read it here. I've also learned about the value of rich feeback while writing, so please tell me what's missing.

I was used to writing blog posts. Each post was a self-contained essay only loosely connected to the other essays on my site. I never had to think about creating a whole larger than each post. But with a book, it really does help me to understand the big picture of what I want to write. The ToC is that big picture. It helps you, the author, and the publisher plan the book.

My first attempts at the Grokking Simplicity ToC were crude. They were outlines of concepts, grouped together conceptually. I hadn't learned to see how a reader might experience the ToC, let alone an entire book of content. The folks at Manning, and especially Bert Bates, helped me understand all of the use cases of the ToC. Yes, we really did talk about it that way. In the end, I learned a ton about writing to teach. So why am I self-publishing this time around? Well, that will have to wait till next time.


The power of runnable specifications 🎙

My latest podcast explores the advantages of writing a spec directly in your production language.


An Intuition for Lisp Syntax 📖

An interesting take on why Lisp syntax is the way it is, through the lens of writing interpreters. I'm not so convinced about homoiconicity as a supreme virture. But I do think it's important that you be able to write interpreters easily.


Teach Yourself Programming in Ten Years

Peter Norvig's classic essay is an important reminder about the value of mastery.


Java to Kotlin Chapter 7

My actions/calculations/data distinction has found some new fans. Duncan McGregor and Nat Pryce are writing a book called Java to Kotlin and they explain their interpretation in Chapter 7, which they are giving away for free!


Grokking Simplicity 📘

You can order my book on Amazon. Please leave a rating and review. Reviews are a primary signal that Amazon uses to promote the book. They help others learn whether the book is for them.

You can order the print and eBook versions on Manning.com (use TSSIMPLICITY for 50% off).


Clojure Challenge 🤔

Last challenge

Issue 475 - Least common multiple - Submissions

This week's challenge

How many digits?

Imagine you took all the integers between n and m (exclusive, n < m) and concatenated them together. How many digits would you have? Write a function that takes two numbers and returns how many digits. Note that the numbers can get very big, so it is not possible to build the string in the general case.

Examples:

(num-digits 0 1) ;=> 0 (there are no integers between 0 and 1)
(num-digits 0 10) ;=> 9 (1, 2, 3, 4, 5, 6, 7, 8, 9)
(num-digits 9 100) ;=> 179

Thanks to this site for the problem idea, where it is rated Expert in Python. The problem has been modified.

Please submit your solutions as comments on this gist.

Rock on!
Eric Normand