How I Motivate Myself to Write

Since leaving Uber a year ago, in October 2020, I've been making a living from writing - one with comparable income to when I was employed.

None of this would have happened if I did not start to write this blog several years ago. Writing which helped hone my writing skills, and build the credibility to start publishing books, and to start my weekly newsletter.

How do you find the inspiration and motivation to write? This is a question I frequently get - especially that regular blogging has led to making a living off writing. Here are the 12 approaches and steps that worked for me - some of which might be useful if you'd like to write more regularly.

1. Own Your Content

Start a blog or a place where you can start share your longform writing.

I am personally a fan for paying out of pocket for the writing platform I use. By doing so, I own my content. I took this advice from software engineer and blogger Scott Hanselman after reading his post Your words are wasted where he writes:

And still you tweet giving all your life's precious remaining keystrokes to a company and a service that doesn't love or care about you - to a service that can't even find a tweet you wrote a month ago.

I pay a monthly fee of around $30 to use Ghost as a hosted service. Paying every month reminds me that I should write something to not waste all this money. It's a small thing, but this guilt is what helped me get more articles out in the early days.

Getting started on free places where you keep your copyright like Hashnode or Dev.to can also be an option. The nice thing about them is you might get better reach, and more feedback or comments.

The downside with free-to-write platforms is that you don't really own your content: those companies make a business directly or indirectly monetizing your writing and the traffic it generates. For example, see what happened with Medium: much of the content hosted there is paywalled.

2. Start Writing - Regularly

Few people know, but I have been blogging on another blog for years. Those posts were irregular braindumps on whatever was on my mind. It was a mix of personal updates, debugging stories and sharing when I released a new version of my app.

In 2015, I decided I want to write about software engineering - a field I had been working in for years. I took my inspiration from the once-very-successful Coding Horror blog by Stack Overflow cofounder Jeff Atwood. In the post How to achieve ultimate blog success in one easy step, Jeff wrote:

When people ask me for advice on blogging, I always respond with yet another form of the same advice: pick a schedule you can live with, and stick to it. Until you do that, none of the other advice I could give you will matter. I don't care if you suck at writing. I don't care if nobody reads your blog. I don't care if you have nothing interesting to say. If you can demonstrate a willingness to write, and a desire to keep continually improving your writing, you will eventually be successful.

I read, re-read, and re-read this post. I then decided this is exactly what I need to do.

I picked a schedule and stuck with it for months. I decided to write an article every two weeks for the next couple of months. And this is what I did, shipping the first few articles on this blog:

If I started writing today, I'd join a community like Blogging For Devs, where you have a community that can feel it keeps you accountable, and a group that gives feedback on your early drafts. I'm a paying member here and drop in when I have the time.

Ship 30 for 30 is another great way to start. This is a program where you ship 30 writing assignments in 30 days as part of a cohort that keeps you accountable, which kicstarts this process and helps form this habit. The course is priced around $300: paying this amount and working in a cohort I'd expect will help you stick with writing through the 30 days.

3. Write For Yourself

When I (re)started my blog, I was wondering who would be reading my articles. In the end, I decided I don't care: I'll just write them for myself, as a reflection of the ideas and observations I have come across.

Approaching writing with this approach, it has been surprisingly therapeutic and a tool that helps me reflect. Writing my ideas down, in a form that makes sense requires a surprisingly large amount of thinking.

Writing is a forced way to think more clearly - and I'm not the only one to make this realization. Early Facebook employee Andrew "Boz" Bosworth shares a similar observation in the article Writing is thinking:

Even when I write for my own benefit, it is undoubtedly a bonus that at the end I have a document which I can easily share to invite critiques or enlist support. I know of no more scalable way to engage a large audience than the written word.

I'm glad I started out writing for myself: it helped my thinking, and it helped polish my writing as well. The early articles are noticeably shorter and, less pleasant to read, though they often took more time to write than later ones. They gave me early practice in forming and writing down my thoughts around various engineering topics though.

4. Copy Writing Styles You Like

Most of my favorite writers and bloggers have a distinct style. When I started writing, this made me think: what would be my style? What writing setup should I chose?

When starting out, I copied the writing style and approach of well-known bloggers. Most of my early posts were inspired by the quotation style that Jeff Atwood uses in many of his articles. He takes a 1-3 quotes from various articles on the same topic, then adds his own cents.

