The best writing advice I ever got


Someone recently asked me how long I spend writing these blog posts, and off the cuff my response was that they went pretty quick, but some could take up to 30 minutes to write. They seemed really surprised it was so fast.

This is a learned skill. I’ll tell you how I worked up to it. Maybe it will work for you also?

About twice a month, I’ll get someone coming to me to ask for career advice. I’m starting to collect the more common questions and my thoughts on them. I’m putting these together as a series of blog posts under the tag CareerPlusPlus.

How I got kicked into gear

One day the person managing the project I was on came in to talk to me about a review I had written for our funders. He basically told me the entire thing was garbage, and he’d have to throw it out completely and start from scratch if I didn’t fix it.

His primary complaint? You’re trying too hard.

He said something along the lines of “When I talk to you the things you say make sense. You’re clear. You’re concise. Your writing is garbage. JUST WRITE DOWN THE WORDS YOU WOULD SAY. Don’t try to write in a certain style or have a special voice. Just write down exactly the words you would tell me if you were talking directly to me.”

It was a bit harsh, but I deserved it.

Get ye to this book

Write to the Point by Bill Stott. You have to be careful, though. There are a bunch of books with the same title. The Bill Stott one is the one I recommend. I don’t know about any of the others.

I’m generally not big on book recommendations, except I think in this blog series I’ve already given out three. So maybe I am? But I do think I’m about to tap out my short supply of book recs very soon.

Anyways, this is the best book about writing I’ve ever read.

How to do it

Ok, start with your blank page. Don’t write anything yet, but just fill out 3 headers for major sections. DON’T TRY TO SPIFFY UP THEIR TITLES. It should just be exactly what you’re going to talk about.

For example, I recently did some work on DataFusion’s rendering of tables in Jupyter notebooks. There’s nothing special about that, but suppose I wanted to write up an article about it. Without trying to hard, I’m going to think to myself about what are the 3 most important things or hardest things I had to do were.

  • Making scroll bars
  • Limiting the cell entry when they’re too long
  • Letting users know when there’s data missing

That’s it. I’m ready to start writing.

Why 3?

Why not? I don’t know. 3 works. Just do it. Also, you want to do 2? 4? I swear I’m not checking your work. I’m telling you what works for me.

But 3 is a magic number. I’ve used it in other blog posts, both implicitly and explicitly. 2 is too few and 4 is too many.

Fill out sections

Now I go back up to the first heading. I’m just going to write with no special language what I did. I’m not going to justify it yet. I’m just going to talk about my actions. Why? Because that’s the easiest thing for me to do. It’s also frequently the least useful. But that’s okay. I’m not trying to write a perfect document. I’m trying to get all my plain language words out of my mouth and onto the electrons.

Now, if the reason for doing it is flowing freely, write that. Don’t limit yourself to my method if you’re ready and know what you want to put down.

So I would start writing something along the lines for the first section of this:

I had a problem that when I was viewing a DataFusion table sometimes it took up pages and pages of my Jupyter notebook that was making it unreadable. I updated the code that generates the html for this view to just be within a <div> that has scroll bars enabled.

The point I’m trying to make is that I’m not going to spend a lot of time trying to write from a certain persona. I’m not going to try to sound smarter than I am. I can even put my mistakes right out there in the open.

I just do a word dump into each section, one after another. Start with the part that is easiest for you to write. If you’re really good at intros, write an intro. If you’re really good at conclusions, start there. Most technical people I know are best at writing down the specific things they did. So I start there.

Writing the part that is comfortable and you’re best at will help you get past that writer’s block of starting out.

Review and fill the gaps

Sometimes I just do a quick once over and hit send.

If it’s more important, I’ll go back and ask myself what’s missing. When I do this I really try to put myself in the mind of my audience.

One trick: I think of myself as my future audience for blog posts. Side note: this week, I used one of my old blog posts to copy & paste into a work thing I was doing. So there’s benefit (to me) to writing to myself.

Don’t let the perfect be the enemy of the good

I say this all the time, because I find in the technosphere people are always avoiding doing things if they aren’t perfect. Some people just focus on finding problems and not decent solutions.

If I waited to have perfect prose and cover every possible angle, I’d never get these things published. I shoot for “good enough” and often when I remove the pressure the words flow more easily.

Closing thoughts

I hope that’s helpful. I’d read that book. And practice is really what it takes. Write simply. Speak out loud to a rubber duck. Then put the words you told the duck into your text editor, word for word. Don’t try to make it fancy. There’s time for that later if it’s really necessary.

When I stopped trying to write like I think it should sound and started speaking plainly in my writing, I got a ton of positive feedback on it. I hope you find the same.

I actually timed this one: almost exactly 20 minutes (but it’s a short article).