Share, don’t tell
How to write articles and not feel like a conceited prick
I used to be afraid to publish articles because I thought I wasn’t worthy of being a “thought leader”. I thought, “what makes me qualified to tell other people how to do this?” Or worse, “what if the stuff I write about is wrong, or not the best way to do something?”
This anxiety would weigh on me, and it often led to me never publishing a lot of valuable content.
When I started working with people in The Side Project Accelerator, I immediately realized that I wasn’t the only one with this fear. Most of the members of the first batch admitted to having at least some version of this fear too.
We all acted as if there was some sort of thought leader application process, and the jury was still out on whether or not we had made the cut.
Well, the jury is still out and it’s not coming back any time soon. No one is ever going to mail me an official thought leader license, and I got tired of sitting around waiting for it.
So I started writing and publishing articles on Hacking UI. I just took a Herculean leap of faith, told myself that everything was going to be OK and that I needed to stop worrying about it. I pushed that fear aside and stopped it from preventing me from getting myself out there.
However, even though I pushed on I still had this unrelenting tinge of anxiety that I wasn’t qualified to be writing about these subjects. That anxiety lasted until I found a way to adapt my writing style and feel completely comfortable with what I had written.
I got over my fear by sharing my actual experiences and refraining from saying that my way is the right way or the only way to do something.
This is done partly by modifying the voice I project and the vibe of the article, both fairly abstract concepts. But more practically, I also do this by being conscious of how often I write in second person. Second-person narrative is when you write addressing the reader with the pronoun “you” (like I did in that sentence). I look out for any usage of second person and ask myself if I could flip that sentence to first person and share something from my own experience.
I find that when I write in second-person it feels more like I’m commanding the reader. It can add a subtle vibe of condescension, or imply that an alternative method is wrong. It also usually leads to me speaking with more generalities rather than concrete examples.
Take a look at these two sentences for example:
- If you use long names for CSS classes, your code is easier to understand.
- I use long names for my CSS classes and it makes my code easier for me to understand.
The first version is very similar to a sentence you would see in a lot of articles about coding. While it works, and it does deliver its message, it can suggest that using short names for CSS classes is a bad practice. In the second version, I explain that this naming method works well for me and helps me.
Naming is one of the most heated and subjective debates in all of programming, and if I’m going to throw my opinion into the ring, I’m almost certainly going to get backlash from proponents of the opposite side. It’s not that I’m afraid of the backlash or worried about getting my feelings hurt. I feel that if I write using my own experiences it eases up the initial tension from someone who believes the opposite is true and makes for a more convincing argument.
Sharing my own experiences also forces me to question if this is really something worth sharing. It makes me pre-qualify the topic because I have to ensure that I have a good enough example to make my case. If I don’t have that example, or I can’t write about something that really happened to me, then it’s a giant red flag and tells me to rethink my topic.
When I share rather then tell, I feel more confident in my work and can fully stand behind what I wrote.
David Tintner is the CEO of ThoughtLeaders, co-founder of Hacking UI. He writes about web development, entrepreneurship, side projects, and whatever else comes to mind.