Take his article, Swiss army knife or generalizing specialist. The article consists of three quotes from three different sources, and his comments surrounding these.

As I browsed blogs, this approach struck me as one that can help me get started easier. Commenting on someone else's writing is a lot easier than writing from scratch. So this is what I did with my first few articles. If you look closely, the resemblance in style for these articles should be clear - but only if you know where to look for the inspiration:

Many early Pragmatic Engineer articles were inspired by the writing style of Coding Horror. Can you see the similarities?

As you start to write more, your writing style will evolve and you won't feel the need to "copy" another style. This is what happened in my case. Current articles don't lean on any one style: they're a mix of what I have found pleasant and useful, over the years.

If you like this style - you're more than welcome to copy the approach. I do, however, recommend the quoting approach for an easy start: it's much easier for words to flow when there's already a few thoughts from someone else that you can reflect on.

5. Capture Ideas As They Appear

Once I started writing, the biggest barrier I faced was the lack of ideas. After finishing an article, I'd be unsure what to write about next.

Capturing ideas as they popped into my head has been very helpful for my writing I almost always did this with a note taking app on my phone or my laptop - as ideas would often come when debating with a colleague, or having a conversation over lunch. I now use Craft Docs to capture these - both because of the slick UI, as well because my brother is behind the company - but any system works.

Once I started to capture these ideas as they hit me, I no longer had a shortage of topics. After a while, I had the opposite: too much to choose from. Here's a screenshot of my "blog ideas" note in Craft Docs, and a fraction of my idea backlog:

6. Freewrite

Once you have the idea, it's easy to get stuck on an empty page. One of the tricks that helps me break this block is to do twenty minutes of free writing. Here's how I do it:

I set a timer for 20 minutes on my phone, and place it next to me.
I proceed to do free writing, typing out everything that is in my head. I don't stop to correct grammatical errors, or to go back and fix anything.
I don't stop to criticize my thoughts - this gets easier once you've done this a few times.
If I cannot think of anything to write, I write "I cannot think anything to write... okay, now I thought of this new idea on..."

The interesting thing is how it works, every time. After a few minutes I'm pushing out ideas, and I'm usually frantically typing when the timer goes off.

7. Draft

Following free writing, I have a good chunk of ideas. I then proceed to write a draft piece.

My approach is this:

I write out key ideas I want to explore as bullets
I write out each of those bullet ideas: either by copying from my free writing, or by adding a few paragraphs to each
I personally like to bold out the key ideas I'm exploring. It helps me focus on what I'm trying to say.
I often do research during the draft stage, reading up on topics I'm writing about, then quoting or linking to relevant resources.

My draft is complete when I wrote about all the parts I wanted to.

8. Edit

Once a draft is ready is when a very different staging of writing comes: editing. This one is something I often leave for the next day. Even when I start doing it after the draft, I take a break to get into "editing mode".

Editing is about making this piece digestible for the reader. I do a few things:

1. Add a closing section. What is the takeaway of the piece? What is the one, or two things I should leave the reader with? For example, in the article Data structures & algorithms I used working at tech companies, I added this summary section:

Data structures and algorithms are a tool that you should use with confidence when building software. Know these tools, and you'll be familiar with navigating codebases that use them. You'll also be far more confident in how to implement solutions to hard problems. You'll know the theoretical limits, the optimizations you can make, and you'll come up with solutions that are as good as they get - all tradeoffs considered.

2. Make the opening count. The first few paragraphs need to grab the attention of the reader, make it clear why the topic is relevant, and what they'll get out of it. I often set the context in the beginning as well.

In the Data structures & algorithms article, I decided to open with a question to the reader, then follow with a summary on what to expect:

Do you actually use data structures and algorithms on your day to day job? I've noticed a growing trend of people assuming algorithms are pointless questions that are asked by tech companies purely as an arbitrary measure. I hear more people complain about how all of this is a purely academic exercise. (...)

This article is a set of real-world examples where data structures like trees, graphs, and various algorithms were used in production. I hope to illustrate that a generic data structures and algorithms knowledge is not "just for the interview" - but something that you'd likely find yourself reaching for when working at fast-growing, innovative tech companies.

