Technical blogging for growth and learning
Writing a technical blog improves your writing, forces you to learn new things, helps others and yourself, and helps your career. This post: why blog, what to blog about, how to start, and using AI.
I’ve been blogging about genetics, statistics, computational biology, data science, and science in general for over 15 years. I published my first blog post on Getting Genetics Done in 2009, and started this blog last year after taking a few years off.
Science blogging has significantly contributed to my personal and professional growth as a scientist. Writing takes time and effort — time I could have spent elsewhere. I wouldn’t continue putting so many hours into this thing if it didn’t serve me in some meaningful way.
In this post I’ll discuss (1) why you should write a blog, (2) what you should write about, and offer a few pointers on (3) how to get started and choosing a platform. I wrap up with a few personal thoughts and opinions on (4) using AI as a writing assistant.
This post is mostly geared toward early- to mid-career scientists, as you have the most to gain from the learning and exposure you’ll garner. But I’m fairly senior in my career and I still get out more than I put in. Maybe you will too.
1. Why write a blog?
Among many reasons: (1) it will make you a better writer, (2) you’ll help yourself and others, (3) it’ll force you to learn something, and (4) it can help your career.
Writing makes you a better writer
I argue that being able to write well is a scientist’s most important skill beyond your technical training and experience. As you progress through your career, you’ll spend less time performing experiments at the bench or developing software, and more time writing.
I spend a lot of time writing. Writing academic papers, grant and contract proposals, technical documentation, materials and textbooks for my courses, and seemingly boundless volumes of internal reports, talks, and slide decks for internal circulation. I spent several years as a principal scientist at a consulting firm, and I easily prepared hundreds of memos, easily in the tens of thousands of pages for my clients in national security and public health.
Most learning and improvement happen through the productive struggle. You won’t master chess, programming, jiu-jitsu, guitar, or shooting free throws solely by reading about them. The same holds for writing. There are a few great books on writing1 and science writing more specifically, but none are substitutes for deliberate practice.
And writing a blog is a great way to get that practice. Not only will it help you find your voice and hone your style for different audiences, blogging will just make writing get easier for you over time. The image below shows one of the most paralyzing screens so many scientists fear — the blank page. If you’re blogging regularly, you’ll face a similar blank page every week, and the more you write, the less paralysis you’ll feel when you face one.
Help yourself, help others
I started Getting Genetics Done when I was a senior grad student. My motivations were somewhat selfish. Junior students and postdocs in my lab were asking me the same questions repeatedly. How do I run a logistic regression in R? How do I automate this with Perl? (Yes, Perl was in en vogue in bioinformatics back then, before Python took over the mind share). What’s the right statistical test for this or that analysis? How do I interpret logistic regression coefficients? And so on. I had work to do, so I started GGD so I could write out these things once and refer other trainees to the post instead of spending time answering the same questions again and again. Eventually, people outside my department and outside my university found my posts helpful, and I kept writing long past my postdoc well into my early career as faculty.
Helping other people always gave me a sense of satisfaction. I suppose it went along with being an educator as I worked my way into a faculty position. But there was another dimension to this as well — writing out a generic solution based on a problem I encountered in my own research gave me something to look back on when I faced the problem again. I can’t tell you how many times I’ve referred back to blog posts I’ve written in the past to remember how to do something. These days it’s easy to fire up ChatGPT to get help with some coding problem. Still, writing out a problem statement and working through a solution for common or niche problems you encounter will give you a record to go back to when you need it.
Write to learn
There’s a quote misattributed to Einstein that goes something like “if you can’t explain something, you don’t understand it.” Similarly, two of Richard Feynman’s Caltech colleagues attributed a statement to him in 1989 (after his death):
Feynman was once asked by a Caltech faculty member to explain why spin 1/2 particles obey Fermi-Dirac statistics. He gauged his audience perfectly and said, "I’ll prepare a freshman lecture on it." But a few days later he returned and said, "You know, I couldn’t do it. I couldn’t reduce it to the freshman level. That means we really don’t understand it."
Anyone who has ever done any teaching knows this. Trying to teach or explain something reveals the gaps in your own knowledge, and gives you the opportunity to close those gaps. Writing a blog gives you a great excuse, an effective forcing function to help you either learn something new, or solidify your understanding around a topic that you already have a loose grasp on.
Last year I wrote about learning in public:
In that post I try to make the case for writing in public about things that you’re learning. You’ll help yourself, you’ll help others, and it’ll help tear down the ego that might be preventing you from trying to learn something in the first place. I’m fairly senior in my career as a scientist and I’m still learning tools, concepts, and techniques that might be considered elementary in some concepts. Celebrate this. There’s an endless number of things you don’t know, and don’t let the “I’m a [senior scientist / PI / director / whatever]; I should know this already” stop you from learning something new.
Take up space
Simon Willison writes in a blog post on science blogging:
Having your own little corner of the internet is good for the soul!
I agree, and I think it’s more than just good for the soul. Robin Moffatt writes in a blog post about blog writing for developers:
Anything in the public domain (such as your blog, but also open-source project documentation, etc) helps establish your credibility in an area and awareness by others of you.
I’ve experienced this first hand. Writing a blog is a great way to take up space online. I’ve attended many conferences where, upon introducing myself, people recognized me (“Hey, aren’t you that guy with the blog?”). I’ve had multiple job interviews where one of my interviewers commented publicly in front of the rest of the interview panel how they read one of my posts that helped them in some meaningful way (every time this has happened I’ve walked away with an offer).
On the other side of the table, I’ve hired many scientists throughout my career in academia and industry. When I’m hiring for a data scientist or computational biology position, the first thing I’m going to look at on your resume is your GitHub profile, and your personal website or blog if you have one. In your resume you tell me what you can do; your blog and GitHub profile will show me what you’re capable of, and showing is far more meaningful than telling. My colleague Tommy Tang has a newsletter, blog, and YouTube channel (all linked from divingintogeneticsandgenomics.com). Last year he published this video with tips for building a strong bioinformatics CV, and the two major tips were to showcase your (1) GitHub profile, and (2) personal website/blog. Having reviewed hundreds of resumes, I couldn’t agree more.
2. What to write about
I reference a few really good posts above, one from Simon Willison on what to blog about, and another from Robin Moffatt on blogging for developers. Both of these are geared toward software developers or scientists who also write software.
Write stuff you would be interested in reading
My advice mirrors Moffatt’s: write about topics you’d want to read yourself. From his blog post:
A really excellent place for ideas is the community around the thing you want to write about. Go and lurk (or even better, join in) at StackOverflow, Twitter, Slack, Discord… wherever the community is:
What questions do people repeatedly ask?
What are the anti-patterns and misunderstandings that you see?
What are the new trends?
What cool things can you do with
$THINGIn short, if it would be interesting to me then I would write about it.
Similarly, Moffatt advises against writing things that you don’t want to read. I’ll never click on a post with a title like “10 amazing ways to visualize your scRNA-seq clusters that no one told you about, OMG you won’t believe #7!” You won’t see listicles and clickbait titles like that here either.
Write about what you’re learning or what you’re building
In Simon Willison’s blog about what to blog about, he advocates for writing about what you’re learning and what you’re building. I second those suggestions. I try to tag blog posts on what I’m learning with the Today I Learned (TIL) tag. I can’t say much about projects I’m working on in my day job, but I also post here about open-source side projects I work on in my spare time (e.g., biorecap, rplanes). I also write about tools I find useful (e.g., lang, mall+ellmer, DuckDB, uv (posts coming soon!), and general tutorials or resource compilations (e.g., Python for R users, Building a Python CLI with Click and Cookiecutter).
Every time I write a blog post in any of these categories I find that writing forces me to think more deeply, examine my assumptions, and edit my writing. All skills that get better with forced practice.
3. How: Which platform should I use?
Use the platform that makes the kind of writing you want to do the easiest. If you’re writing mostly a technical blog with lots of embedded code and results, you can’t go wrong with using Quarto. The docs on building a blog with Quarto are a great place to start, and this webinar from Isabella Velásquez at Posit provides a great overview and demo. If you know your way around GitHub pages or Netlify, and especially if you’re comfortable setting up a GitHub action, then it’ll be relatively easy for you to start writing and publishing immediately.
I’m going to draw ire and lose my R Evangelist™ card for this, but I purposefully chose not to go this route (feel free to leave feedback at stephenturner.us/complain). I don’t write many posts here with embedded code and results, so the main draw of using RMarkdown/Quarto is lost on me here.2 I want the platform I use to make writing, publishing, distribution, and analytics as easy as possible. I don’t want to have to fuss around with git and my GitHub pages / Netlify setup and third party email distribution services just to publish and email a post out to people (maybe I’m overstating this — if you’re reading this blog chances are this kind of thing isn’t much of a hurdle for you). I don’t want to git push here and git pull there to write from different laptops. These are things I do at work, and I don’t want blogging to feel like work. I just want to open up some bookmark, start typing, and hit a publish button. When I want to include media I want to CMD-V to paste it in, and click+drag to resize. I want to see what my post will look like without rendering constantly to preview the layout. I want zero friction between idea to words on a page to email distribution.
I didn’t want to think about maintaining the software stack used to create a static site. I definitely didn’t want to try to figure out an email distribution system. I love RMarkdown and Quarto, and if you can set yourself up so that the kind of writing you want to do is frictionless, by all means do so. I can’t say enough great things about Quarto for reproducible research and technical (code-heavy) writing. However the category error here is to get so mired in fussing with these technical details that you end up spending more time setting up and optimizing your software stack than you do actually writing.
I use Substack (but there are other great options)
I have no affiliation or relationship with Substack, but after looking into Ghost, Medium, Buttondown, and a few other hosted solutions, I chose Substack for this blog and I (mostly) like it.
You own your content and audience. More on this below. If I ever want to leave it’s easy for me to export all my posts and my subscribers’ emails and import them elsewhere.
Zero effort setup. Create an account, hit the new post button, write, hit publish.
Built-in email distribution. People can subscribe on their own or I can add or import them manually. As soon as I hit publish, the post is sent out via email. I don’t have to manage any of this.
Clean editor UI. The editor has most of the features I want with very few that I don’t use. I can focus on writing instead of getting distracted by formatting, compiling/rendering, etc. It’s also easy to embed photos and videos.
Minimal social features and no AI BS. The minimal social features (comments, reshares, etc.) are all easy to disable, and there’s no tempting “help me write with AI” or some other AI-enabled nonsense I don’t want.
Clean preferences UI. Preferences across everything from layout to emails to analytics to payments are all customizable, in just the right amount. I can change most of what I want to change without being distracted by a bewildering set of options I don’t care about.
Custom domain. It was easy to set this up. More on this below.
Built-in podcast server. I don’t really use this feature much yet, but I might in the future. Upload an mp3 file to a post and in addition to being embedded in the post it automatically gets syndicated to all the major podcast apps. E.g., here’s the Paired Ends podcast on Spotify, Apple Podcasts, and Overcast.
Built-in paid subscriptions. This newsletter is free and I plan to keep it that way, but if I ever wanted to turn on a paywall, I’ve already spent the 5 minutes it took to link Substack to my Stripe account, and all I’d have to do is click a toggle to turn on the juice. You can also choose only a subset of content to paywall (e.g., new posts only, old/archives only, select posts, podcast previews, etc.).
RSS. RSS works out of the box. I can just plug https://blog.stephenturner.us/feed into whatever service I want to use an RSS feed for. Besides enabling people to use RSS readers to read this newsletter, I can use the RSS feed to do some interesting things myself. For example, I connect this blog to Rogue Scholar so I get a DOI automatically created for every post I write, like this DOI for this post: https://doi.org/10.59350/bqnfd-7p249.
Detailed analytics. I try not to pay too much attention to this, but if it’s something you need, you get good detail on reader stats on each post, individual level data on who among your subscribers are opening which posts, when, and how often, which external sources are driving traffic to your posts, etc.
It’s free. This could be seen as a huge downside (when something’s free you’re the product). However Substack’s business model isn’t ad-based or freemium — they’re hoping you can turn on paid subscriptions and they’ll get a cut. But point #1 — I own the content and audience and I can pack up and leave if the model changes in some annoying way.
Substack isn’t perfect. I wish the code blocks were a little more feature rich (just give me syntax highlighting). I also wish I could write markdown and have it be rendered on the fly, much like what Slack does. And when I actually want to write code with executable chunks, it’s way harder than it would be with RMarkdown/Quarto.3 But for a minimal friction get-words-on-the-page-and-get-it-out-to-people platform, I like it so far.
Own your content and audience
Cory Doctorow has written multiple times advising that you should not devote energy to building up an audience on a platform whose management can sever your relationship to your audience at will, at any time, for any reason. These posts were about social media properties, but the same principle applies here. Whatever route you choose, make sure you own your audience and content.
In a more recent essay, “Be A Property Owner And Not A Renter On The Internet” author Dan Delimarsky writes about not getting locked into the walled garden of some major platform, but stops short of arguing against using any “BigCo” services as universally evil or bad. It’s better if you can find a place where your goals overlap with the company’s desire to make money (e.g., a platform that makes money by taking a cut of your revenues from paid subscribers).
The main point of the article is that we shouldn’t build our castle in someone else’s kingdom, and it offers a few recommendations. One is to separate your domain from where you host your content. For instance, if you own your own domain you can move it anywhere you want (I could point blog.stephenturner.us to any other platform, or host my own with a static site generator). Another is to avoid content lock-in. If you go the static site generator route (Quarto, Hugo, Jekyll, etc.) this is easy — all your writing is in plain text files that you can take wherever you want. I use Substack, and in about 3 clicks I can export my entire subscriber email list and plain HTML for every post I’ve written here.4 I can take everything to Buttondown or Ghost or wherever I choose if Substack ever disappears starts behaving badly.
Align with the notion of POSSE: Publish (on your) Own Site, Syndicate Elsewhere. This is the practice of writing and posting content on your own site first (like a Quarto or other static site, or on a platform service tied to a domain you own), then sharing links to other sites like LinkedIn, Bluesky, or other social media silos.
4. On writing (and revising) with AI
The elephant on the room (on the page?): writing with AI. I have mixed feelings about this one. I often use LLMs for reading (e.g. summarizing preprints, summarizing social media posts on a topic, summarizing YouTube video or podcast audio). But I limit how I rely on these tools for writing (at least for now).
These tools are great for certain tasks: proofreading, suggesting revisions to improve spelling, grammar, clarity, and tone, or brainstorming ideas when you’re stuck. Like any tool I believe you need to understand their strengths and limitations to get the most out of them. Counterintuitively, LLMs (AI chatbots, specifically) are actually really hard to use — “they’re chainsaws disguised as kitchen knives” as Simon Willison notes. You actually need a good deal of experience with several of them (e.g. both the frontier models like ChatGPT or Claude, and an open model like Llama3.3) to get an intuitive feel for where they help and where they fail miserably.
I like to think of these tools as a reasonably knowledgeable and patient colleague who will tirelessly read drafts and provide feedback without complaining. If I want to clean up phrasing or clarify a point, I use AI to highlight areas for improvement without judgment or fatigue. They also excel at reworking text for different audiences, or helping rewrite awkward sentences (like getting rid of the passive voice5). In this sense, they’ve become a valuable part of my writing workflow, especially during later stages of revision. When I’m working on something sensitive that I don’t want to end up in some training dataset, I’ll usually use the latest and biggest Llama model I can run locally on my 96GB Macbook Pro M3 (currently llama3.3-70b via ollama). Lately I’ve found Claude 3.5 Sonnet to be the best and giving me what I want, but I also really like ChatGPT’s Canvas feature, which lets you collaboratively work on a document together with the AI.
I try to resist starting a writing project by feeding a prompt to an LLM. It’s tempting, especially when faced with the blank-page paralysis I mentioned earlier. It’s easy to fall into what Simon Willison calls “AI slop” — unsolicited and unreviewed AI-generated content where the resulting text feels generic, overly polished, and blandly formulaic. It’s hard to shake that distinctive “written by ChatGPT” smell — an impersonal tone that lacks the texture, quirks, and authenticity of writing crafted by a real human.
There’s also the risk of depending too heavily on AI, which can stifle your own growth as a writer. Similar to what I wrote about learning to code, writing is a skill that improves through deliberate practice and the productive struggle. If you lean on an LLM to generate your starting drafts, you’re skipping an important step: grappling with your ideas and refining them into something meaningful. AI can augment your process, but it shouldn’t replace the hard work of thinking critically and finding your own voice. In my experience writing with AI, especially starting a writing project instead of just using AI for revisions, tends to shift you more to the right on the spectrum in the figure below. I don’t use a ton of contrarian GIFs or profanity in my writing but I don’t want to sound like a goddamn corporate mouthpiece either.
Recognize that LLMs are tools — neither inherently good nor bad. Used thoughtfully, they can streamline tedious parts of writing. I like writing and hate revising, and this is where I find AI the most useful. These tools can also provide an outside perspective when you’re too close to your own work to see its flaws.6 IMHO the key is to remain the author and editor-in-chief of your own writing, not simply the curator of slop that an AI generates.
If you integrate AI into your writing process, do so intentionally. Use it where it adds value — proofreading, simplifying complex ideas, or refining drafts — and avoid situations where it might hinder your creativity or authenticity. Writing is a deeply human activity, shaped by our unique perspectives, imperfections, and experiences. Embrace AI for what it’s good at, but don’t let slop take the pen out of your hand.
References
Den Delimarsky: A Property Owner And Not A Renter On The Internet
Chris Zukowski: Don’t build your castle in other people’s kingdoms
Stephen King’s On Writing: A Memoir of the Craft is my favorite book on the topic. It’s not about science writing specifically. But aside from technical documentation, we’re all storytellers, and Stephen King is a master of the craft.
When I do want to include lots of code and/or results, I put snippets here and the full code on GitHub, either as a Gist or a regular repo, and link to it from here.
It’s clunky, but if I really want to write posts with lots of embedded code and output I can write in RMarkdown/Quarto, render to HTML, then copy and paste into the editor. All the formatting is maintained and for the most part it just works.
When it comes to backing up important data, I don’t consider a backup real until I’ve simulated a catastrophic data loss and then attempt to restore from my backup (e.g., Backblaze, Time Machine, rsync, whatever). Same here: I don’t truly believe “you can export all your data” until I try it myself. With a few clicks I was able to export all my posts as HTML with embeds intact. E.g., for my post Learning in Public, here’s the raw HTML from the export, and here’s what it looks like rendered. The raw / unstyled HTML isn’t pretty, but it’s easy to import this into another platform or convert back to Markdown with pandoc if I ever wanted to.
People who know me or who I’ve collaborated with on a writing project before know that this is a hill I’ll die on. The passive voice is an incorrect construction, not a matter of personal preference or opinion. The passive voice is a hoax, and shouldn’t be used in scientific writing. Stephen King in his memoir On Writing (see footnote #1) discusses the passive voice: “It's weak, it's circuitous, and it's frequently tortuous, as well. How about this: My first kiss will always be recalled by me as how my romance with Shayna was begun. Oh, man—who farted, right? A simpler way to express this idea—sweeter and more forceful, as well—might be this: My romance with Shayna began with our first kiss. I'll never forget it.”
I’m not sure where I saw this tip, but I used to do this when I had to review my own writing for the Nth time: change the font on all the text to Comic Sans. If you’ve written something and reviewed+revised it several times, it’s easy to re-read on a third (4th, 5th, …) revision and skim over errors and poor constructions. Changing the font to something cringy like Comic Sans or annoying to read like a monospace or script typeface forces you to slow down and review more carefully. I still do this on occasion, but I prefer the AI revision route.