This was the first year in many that I managed to regularly update and publish content on my personal site. In past years I started strong (usually around New Years) with fresh writing, energy, and enthusiasm. But somewhere around February or March, things died off and I could never find that momentum again.
Why was this year different? In this post I've tried to tease apart factors that made writing and editing easier this time around – hopefully there's something in here that may be useful for your own personal website.
One of the hardest parts of maintaining a blog is knowing what to write about. Finding topics, developing those topics over time, and ensuring that there is a steady stream of ideas itching to be written about has been key for me to write consistently.
Here are some sources of writing prompts and blog post ideas that have helped me publish 20 posts this year:
Maintain an ongoing list of ideas
This sounds so obvious on the surface, but it's hard to do in practice. This is the single most important strategy I've found that keeps ideas flowing and makes it easy to sit down and write every week.
I have a project in Things called "Blog post ideas" where I maintain an ever-growing list of topics to write about. The key is to have this list running as a background process in my brain every day. If I come across a new idea, or find an article that would supplement some existing idea, I quickly add it to the list.
When it comes time to write, I will reorder my list of ideas based on what feels most developed and easiest to write about. At that point, the top idea usually has had time to form, and might have a few notes or reference resources that can help kickstart the writing process.
Find opportunities to extend ideas and conversations
Last New Years, a fiery debate arose on Twitter about whether people should work on nights and weekends. Everyone seemed to be talking past each other and spinning hot takes. This kind of temporary chaos is an opportunity to pull back, think, and write. That's where On working nights and weekends came from.
Twitter debates can be a useful opportunity to really think about my perspective on a topic. If I manage to resist the temptation to tweet a hot take, I can find the time to think, change my mind, and add new data points to some existing belief.
Seeding ideas from Twitter
In November I asked people on Twitter if they had any side projects earning passive income. That one tweet ended up getting a wave of replies, retweets, and initiated a lot of DM conversations. It's hard to predict when a tweet will get traction like this, but when it happens it should jump out as an opportunity to write. As a result of that tweet, I've been drafting a larger project about designers who earn passive income through side projects.
A useful reminder: every tweetstorm is just an outline for a future blog post.
What's normal for me is novel for someone else
In college I began investing in the stock market and making money work for me. Over the years I've maintained a basic spreadsheet that accounts for where my money is growing and working, and where it's sitting stagnant. This investing and money management process has become so normal to me that I figured everyone else must also have something similar (or more likely, something more advanced).
But something normal for me might be novel for someone else – especially someone a bit younger, or someone who has just started making money. So I sat down one afternoon and wrote a primer on investing for designers and developers. That post is the third most popular blog post I've written this year.
Writing about things that you already know, but with a specific audience in mind, unlocks a lot of opportunities to help others. It's also a great way to re-check preexisting beliefs by looking for new information that might improve or replace some of your ideas. And of course, writing things will solidify topics that exist as a loose jumble of ideas in your head into something tangible and clear for others.
I'm way too guilty of getting in my head about everything that I publish on the internet. Hell, the working name of this blog is Overthought. The key thing that I get hung up on is feeling like each blog post has to be evergreen content, an idea gilded for all eternity.
That's just not true. If anything, it's entirely counterproductive to exploring new ideas and using writing as a way to learn.
To combat this feeling, I now time box myself whenever I sit down to write. Drafts aren't meant to be dragged out for days or weeks. I want ideas to be simple and concise enough that they can be drafted, edited, and published within a few hours. When my ongoing list of blog post ideas is documented correctly with notes and references, it makes it trivial to open up my editor and simply add meat to a skeleton that has been forming for a few weeks.
A good example of this was my first impressions of Tailwind post. While I used the CSS framework during the week, I wrote down notes about what was working, what felt confusing, and what I wished worked differently. On the seventh day, I added a few sentences, drafted an introduction, and published within an hour or two.
That post is already the 5th most-viewed post I've written in 2020.
It's always surprising what ends up getting traction. Some of the posts I spent the most time writing never got off the ground. Others that took an hour to write ended up becoming the most popular.
I think there's something more fundamental at play: when I remove the pressure to capital-B Blog and instead just focus on sharing a chain of connected ideas with my own voice, people tend to respond more positively.
The tools we use shape the entire experience of creation and maintenance. If writing a blog post requires spinning up a bunch of apps, opening a command line, saving a bunch of text files, running tests, and more...well, I'll just never update things.
I realized this would be a problem when I created my bookmarks and AMA pages. If it took more than 3 seconds to add a new bookmark, I would never add new bookmarks. Creating low-friction systems is critical.
Whenever I'm working on something that should be dynamic, I try to think of ways to allow that creation to happen inline, directly on the webpage. This led me down the path of creating a micro authentication system, just for me, and leaning into the principles of incrementally correct personal websites. With authentication in place, and a thin API layer that talks to Firebase, it now takes a second or two to add new bookmarks and review pending AMA questions.
Low friction means I'm eager to add, extend, and edit. The bookmarks and AMA pages on my site are now some of the most popular pages here, because there's reason to revisit and see what's new.
One mistake I've made in past personal website designs was trying way too hard to find the perfect abstractions so that every single page was internally consistent. While a consistent architecture is satisfying from a coding perspective, it can become a constraint on creativity.
The right abstraction is one that makes it trivial to add new layouts to different pages. My home page is different from Security Checklist, which is different from Bookmarks. Sure, they're all single-column views, but under the hood they behave quite differently. Here's my dead-simple single column page layout. Any new page can use a new layout and be free from the design language of all the others pages on this site.
I've found that having flexiblity per page opens up the opportunity to try new ideas. In fact, this is one of the reasons that I'm so bullish on Next.js - some of my pages are statically generated, some have bespoke data fetching processes, some incrementally build as people visit throughout the week. Next.js gives me full control per page to build the exact experience I want.
I hate site operations: deploying, testing, maintaining. Every step that it takes to get some new idea live on the internet is a point of friction that stops me from doing anything at all in the first place.
Luckily, frontend tools are wildly good in 2020. Finding the right ones might feel like chaos, but once you find a setup that works for you, the headache of site maintenance just melts away. Here are the key parts of my setup:
main branch is changed. For example, if I spot a typo, I can quickly edit a file directly on GitHub, commit directly to main, and know that within a minute or two the entire site will be tested, rebuilt and deployed.A small favor
Was anything I wrote confusing, outdated, or incorrect? Please let me know! Just write a few words below and I’ll be sure to amend this post with your suggestions.
The email newsletter
Get updates about new posts, new projects, or other meaningful updates to this site delivered to your inbox. Alternatively, you can follow me on Twitter.