3. Tighten up the text. Once the opening and the closing are clear, I go through the article to tighten up the text, make sentences shorter, and fix any grammatical issues.

In the past, I used Hemingway Editor to spot overly complex sentences. I would then proceed to make them shorter and easier to read. Over time, I learned to write more clear sentences myself:

Making text easier to read with Hemingway Editor: before and after

I also use Grammarly to catch spelling, and grammar issues, and sometimes take suggestions the tool gives - though I just as frequently reject them.

4. Hire an editor. This last one I wish I had done earlier. For years, I wrote without an editor. I hired my first one when writing my books Building Mobile at Scale and The Tech Resume Inside Out.

An editor not only makes your writing more clear, but it's a fantastic way to learn on how you can improve it. I would not recommend an editor for every blog post: but hire one if you're serious about wanting to write better.

9. Publish

Pressing the button to make my writing live is one I like to delay. However, I've always found that done is better than perfect. Most of my blog posts go out after light edits, and I set it live.

10. Feedback

For most of my early posts, I got no feedback, and probably very few readers. However, as soon as I start to get feedback, I often go back and tweak my writing based on what people say.

The most frequent feedback I used to get was on typos. I sometimes do get corrections, and additional ideas, mostly as emails or messages - both are more common since more people read what I have written.

11. Audience

Writing and people reading your writing is a chicken-and-egg problem. When you start out, there's no one to read. When there's no one to read, there's little point in writing.

As uncomfortable as it is, you do need to share your writing to where interested people could be. This can be social media like Twitter, LinkedIn or Facebook. It can be groups like subreddits, Hacker News and other tech forums. It can be chat groups on Discord or Slack.

Self-promotion is something you'll need to be wary of on forums: if you only join these communities for the sake of sending a link to your article, you will - rightfully - not be welcome at these places.

This is where it's helpful when you start to write for yourself: you have less of a pressure to want to get people you don't know read your writing.

12. Again. And again. And again.

The hard thing about writing is not on publishing an article: anyone can do this. The hard part is doing the writing on a consistent basis.

I found that setting up dedicated time - an hour each week, on a weekday - helped me get into the habit of writing. This is how I wrote most of the posts on this blog.

Over time, some posts resonated with people, while others saw very little interest. Still, every piece helped one person: me. Every time I published, I had the satisfaction that I've understood or explained something for myself - and maybe, for others as well.

And this satisfaction is what gave me the motivation to do it again. And again. And again.

The result of repeating this for years is this blog, the weekly newsletter, and few books.

Featured Pragmatic Engineer Jobs

Engineering Leader - Card Platform at X1 Card. $250K+. Remote (US).
Engineering Leader - Card Product at X1 Card. $250K+. Remote (US).
Senior Android Engineer at Polarsteps. Amsterdam.
Frontend Software Engineer at Enveritas. $130-150K. Remote (Global).
Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
Software Development Manager - eCommerce at Card Kingdom. $175-195K. Seattle, WA or Remote (US).
Senior Frontend Engineer at Pento. £80-92K. Remote (Global).
Senior Fullstack Engineer at Synthesia. £70-110K . Remote (Europe or US Eastern time) or onsite (London, Amsterdam, New York).
Senior Backend Engineer at Synthesia. £70-110K . Remote (Europe or US Eastern time) or onsite (London, Amsterdam, New York).
Senior Frontend Engineer at (catch) Health. $90-120K + equity. Remote (North America).
Staff Backend Engineer at Pento. £95-115K. Remote (Global).
Senior Full Stack Engineer (Laravel / Vue) at RXMG. Remote (Global).
Sr. Cloud Infrastructure Support Engineer at RXMG. Remote (Global).
Founding Engineer, Front End and API at Causal. $175-225K - equity. Boston.
Senior Full Stack/Frontend Engineer at Vitally.io. $180-270K. New York or Remote (US).
Senior Software Engineer - Core Platform at CAST.AI. €72-€96K. Remote (EU).
Senior Software Engineer - Cost Optimization at CAST.AI. €72-€96K. Remote (EU).
Solution Architect at CAST.AI. Remote (EU).
Senior Software Engineer - Security at CAST.AI. Remote (EU).
Solutions Engineer at Pigment. $70-120K. New York or Toronto.

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.