How PlanetScale write content, with Ben Dicken
Ben Dicken's first interactive PlanetScale article drew roughly 80,000 page views in its first week or two. His standard for every piece is harder to measure: even a reader who never buys the database should leave a better engineer.
Ben Dicken is a developer educator at PlanetScale whose path runs through database engineering and teaching computer science. He combines both disciplines in unusually deep, interactive articles about databases and the systems beneath them.
We talk about why that work takes months rather than hours, how visuals make difficult ideas tangible, what engineers can reveal by writing about their work, and how an article can support a product launch so well that readers forget they are being marketed to.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What happened when you published your first interactive PlanetScale article?
I had been experimenting with D3 visualizations of B-trees for fun and wondered whether they could become a blog post. Making the blog support them took a lot of work, but the result reached the front page of Hacker News and received roughly 80,000 page views in its first week or two. It was something I enjoyed, it was distinctive, and readers responded, so PlanetScale gave me room to keep doing it. These posts do not appear every week; each takes many hours spread over a month or two.
What is your process for creating a great technical article?
It starts with caring about the subject and doing a lot of research. PlanetScale gives me freedom to pursue ideas that will be interesting, engaging and good for the brand rather than tying every piece to a launch. I keep asking whether an engineer would actually want to read it and whether they will leave smarter, even if they never buy a PlanetScale database. That real educational value builds respect for the brand and an association with high-quality engineering.
What can engineering teams contribute to developer content?
Engineers often undersell how interesting their work is because the systems they built feel ordinary to them. Writing about the decisions and innovations behind that work demonstrates expertise more convincingly than a list of impressive former employers. It also builds trust: somebody buying a database wants evidence that the engineers operating it know what they are doing. The constraint is time — at PlanetScale roughly 90% of the company is engineers and shipping comes first — so each company has to decide how much engineering effort it can put into writing and documentation.
Can good technical writing be reduced to a set of shortcuts?
It takes practice and a lot of work. I spent years thinking about teaching and communication, including formal work on classroom methods, and still put many hours into each article. My standard is that the bar should be exceeding the bar: after something succeeds, ask how the next one can be better. You also need to seek uncomfortable feedback. I regularly ask people to review a draft and tell me what is weak, because everybody has blind spots.
Why do most company blog posts disappear without an audience?
You have to distinguish broad awareness content from product education and get inside the customer's actual problems. For PlanetScale that might mean explaining MySQL and Postgres, replication pitfalls, or publishing real benchmarks for a new Postgres release. If an engineer finds your article while solving a performance or reliability problem and it genuinely helps, they begin to associate your company with solving that class of problem. It is not enough to assume an engineer will care because you wrote it.
How important is the visual side of technical content?
Visuals attract attention, separate the work from average content, and let readers test an idea themselves. A college course on data visualization made me interested in both the code and the human perception behind it — colors, representations and interaction. The goal is not decoration. A reader might arrive for a playful visualization, but it should reinforce a concept and keep them for the educational value.
How did you structure the article on IO devices and latency?
It was a brief interactive history of persistent storage, with simulations of tape systems, spinning disks and SSDs. Readers could trigger reads and writes and experience their latency in human time. One section visualized the otherwise abstract EBS burst balance as a bank of IO operations filling and draining. Each simulation took many hours to make responsive, work in light and dark modes, and run across browsers, but it made niche infrastructure concepts graspable.
How did that educational piece support the PlanetScale Metal launch?
The article explained why storage latency matters just as PlanetScale launched a product using locally attached SSDs rather than only network-attached storage. We mentioned Metal only a few times, but the whole truthful narrative led toward the problem it solves. After investing so much in the research and having engineers review it, we could put a strong product call to action at the end without bluffing. A favorite Hacker News comment said the piece was so informative the reader forgot it was promoting a product — that was exactly the goal.
What business value did such a labor-intensive article create?
It reached the front page of Hacker News and brought many tens of thousands of visits in its first days. Large platforms already have universal awareness; a smaller company has to help people discover that it exists, understand its product, and recognize the problems it solves. Every excellent educational interaction builds that awareness and trust, then gives readers a chance to see the product behind it.
Links & references
This episode is brought to you by WorkOS.