What 79 TIL posts taught me about developer content
April 7 was the last one. Not that I knew it at the time. I pushed up a post about diff -y, same as I had done on the first Tuesday of the month for six and a half years. Git history on the blog repo shows 79 TIL posts dating back to September 2019. Every one of them fit the same pattern: one technique, one tool, one trick. Show the command. Explain why it works. Get out of the way.
That was the third post I wrote about diff. The first one was diff and patch for incremental file changes in 2021, back when I was at Vonage and spent most of my day elbow-deep in communication APIs. Then diff -r for directory comparison in late 2025, while I was running a developer community at Deepgram and needed to compare configs across environments. Then this one, diff -y, in April 2026. Each one a variant on the same Unix tool, six years apart, and each one taught me something I did not know when I wrote it.
I did not plan 79 posts. I planned one.
How it started
September 2019. I was a developer advocate at Vonage, working with communication APIs every day. The blog was a side project, mostly opinion pieces and deep dives that took weeks to finish. I kept starting posts and not finishing them because the scope was too big.
A TIL post is small by design. One thing you learned this week. A command, a library function, a config trick. The constraint makes it finishable. I could draft one in 20 minutes during a lunch break and have it live before the afternoon standup.
The first one was about wscat, a WebSocket testing tool. I had been debugging a WebSocket connection at work and spent an hour wrestling with raw socket connections before someone on the team showed me this tool existed. The post was maybe 200 words. Three code blocks. A couple of quick questions at the end. I hit publish and thought nothing of it.
The next month I wrote about ngrok. Then jq. Then script and scriptreplay. Each one a thing I had actually used that week, documented while the context was still warm.
What patterns emerged from 79 TIL posts
Looking at the full list now, three things jump out.
First, most of these tools are terminal tools. Not IDEs, not GUI applications, not cloud console menus. Terminal tools. The ones you run from a shell, pipe together, script into workflows. I did not consciously decide to focus on CLI tools. It happened because those were the tools that solved the problems I hit, and the easiest way to share a solution was to write down the command.
Second, the topics tracked my jobs exactly. At Vonage, I wrote about WebSocket testing, audio conversion, and API debugging. At Deepgram, the TILs shifted to audio inspection, speech-to-text pipelines, SoX commands, and ffprobe. I never planned this as a career diary, but reading them in order tells the story anyway.
Third, the format never changed. Every post in that list follows the same skeleton: title starts with “TIL:”, one- or two-line explanation, code block, short explanation of why the trick matters, maybe a second variant, then two or three FAQ questions. I broke the pattern zero times in 79 posts. The consistency made writing them automatic. I did not have to think about structure. I only had to think about the content.
What 79 posts taught me about writing for developers
Writing a TIL every month for 6.5 years taught me more about developer education than my entire career before it.
The first lesson is that developers search by problem, not by tool. Nobody searches “how does ffprobe work.” They search “why is my audio file silent” or “what sample rate is this wav.” The best developer content answers a question the reader already has, phrased the way they would ask it. That sounds obvious, but most technical writing answers questions the author wants to answer, not questions the reader is asking. TILs forced me to write about the thing I just solved, which meant the question was real. The post was written while the debugging context was still fresh.
The second lesson is that code samples need to be copy-paste runnable. Every TIL post has at least one command a reader can copy, paste into a terminal, and see the same output. Not “similar” output. Not “your mileage may vary.” The exact same output. If I cannot make that work, the post is not ready. That constraint made me test every command, verify every flag, and account for platform differences. It is the single highest-leverage quality gate in developer content.
The third lesson is about consistency. 79 posts across 6.5 years is not a lot. Some developer blogs publish that in a quarter. But those 79 posts show up for every search that matches their topic, and they keep showing up years later. A post about diff from 2021 still gets traffic. A post about ffmpeg from late 2021 has been read by more people than anything I wrote about identity protocols at Auth0. The half-life of a good TIL is longer than the half-life of most analysis pieces, because the underlying tool does not change as fast as the industry narrative around it.
The tools that came back
Pattern I noticed when I laid them all out in order: some tools appear more than once. Diff showed up three times across six years. SoX showed up twice (trimming silence, generating test tones). Python tooling showed up three times (virtual environments, pytest, pyproject.toml). Each reappearance was a different angle on the same tool family, driven by a new problem.
That is the real story of technical skill growth. You do not learn a tool and move on. You learn a tool for one purpose, then six months later you need it for a different purpose, and each iteration deepens your understanding. A 2021 post about trimming audio silence with SoX was written by someone who knew one use case. A 2026 post about generating test tones with SoX was written by someone who used it weekly. Same tool, different depth.
The era ends
I did not plan to stop after the April post. It just happened that the structure of the blog was about to change. The monthly TIL format had run its course. Not because it stopped working, but because the problem it solved had changed. Writing one post a month was a good way to start. Writing one post a day demanded a different approach.
The 79 TILs are not going anywhere. They sit in the blog archive, each one a snapshot of a specific tool at a specific time. Some of the commands still work exactly as written. Some of the npm packages have been deprecated. A few of the tools have been replaced by something better. But the problems they solved are still the same problems developers hit every day: how do I test a WebSocket, how do I convert an audio file, how do I find what changed between two configs.
That is what made the format work. It did not need to be clever. It just needed to be true.
FAQ
Why did you start writing TIL posts?
I was writing long-form blog posts on the side and wanted a lower-stakes place to document things I was learning at work. A TIL post takes 20 minutes to write and does not need editorial review. It was a way to build a writing habit without the overhead of a full article.
Did you ever miss a month?
Once or twice a post went up a day late when the first Tuesday fell on a holiday. But I never skipped a month entirely. The calendar reminder was set for the first Tuesday, and I treated it like a standing meeting.
Why terminal tools instead of frameworks or languages?
Terminal tools have a shelf life measured in decades, not months. A post about jq from 2019 still works. A post about a React hook from 2019 is probably obsolete. Developer content that ages well is content about the things that do not change.
Do you still write TILs?
The format evolved into a daily cadence with multiple content types. But the philosophy is the same: one technique, one post, show the code, get out of the way.