I encourage my colleagues to write blogposts more frequently. This is for a few reasons:
It informs your broader community what you’re up to, and allows that community to communicate back to you quickly.
You communicating to the community fosters a sense of collaboration, openness, and trust. You gain collaborators, build momentum behind your work, and curate a body of knowledge that early adopters can consume to become experts quickly.
Getting feedback from your community helps you to course-correct early in your work, and stops you from wasting time in inefficient courses of action.
You can only work for a long time without communicating if you are either entirely confident in what you’re doing, or reckless, or both.
It increases your visibility, and so is good for your career.
I have a great job. I find my work to be both intellectually stimulating and ethically worthwhile. I’m also decently well paid for it.
I have this job largely because a potential employer a long time ago read my blog when I was just starting out.
It focuses you towards tasks that are relevant to others.
When you set an expectation of regularly publishing a blogpost, you find yourself seeking out work that will engage people. This is a nice objective to try to optimize, and keeps you on task serving the general public.
Obviously, you don’t want to take this too far, but my guess is that most developers could use a little more orientation towards public interest.
It improves your communication skills
Your effort is valuable only if people understand and adopt it. This is true for technical programming, but also true for most efforts. Writing regularly encourages you to think about effective communication.
But I’m too busy#
How are we supposed to get work done if we’re writing blogposts all the time?
We should reduce our standards. Blogposts don’t have to be big endeavors that solve a huge problem. They are not scientific journal articles. They can just be longer-than-average tweets.
We can write short blogposts that we write in a fixed amount of time. Personally, I like timing myself (I started this blopgost just 18 minutes ago) and time-boxing myself (I plan to publish this this afternoon before my next meeting).
One of my favorite bloggers, John D Cook writes an excellent blog that follows this concise approach. Here are some recent posts from his blog:
These are all about a page long, and are a great read. Honestly, I probably wouldn’t read a scientific journal on any of these topics (they’re not my field) but I know that John’s posts are concise, so I’m happier to dive in than for someone that I know produces very long posts.
You should write more. It can be easy if you don’t make a big deal out of it.
12:30: Talking to a colleague about writing short blogposts. Decide that I should stop one-on-one communication, and just write a blogpost about this.
12:51: Start writing
13:16: Finish first draft, render it to take a look and edit
13:29: Back to work!
13:32: Oops! Typo.