In 2016 I spent a summer on the Open Event project for FOSSASIA, through Google Summer of Code. I built a drag-and-drop session scheduler on Interact.js, wired up Stripe Connect so event organizers could take payments under their own accounts, added PayPal NVP alongside it, and put a revisioning layer on top of SQLAlchemy that borrowed its UI cues from Wordpress. Along the way I wrote about a dozen blog posts walking through how each piece worked. I thought I was publishing tutorials. A year later, I'm fairly sure I wasn't.
What I was actually doing was keeping lab notes. The audience for "Generating xCal calendar in python" was not some future reader who also needed to generate xCal. It was me, six months later, trying to recover what I'd figured out. The tutorial framing was a useful fiction. It forced me to explain things clearly enough that the explanation would still make sense outside my own head. The person who most needed that turned out to be me.
Writing while you're still confused preserves the landmarks you used to navigate. You mention the detour you took, the thing the docs don't say, the subtle mismatch between what a library claims to return and what it actually hands you at runtime. All of that context disappears the moment you stop being confused. If I'd written the Stripe Connect post three months after I understood it, it would be shorter, cleaner, and useless to anyone else trying to figure it out.
Re-reading them now, the integration posts aged the best. Stripe Connect, PayPal NVP, the SQLAlchemy revisioning glue. Payment flows & audit trails are problems that recur in shape even when the APIs change. The framework posts aged the worst, because Interact.js and the Flask idioms of 2016 do not stay still. And the GSoC diary entries, the "here is what I plan to work on this week" ones, were the least useful to anyone, myself included. Commentary on work-in-progress is rarely as interesting as the work.
The post that surprised me most was the one on adding revisioning to SQLAlchemy models. I wrote it breezily, as a recipe. The problem underneath is one I've kept running into in every production system I've touched since. How do you give users a sane audit trail without making every bit of application code carry the weight? The specific library I reached for may not age well. The shape of the problem will. If I were writing that post today I'd spend less time on the pip install and more on why the naive instinct, sticking an updated_at column on every table and calling it done, misses the point entirely.
There's also a difference between writing publicly and writing privately that I didn't appreciate at the time. A private note lets you get away with "I got it, moving on." A public one doesn't, because some imagined reader might quote it back at you. I had a scratchpad file going in parallel to the blog. It never caught the mistakes the blog did, because no one was ever going to read it.
Write things down while you're still figuring them out, not after. The post-hoc version is always tidier and always less useful than the version where you were still confused. That confused version is what future-you actually needs. The paragraph that feels embarrassing to publish, the one where you admit you didn't know what the error message meant for two hours, is usually the paragraph that ages best.
I've retired those old posts. They served the purpose they were written for, which was cementing what I learned that summer, and they don't belong alongside what I write now. This entry is where they used to live.