Tanel Poder on Technical Blogging
How blogging forces a deeper understanding of hard problems – and increases the impact of your solutions
Following up on writethat.blog and Writing for Developers: Blogs That Get Read, we’re sharing the perspectives of expert tech bloggers: why they write, how they tackle writing challenges, and their lessons learned.
This time, let’s hear from “long-time computer performance geek” Tanel Poder. He’s an Oracle performance engineer, serial startup co-founder, consultant, trainer, book author, 0x.tools developer, lifelong fixer… We could go on, but Tanel’s unsurprisingly efficient statement covers it perfectly: “I solve (big) computer problems.”
Tanel just celebrated 18 years of blogging, and his answers reflect that deep experience.
Over to Tanel…
Why did you start blogging – and why do you continue?
Over the years, I had accumulated a number of useful scripts and techniques for troubleshooting the common OS & database problems I had encountered. At first, I created the blog (on June 18, 2007) as a lookup table for my future self. I uploaded all my open source tools to my blog and wrote articles about the more interesting troubleshooting scenarios. When I visited a customer to solve a problem, we could just copy & paste relevant scripts and commands from my blog. That way, I didn't have to show up with a USB stick and try to get it connected to the internal network first.
Why do I continue? There's so much cool stuff and interesting problems to write about. When writing, you have to do additional research to make sure your understanding is good enough. That's the fun part. Systems are getting more complex, so you need to find new ways to "stay systematic" when troubleshooting problems and not go with trial & error and guesswork. These kinds of topics are my favorite, how to measure the right things, from the right angle, at the right time – so that even new unforeseen problems would inevitably reveal their causes to you via numbers and metrics, without any magic needed.
What makes me really happy is when people contact me and say that they were able to solve completely different problems that I hadn't even seen, on their own, with the aid of the tools and systematic troubleshooting advice I have in my blog.
What has been the most surprising impact of blogging for you?
I think blogging and writing has made me a better problem solver. It has steered me towards trying to generalize and structure whatever solutions I happen to come up with in my work. I won't just conclude that the "problem was a hang" and "solution was a reboot" and be done with it. I want to understand and dig deeper (that's the fun research part) and generalize it to cover a wider range of issues. And once I've found a simple enough way to explain the whole chain of events, it's the perfect time to write about it.
This kind of generalization and writing for a wider audience has created a positive feedback loop for my own thinking and work. I'm not just "printing out" the latest steps I had taken, but I fit them into a bigger picture.
As far as other surprises go, some articles from 15 years ago are still useful when dealing with real-life scenarios today. Many of my old articles are about things running on Solaris or HP-UX, but exactly the same problem patterns happen on modern Linuxes too. So, when dealing with a connection storm or a priority inversion issue in a latest Ubuntu Linux container, I can still point people to an old 2010 article about the fundamentally same "chain of events" I had documented before. On different platforms, the tools, naming conventions and terminology are different, but the pathology is the same.
What blog post are you most proud of and why?
I'm proud of many of my posts, not because of the blog writing alone, but because they presented new approaches, techniques or tools I had developed. Your magic new solution is not that useful if nobody knows about it!
One cool example is the Visualizing SQL Plan Execution Time with FlameGraphs post from 2018. Here I applied already existing visualization tools (Brendan Gregg's FlameGraphs) to SQL plan execution metrics, approaching the same problem from a different angle.
It wasn't even that much of an effort since the tools for generating FlameGraphs already existed – and SQL plan node-level performance metrics too. I just had to combine them appropriately to make these technologies useful in a new way.
And now, widely used products built by other people & companies have implemented this particular SQL plan FlameGraph visualization into their developer tools. I would like to think that my blog entry had something to do with it!
What post was the most difficult to write and how did you tackle it?
The most difficult one was the Linux Performance Analysis with Modern eBPF and DuckDB posted just a few months ago in April (2025). It's about the latest version of my 0x.tools xcapture eBPF tool. It uses an always-on event tracking + sampling approach to provide full visibility into system activity. Thanks to eBPF, it can see almost everything going on in your monitored systems.
I started writing the blog post a few months (!) before its eventual publishing. I just kept finding things that could be made better in the xcapture tool itself, so that the blog entry would be even more striking! That led me to a yet-another eBPF rabbit-hole, adding more features or trying to make some parts even more efficient.
At some point, I realized what I already knew anyway. The opportunities for adding further optimizations and functionality to your software will never end. After all, eBPF is not only configurable, it's completely programmable. So I had to pull my nerd-self-control together and decide that I wouldn't add anything new into the underlying toolset before getting out a blog post about its current functionality. After all, if nobody knows about your great solution, it's not gonna be that useful!
When talking in more general terms, what helps me to set up new blog entries is to just write some keywords of the "random" thoughts in my mind into a new empty document . I don't stress about correctness or writing good prose and formatting at all. I just dump the ideas and angles for the new post into a draft document. As my posts are technical, then as the next step, I post my code snippets, test results or screenshots into the document too.
Then I move things around, expand some keywords into key sentences about what I'm trying to convey, then perhaps add section headers. Once this structure is in place, it's much easier for me to add the remaining thoughts around the key "anchor" elements and not get distracted with other stuff.
Any lessons learned that you want to share with the community?
One unexpected thing I learned is that it's not worth distracting yourself from your target audience (which hopefully includes you), even if your planned next post might end up popular. Example: Some years ago, there was a Gmail web UI update and your email reply composing boxes were sized very small. This was not good for techies who sent wide command line tool outputs and code samples in their emails.
So I found a trick for expanding the Gmail reply compose box to full screen that'd be suitable for technical content and blogged about it – hoping that it'd be useful for a much wider audience. Indeed, it did reach a wider audience, but the end result was that my blog's comments section ended up full of general email, Windows or printer troubleshooting questions from all over the Internet. I took that post down later on.
Also, blog commenting is pretty much in social media now, so you might want to add backlinks to your social media posts about your latest blog to the end of the article. I've been too lazy to do this myself though.
And last, I'm happy about my move to static hosting from a managed "CMS" system. The product details don't really matter, but I moved from Wordpress to Hugo static hosting, where all my blog entries are stored in a GitHub repo. I feel better when treating my blog writings and updates as just code, stored in a repository and rendered to the public-facing HTMLs when needed. Your static page load times will be much better too, especially when a post of yours gets popular.
Your advice for people just getting started with blogging?
Getting started: When writing your first blog entries, document your story. I mean the technical sequence of your actions. How you did something when addressing a real situation, even if there are plenty of similar articles out there. Such personal documentation will be useful as a future reference for yourself (speaking from experience), and sometimes for others too. Unless your goal is to become a random influencer with the most followers, but no substance, do not use AI to write your content.
Medium term: Start adding context of why you chose to do something like you did, given your circumstances and requirements. This is not just "rehashing documentation" that the AI chatbots these days can do very well. The "why" of tradeoffs is a deeper level of understanding that shows both your expertise in the field and helps others understand it better as well.
Long term: Address something unique. A problem that you fixed that didn't have well-known solutions documented before. Or if you found yourself doing repetitive work and ended up semi-automating it with a simple tool or even just a one-liner script, that's unique enough to publish!
A few blogs that you particularly enjoy?
These days, I tend to discover new posts or new writers via social media. Even though I still have an RSS reader, I rarely open it. There's too much good information out there to keep up with all of it.
I find these blogs worth checking out as I like the writing angle of the authors:
https://externaltable.blogspot.com/ - Luca Canali is doing performance things at CERN and has built new tools and approaches for addressing system performance (Spark, big data, databases)
https://dev.to/franckpachot - Franck Pachot is able to explain database tradeoffs from the angle I like, going deep into fundamentals, but fully connected to practical reality (lots of different databases)
Anything else you want to add?
I want to make Cat Benchmarking a thing, so please check out my CatBench Vector Search Playground open source project that combines Postgres, AI image processing, Vector Search with cats in a useful way for learning these things.
You can jump in, test out the app… and you're welcome to provide feedback and submit enhancements too! Also, I'll be doing a joint "hacking session" style webinar with Google about how I’ve been testing CatBench on Google AlloyDB Omni. If you’re interested, join us on July 23.
***
Stay tuned for more tech blogger spotlights mixed in with the monthly writethat.blog updates.
