5 weeks ago I set out to write at least an article on software development every day. What follows are the ups, downs, and lessons learned from that process.
So, first of all, why would I do this? Well, a month ago I applied to speak at my first technology conference. Though I'm a very experienced professional, I do not frequently change jobs and have worked primarily for small to medium-sized Software as a Service organizations. Therefore I'm not widely known, even in the area.
Since I have a message I want to get out there, I decided to write every day prior to the cutoff for speaking abstracts, just so organizers could get a sense for who I am, what I care about, and how I think.
The plan was to write 7 articles and call it at that.
This is now my 36 published article, following a streak of writing at least one article a day since August 27th.
My first week consisted of writing articles on Medium to little or no viewership.
Since my primary audience was a small handful of organizers curious about who I was, I didn't care that much if the general public wasn't clamoring over what I had to say, but I did find that writing was resonating with me and that I still had more to say.
Then an awesome member of the local development community suggested I check out dev.to, a blogging platform centered around developers and other technologists.
I ported my week's worth of stories onto the platform and got immediate viewership, enthusiastic support and encouragement from readers as well as assistance promoting my articles from the staff.
This encouragement gave me more energy, and seeing what resonated and didn't resonate with people helped me tune and improve my own writing style and topic selection.
This is also exactly when my writing moved from something centered around a hope to be taken seriously for a conference to something centered around teaching, learning, and sharing in a community.
With the continued practice and added feedback of the community, my skill continued to improve to the point where I began to be selected by publications and Medium's own curators on the Medium platform.
While my viewership numbers aren't fantastic for a professional blogger, I'm a professional developer who just wants to share more, so seeing that my work is making a difference in others is huge - particularly for someone with a heavy bent on teaching.
So, let's talk some specifics about this journey.
I've gotten a lot of comments on how things have been helpful, helped people understand concepts more clearly, or given people new ideas, and that's made it all worth it.
I must humbly say that I had not understood how truly global the software development community really is. It simply wasn't one of the things I thought about. And every night, almost without fail, I would publish an article in the early reaches of the morning and go to bed and wake to find hundreds of views already as well as comments, reactions, and follows from people of all nationalities.
My lack of understanding for how global this community is was staggering and correcting this was perhaps one of the best things that came out of writing this way.
This thrills me. Now I'm not just helping junior developers in Ohio, but people throughout the world with problems far more severe than the local ones. If I can take a small part in equipping and encouraging the global community to do the things their minds are set on, we'll all be better for it.
Speaking of community, I've encountered some really great people. You see the same people commenting on posts again and again and you begin following more people on twitter and soon, they're a part of your life and you're being encouraged by them (and hopefully vice versa).
Related to that, the comments people can leave will often tell you about things you had no awareness of whatsoever or give you new insights or ideas to try.
Additionally, the act of writing an in-depth article will force you to deepen and broaden your own understanding of a subject, as well as think about how to best communicate it in a way people can teach. I did this with my SQL Server series and really grew my own skills significantly in the process.
The act of writing and releasing something small every day helps focus and improve the skills of even an experienced writer. My insight into how readers read articles, in particular, has improved by this process.
When I see the folks at dev.to tweeting about my articles or Medium or its publications promoting an article, it boosts my confidence and resolve and it helps me have energy to keep going. It also shows me what the people who follow me are interested in.
I've felt a greater degree of confidence and lessening of that impostor syndrome most of us deal with. While I can't quantify this further, it's been helpful for me to get out there and get out of my comfort zone and interact with new people in the community.
It's been pretty cool to see trivial 'low energy / time' day articles succeed and make a difference.
With Medium in particular, I've noted that when articles succeed to even a modest extent, they bring continued success over time and that success spreads to other articles you've written in the past as well as future articles.
Because I've recently given a detailed talk on software quality and have studied the subject extensively this year, I had a lot of content ready to go at the beginning of this journey and have been able to trickle a lot of it into various posts.
By writing at the same time every evening or on the weekends, I've fallen into a cadence of sorts, making it easy to focus on the task at hand.
Unfortunately, my very first article was the one I cared the most about and felt the most passionate about. I say unfortunate because my skill improved after that, I had no following a the time or awareness, and as a result, the interesting topic of using the Scientist family of libraries to eliminate user-facing defects went relatively unread for awhile, particularly on Medium.
I got sick during this month and had a pair of days with a bad fever in particular. I still wrote on one of those days, while the article the next day was written after my fever went away. Committing to this course of action might not have been the wisest thing when sick.
I had to proof the article a number of times, but this one article on Action-Oriented C# written under a fever is one of my top articles on Medium now, so ... I guess I still did okay.
By restricting myself to writing an article mostly in a single sitting, I expect some quality issues, focus issues, and that the level of polish might not be as good as it could have been.
While the quantity approach has helped me get better quickly, some of these articles could clearly have benefited from more love and attention.
Writing takes awhile. An article takes anywhere from 30 minutes to 4+ hours (for the more technical items I don't already have code for). This is time not spent developing or relaxing by playing games (Typically I write later in the evening after my wife has gone to bed so it's not as much of a loss of family time).
The loss of time for new development hurts quality a little, and the loss of recreational time likely contributed to getting sick.
This, notably, was my first article not related to general software engineering or .NET development.
So, what have I learned from my foray into daily writing?
First of all, what you put in your article title matters a huge amount, as you might expect. On Medium, the 140 characters you get to write a description of your article matter significantly as well.
The cover image is incredibly important if you'd like to see your work promoted or shared. I strongly recommend using something from Unsplash if you do not have artwork that could fit this pattern.
Additionally, tags matter for discovery, but be honest about things.
Break up your articles with headers, bold, italics, images, and line breaks.
Keep paragraphs short as many people skim.
The most important things to establish in an article early on are:
- What the article is about
- What you hope people will get out of it
- Why people should care about what you say
For example, start by talking about a problem or a solution and why it matters, then talk briefly about what you're going to present.
I also like to close with next steps for people. By this I don't mean exhortations to follow, like / applaud, etc.
I mean, tell people how they can learn more. Link them to official documentation, GitHub pages, other articles you've written on related topics, etc.
If people reached the bottom of an article, it's either because they want the tl;dr or because they liked it and want to consider what you talked about. Help them keep that momentum going.
So, one month later I'm ending my habit of daily writing. What's next for me is either preparing to speak at a major conference in January, or licking my wounds in October and taking on a larger technical project and sharing about that journey with a greater degree of polish than I've had in September and late August.
Specifically, you can expect either posts related to one or more conference sessions I'm preparing for or you can expect a strange series of articles on "Emulating Squirrel Brains in F# with a Blazor UI in .NET Core 3".
Yes, I know. I'm a strange man.
Edit: I was accepted to speak at CodeMash 2020, and so I will be working on slides. As it's not an extremely technical presentation, I should have some time for ongoing development and articles. I will aim for an article a week going forward and find a new flow
If you got this far, you likely are interested in taking your writing to the next level or trying something like this out.
I recommend giving it a limited trial. Try either writing every day or writing on specific days each week. Set a date, see what you see and encounter, and let me know what works and doesn't work for you personally.
There are a lot of people who love both JS and UX/CSS. If we stop labeling people just as “JS developers” or “UX developers”, we can achieve a ceasefire in the current “JS vs. CSS” war and achieve a mutually benefiting peace.