zlacker

> The inverted pyramid is almost always the correct format for your text.

Do you find this conflicts with "offering an interesting story that resonates with the reader"?

For example: Using inverted pyramid to describe a problem and my solution, I'd structure my writing as "here's a problem, I found this solution, using this method". Whereas a story would usually be told in chronological order: "here's a problem, I tried these methods, and came to this solution".

Or is it possible to both have your cake and eat it? Tell a good story after giving away the ending?

>>pansa2+(OP)
There's a tension here but I don't think it's a fundamental conflict.

>>pansa2+(OP)
You can have other formats as well, and the one you describe can work out, though you're at serious risk of losing the audience before the big payoff.

I think what matters the most is that the reader can tell quickly whether the text is interesting.

You could start by e.g. describing a mystery, and then proceed to reveal the truth later, this sometimes works, though if the payoff isn't there, readers will feel cheated.

>>pansa2+(OP)
I have noticed that when I wrote blog posts they tend to fall in one of the two categories. Sometimes I'm trying to share an insight, in which case I make sure not to bury the lede[1]. Sometimes it's the journey to the insight that matters more than the insight itself[2], in which case the narrative take precedence, even if it buries the lede.

In some cases it is possible to combine both, by using the storytelling formula that starts describing the outcome and then traces back to how things ended up that way.

[1]: The lede is in the title, even! https://entropicthoughts.com/code-reviews-do-find-bugs

[2]: This is all meandering discovery. https://entropicthoughts.com/deploying-single-binary-haskell...

>>pansa2+(OP)
Good story defends itself even if you know the ending.

>>pansa2+(OP)
Particularly with technical writing, I think you can definitely get away with both.

“How I Reduced My Postgres Query Latency By 100x With A Single Index”

Even in the title, I can tell you the punchline (if you wanna make your DB access faster, use an index!)

but an interested reader still wants to figure out how exactly your solution works, and you can tell them some interesting details along the way

“just enforcing unique constraints does help certain data types, but it’s not a big performance boost most of the time”

while finishing on the kicker

“Since my hottest endpoint by far was for individual users querying orders which were still ongoing, I created an index on the user field for the orders table, and included a status filter in the index, which took p90 latency from 10s to <100ms!”