Learning in public isn't so easy when you're buried by layers of engineering

I’ve come to appreciate that unless you’re a full-time content creator who can devote hours to polishing, the only way to publish regularly is by embracing the approach of “working with the garage door up” or “learning in public”. Show Your Work! as Austin Kleon says.

TIL-style posts about what you’ve been working on are a great type of content for your developer blog. And if your work is straightforward enough, the writing is straightforward enough too. A CSS developer could share how they use a new language feature. A UI developer could share their opinions on a React component pattern.

But as the scope and complexity of your role grows, the harder it is to write something about your day. At least this is how I’ve experienced it.

Take one of my work days recently. I was struggling with something and thought writing a note about it might help. The problem was that the “something” was generating TypeScript types from GraphQL files using GraphQL Code Generator in a Next.js project using a custom webpack config, that lives in a monorepo powered by Lerna. There were …seven tools or technologies in that sentence. My potential note is niched down so hard, it feels like there is maybe one other person in the world who can relate. His name is Geoff and chances are he’s not reading this site¹.

A way to rise to this challenge is to work on the skill of abstracting something more generic/simple from your complex work situation. A “minimal, reproducible example” via blog post if you will. Chris Coyier is good at this, turning what is layered work at CodePen into simpler hypothetical scenarios.

Say you have some JSON data like this…

Or, you could turn complaining about this challenge into post content instead, as I have here.

Footnotes

1. Geoff, if you’re reading, we should talk. ↩