Louis CK paid a moving tribute to the late George Carlin: His story of how Carlin influenced his life and career is poignant, and it speaks to a very deep truth about the importance of writing.
At one point when Louis CK was struggling, he was delivering the same fifteen year-old material. He noticed that Carlin was not telling fifteen year-old jokes: Carlin threw out his material every year and started fresh with a blank sheet of paper.
This constant renewal of material forced Carlin to constantly observe life, to constantly find insights, and to constantly invent new ways to hack past all of our filters and defenses, using jokes to help us face the uncomfortable, surrelistic, or just plain oddball things we humans do.1
Louis CK’s career and life changed when he comitted to renewing his act, to throwing his existing jokes out and regularly facing a blank page. He describes this as forcing himself to go deeper into his hopes, fears, and even the things he dreads. Throwing material out and starting fresh does more than just improve the material, it improves the comic as a human being.
It’s very powerful.
I feel like there is a parallel between comedy and other forms of writing. For me, the main thing in writing something for the first time is the observation, discovering something and working out what it means. Writing about an idea is a way of manifesting it. It’s a forcing function that gets me to explore an idea in some reasonable depth.
If I share that writing, perhaps as an essay on the internet, perhaps it’s a talk I give at a conference, I have an audience who can critique the idea. This forces me to make some reasonable standard of quality. I don’t mind being wrong, but I don’t want to embarass myself. An essay might read like stream-of-consciousness, but it shouldn’t read like drunken raving.
But really, truly, the big work of writing for me is taking an idea from a glimmer to exposition. That is hard work, I have spent weeks full-time getting a conference talk to flow. But that work is mostly thinking and organizing. For me, the performance part of a presentation at a conference is just the “tip of the iceberg.”
For example, my Webrebels keynote “I have a good feeling about this” took me weeks to prepare, and it was over in forty-three minutes:
I don’t give presentations more than once, so the preparation time isn’t amortized over multiple performances. Furthermore, I can’t refine presentations, or incorporate feedback, I don’t become more comfortable delivering the talk because I don’t give myself a chance to get comfortable.
I always ad-lib the specific words, I don’t work off a script. If something feels awkward, I have to just plow ahead. If you watch the whole thing, you’ll see there was a techncial problem with the A/V, a problem I might have been able to prevent in future performances.
By only presenting a talk once, I maximize the observing and writing. I also minimize the performance. The net result is good for me, because I’ve grown as a person by going through the writing process. By never giving the same talk twice, I’ve grown as a person by forcing myself to dig deeper and find things that matter to observe.
I write for myself.
Ricky Gervais, Jerry Seinfeld, Chris Rock, and Louis CK talk about repeating the same material. They agree that people who haven’t seen an act before get more out of it than people who saw the first performance, because comedians polish their acts, they remove the bad bits, they move things around.
There’s a tension between renewing material and polishing material. Carlin threw away his material every year. Jerry Seinfeld has a different approach, he’s a perfectionist. He says he has some material that’s several decades old, he’s still working on being able to deliver it perfectly, with the right timing, the right intonation, the right anticipation of the audience’ reaction. That doesn’t make him better or worse than Carlin, it makes him different. He emphasizes performance over observation.
With talks, I believe that the audience benefits from speakers that spend more time on performance. Some speakers I know deliver the same talk many times. They are terrific performers. Some excellent speakers—Denise Jacobs comes to mind—have given me great feedback on how to be a better speaker. They rarely say anything about my material, but boy do they spot a lot of ways I could improve my delivery.
That matters. Better delivery communicates the idea better. That means the audience benefits. Audiences win when speakers are great performers. By performing more, I’d be a better speaker. By iterating over the same talk multiple times, I’d give better talks.
To me, giving the same talk multiple times is like “rewriting.”2 Fixing bugs, moving things around, dropping inessentials. Rewriting makes writing better. In the case of talks, it makes performance better. Rewriting is a massive win for audiences.
I rewrite for others.
In software, it’s the same damn thing. The first go-‘round of an idea is like crack cocaine for the puzzle-solving mind. That first algorithms written solve the big problems. The first iteration of a product establishes whether there’s something there that the market wants.
Writing software is something I very much do for myself. And my selfish toddler brain wants to finish writing and then walk to start writing something else. The little child in me wants to spend all his time writing software, and as little time as possible rewriting software. And that’s exactly what I do with my libraries and side-projects. I wrote most of them for myself, to explore ideas, to observe phenomena, to discover the possibilities.
But just like talks, rewriting is where we build value for people that use what we write. It’s when we fix bugs, things that usually aren’t a major part of the idea, but need to be fixed for someone to use the product. Rewriting is when we clean up algorithms that felt like accidental complexity, so we just slapped something in that worked. But now we make it fast, so we stop thinking about the idea and start thinking about the icky implementation of the idea.
And when we have colleagues, we submit a pull request and then get to rewrite the code to be more readable, to match our team’s style, to fit better with the code base. All things that add very little value to our personal understanding of the problem, so our urge is to stop doing that and move on to fresh writing.
But if we want to actually deliver value, we need to iterate. To practice. To rewrite. In software, rewriting is how we make value for people. By making small changes that matter to the people that use our work, even if making those changes don’t represent the most growth for ourselves as developers.3
If we find ourselves doing a lot of rewriting, but rarely push ourselves to write software, we probably need to get ourselves to start “throwing our material away.” Growth comes from taking risks, from starting with a blank sheet of paper, from staring at an empty whiteboard.
Whereas, if we spent a lot of our time inventing the future, but little or no time perfecting the present, we probably need to remember that Carlin threw his material away every year, not every performance. To maximize the value we create, we need to write and to rewrite. And to rewrite again. And again. And again.
It’s not glamorous, but it’s an inescapable truth: We write software for ourselves, we rewrite software for others.
Some distinguish “telling jokes to create humour” from “using humour to communicate observations.” I am speaking of the latter when I use the word “comedy.” ↩
In software, people often use the word “rewrite” to refer to a complete rewrite of an entire system. But the word “rewrite” can also refer to a rewrite of something as small as a single line of code. Or refactoring some code (“I rewrote the way we handle fubars to use the Observer pattern”). In this essay, I am using the word in a broad sense, encompassing revisions, tweaks, refactorings, bug fixes, anything that involves writing some or all of something again. ↩
EcmaScript-6 is incorporating a
class keyword. This is a classic example of rewriting and refining. It’s not a “big idea” like promises or even proxies. It’s not very hip: the people who don’t like OO complain about it being unecessary, and the people who like OO complain that it ignores recent research. Like most rewriting, it serves its users at the expense of its implementors, who’d probably be just as happy figuring out how to add gradual typing to ES-7. ↩