I read fewer technical blog posts than I used to. This is partly because I find information differently, and partly because I'm 30 years into this. My reading habits say more about where I am in my career than about the value of blogging.
I write fewer technical blog posts than I used to, too. This is mostly a function of time and juggling work and life priorities, rather than a lack of ideas or perceived value in sharing them.
I still value blogs as places to learn, share ideas, and express opinions.
But why?
Blogs give us access to someone's experience and judgment, including the messy process that produced a solution. Sometimes that mess is pinging ideas back and forth with a colleague, sometimes it is experimenting and failing, and sometimes it is iteration with a chatbot. But when that solution is documented in a blog post, the author has room to share the whole experience: which assumptions proved wrong, why a promising approach failed, what actually happened in practice, and which caveats survived the final edit.
The author can decide which parts of that process deserve space. They can also add humor (including inside jokes), humility, callbacks, analogies, and opinions. You know, human stuff. Those details give you a sense of the person making the recommendation, how they arrived at it, and why they discarded a solution you might have been considering yourself.
Sometimes what I want to share doesn't start with a question at all. It starts with an observation, a frustration, or advice I keep encountering that deserves some scrutiny… like applying NOLOCK everywhere, insisting on MERGE, or (coming soon) defragmenting indexes like it's 2008. A blog gives me somewhere to develop that thought, including enough context for readers to understand why I hold the opinion and decide whether they agree.
Posts about features in brand new versions of SQL Server can also help decide what deserves further investigation. Someone's practical example might reveal a benefit you or I hadn't considered, give us a reason to test a feature against our own workloads, or add something concrete to the "pros" column of an upgrade decision matrix. Even if an upgrade is some distance away, that information can help shape the case for it.
For features or versions still in beta or preview, blogging can influence what eventually ships. Trying something beyond the introductory marketing slide demo can expose confusing behavior, unexpected limitations, or outright bugs. Publishing a clear explanation and a reproducible example makes those problems visible to other testers and gives the product team useful feedback while there's still an opportunity to address them before release. That can make the feature better even for people who will never read the post.
What have you done for me lately?
A useful conversation with a colleague or chatbot might help me solve today's problem. But how does it help you? Writing about it makes what I learned available to someone who wasn't part of that conversation. They can find it later, send it to a teammate, test the approach, or explain why it behaves differently in their environment. Their experience and feedback might even send me back to revise the post or write a follow-up.
That also gives us something worth linking to. When I'm trying to explain a recommendation, a post with context, evidence, and caveats can save everyone some time. And when someone challenges it, we have a shared starting point for the discussion. They can point to a particular assumption or test result, and we can work out where our experiences differ.
This very thing has happened recently. I wrote this post about using NOLOCKs to drive writes: Dirty Reads, Permanent Damage. Writing about NOLOCK as a Bad Idea Jeans™ model wasn't new, of course, but the post came from a pattern I kept encountering. Since publishing, I've referenced the post in at least a dozen customer performance reviews. It gives customers the explanation and evidence behind my recommendation, along with something they can revisit or share with their developers. And it saves me from repeating the whole investigation in every review.
That said, another NOLOCK post got me into hot water with colleagues. An LLM told them that NOLOCK had been deprecated back in 2022, possibly taking my satirical April Fools' Day post, "All you NOLOCK lovers better read this!," at face value. The deprecation announcement was a joke, but it led to another valuable conversation about how and where we use that hint, and also a sidebar about how LLMs don't necessarily identify humor or sarcasm.
Sometimes a post is useful before I even have the problem it describes. Someone writes about a surprising behavior, an overlooked setting, or a practice they've reconsidered, and now I have something else to investigate. I wouldn't necessarily have thought to ask about it, but someone else's post gave me the question. Sharing what I learn gives the next person somewhere to start.
But someone has blogged about it before
An explanation that feels redundant to me may be the one that makes the concept click for someone else, and there's really no telling how valuable a seemingly simple observation might turn out to be once it gets publicized the right way. "Someone has already written about this" shouldn't automatically become a reason to keep your explanations and opinions to yourself.
I've blogged about these blogging concepts before:
Show your work
My daughter's math teacher asks her to show her work to validate how she arrived at the answer. Publishing code for a technical audience makes my reasoning visible in much the same way. I need to explain why I made particular choices, what assumptions I'm relying on, and what evidence supports my conclusions. Does the example behave correctly beyond the handful of rows I tested? Did I measure what I think I measured? Have I dismissed an alternative without giving it a fair shot? Did I ignore an environmental factor that doesn't affect me but might affect others? Knowing that someone might ask those questions makes me ask them first.
I find that a much more effective way to tighten up my work than another round of back-and-forth with an LLM. Those conversations are useful, but I choose what context to provide, which questions to pursue, and when I'm satisfied. Someone reading my post may bring an entirely different set of experiences and immediately spot an assumption I never thought to challenge. Publishing to that audience gives me a stronger reason to inspect every decision and make sure I can explain it.
That benefit starts before I publish the post, before I've contemplated a featured image, and even before I send a draft to Andy Mallon or Melissa Connors for sanity checking (and they always suggest improvements). Sometimes the act of explaining a choice reveals that I need to change the code or that I'm missing a caveat, dependency, or version requirement. And I learn from readers all the time: sometimes a reader finds something I missed anyway, which gives me another opportunity to improve the post. Being willing to share the work also means being willing to correct it and carry what I've learned into the next post or conversation.
Back to the start
So yes, I still think blogs are relevant. My reading and writing habits have changed, but I still value a thoughtful explanation from someone willing to share their work, their mistakes, and their opinions. I still have plenty of all three to share myself. If you've worked through a problem, reconsidered some advice, challenged long-standing techniques, or found a way to explain something that finally made it click, you probably have something worth writing down, too. Someone else may be looking for exactly that perspective, even if they don't know to ask for it yet.