Janine: I bet you like to read a lot, too.

Egon: Print is dead.

Janine: That’s very fascinating to me. I read a lot myself. Some people think I’m too intellectual.

—Ghostbusters (1984)

Learn how to learn

A quick recommendation: Learning How to Learn is a popular Coursera course co-taught by Dr. Barbara Oakley, professor of engineering at Oakland University. I liked it so much I got Dr. Oakley’s book, A Mind for Numbers: How to Excel at Math and Science (Even If You Flunked Algebra).

Remember when I wrote about packaging your book? This is a book about learning deep, difficult concepts—period. Unfortunately, the title sends the wrong impression. Sure, Oakley draws stories and examples from the sciences, but the advice applies equally to the task of absorbing any demanding subject.

The book itself is anything but demanding, a light and compelling read I’d comfortably recommend to a middle school student. Let alone a brilliant and accomplished professional like yourself.

Oakley’s next book is Mindshift: Break Through Obstacles to Learning and Discover Your Hidden Potential. (Clearly, someone at her publisher read my essay on book packaging and took the hint.) Rather than wait until April, just get this book and replace every mention of “chemistry” and “quadratic equations” with “Lacanian psychoanalysis” and “social cognitive theory.” Or whatever ridiculous doorstop you’ve been brandishing on the subway to impress the other nerds. Personally, I can’t wait to read Mindshift, too. Oakley is my new guru.

Writing is hard

He spoke so softly. I was awestruck: the guy’s the editor of

The New Yorker

…He explained everything with absolute patience, going through seventeen-thousand words, a comma at a time, bringing in stuff from the grammarians and the readers’ proofs. He talked about each and every one of these items with the author. These were long sessions. At one point I said, Mr. Shawn, you have this whole enterprise going, a magazine is printing this weekend, and you’re the editor of it, and you sit here talking about these commas and semicolons with me—how can you possibly do it? And he said, It takes as long as it takes.

—John McPhee interviewed in The Paris Review (2010)

If there’s one thing I need to be reminded of on a daily basis, it’s this Shawnian gem. It takes as long as it takes.

My fatal flaw is that I’m always trying to optimize. My idea of a good time is getting wired on caffeine and flipping through Tools for Titans looking for the “tactic, routine, and/or habit” of a “billionaire and/or icon and/or world-class performer” that will help me finish a damned chapter outline on time.

I always think there’s some way to get this newsletter written faster. I’m always wrong. The best advice I can give myself is simply this: writing is hard. That’s what makes it valuable, after all. I’m comforted by the fact that as a writer, I won’t be replaced by an AI until milliseconds after those in other occupations have been “deleted.”

(For the record, milliseconds is a very long time for AIs. Our new robot overlords are going to deliberate quite a bit before sealing us writers into our pods and using us as batteries.)

David Heinemeier Hansson, a.k.a. DHH, creator of Ruby on Rails, founder of Basecamp (formerly 37signals), and author of Rework, wrote a post entitled “Writing software is hard”:

Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked—just shocked!—when the expectable happens and the software we’re exposed to or is working on turns out poor.

This is classic cognitive dissonance: Accepting that writing software is hard, but expecting that all of it should be good.

Holds true for writing, as does most good advice about programming, I’ve found.

It’s also an application of a just-world theory of effort and accomplishment. That despite the odds, everyone who has the right intent at heart, and puts in the work, will succeed. No they won’t. That’s just delusional.

Oof. Yes.

And those delusions are anything but harmless. When we expect good software to be the most likely outcome from the hardship of writing it, we’re setting ourselves up for inevitable disappointment. Even worse, if we feel we deserve good software from our imperfect efforts, we’ll project the inevitable failures on everyone and everything but ourselves.

You’re seeing the parallels here, I hope. I could say all this stuff to you myself, replacing “software” with “books,” but that would be plagiarism. And I would never plagiarize. The last thing I need is to become a New York Times bestselling pop psychology author and have to go brag about my amazing humility on a panel at the New Yorker Festival after my plagiarism is discovered.

With a few exceptions, the rest of DHH’s essay applies and is well worth reading. One more bit to chew on:

I’d like to see fewer people get stuck at the plateau. Life is just more interesting when you keep climbing. And you’re more likely to do that if you accept the odds: You will write poor software for a long time. If you accept responsibility for this, you stand the chance to write that which is at least poor in new and exciting ways, but most likely better too.

“Poor in new and exciting ways” = my new motto.

Yeah, so, writing is hard. I try to set expectations with each of my clients about what to expect from process and yet it still always comes as a shock to them (and to me) what an endeavor the book turns out to be.

This is not to discourage you. I find it energizing myself. So much of the advice out there takes the position that somehow—with the right schedule, the right apps, the right mindset—you can somehow “crank” out a book. Good habits may keep a blog humming, but they won’t get you to the top of this particular mountain. Which makes it worth climbing, the way I see it.

Writing a book is hard. It’s going to push you to your limits. At times, it’s going to hurt. It will also be well worth it. Brace yourself.