I always insist that education is not storytelling and should not be structured as such. People want to save "twists" and "revelations" for maximum impact and it's harmful. It should actually be the other way around and be, keeping the theme, "spoilery" and repetitive. Like a good presentation you should start by saying what you'll say, say it, then conclude by saying what you said.
LLMs have made this problem extremely worse. Imagine how'd you'd explain what an MCP is in a couple words and technically, then try to look it up. There's phone books worth of pages and text that never end up getting to the point.
I agree that education is not storytelling, but I think that storytelling can be a useful tool for education.
A lot of Paul Graham and Joel Spolsky posts don't get straight to the point and usually do not follow an intro -> body -> conclusion format. A lot of them start with a story that makes the direction of the post unclear[0] or include long digressions whose value isn't immediately obvious.[1]
For a while, I struggled with this contradiction because I think good writing should quickly demonstrate the value a reader can expect, but I think Graham and Spolsky are excellent writers that frequently take their time in getting to their point.
The easy answer is that Graham and Spolsky are famous, so they can do whatever they want, and people will still read. I've come to think it's actually that writers like Graham and Spolsky are so good that the quality of the writing itself is the thing of value that keeps you interested even if you don't know what point they're going to make.
Over the years, readers learned what to expect from Joel and Paul, which gave them freedom to continue writing in their own style. I'm curious how the same writing would be received today in a very different environment - much more crowded and driven more by social media than the open web, not to mention the shift of attention towards video. I just don't think writers today have access to the attention that tech bloggers of an earlier era built up.
There is a balance. A short story can help understand. However you can go too far with stories. Joel strikes a good balance because it isn't long before you realize why the story is relevant and he cuts out a lot of details that are not relevant. He also is telling non-fiction stories, which adds additional credibility (unlike many blogs that are making up fiction stories)
My undergraduate research advisor told me "Papers and presentations are not murder mysteries." I try to keep that in mind whenever I approach explanatory writing, because the purpose is to help the audience reach understanding of where you ended up, not to replicate the epiphany you had yourself.
I was handed the paper: A rational design process, how and why to fake it [0]. It's still one of my favorit papers. Basically it tells you to, when writing documentation, go back and put in later findings in the place it would be, if the world had been completely rational. Just leave out all the weaving and late discovery, very few people cares. Retrofit documentation to pretend that everything and everyone was completely rational and had all the knowledge at the correct times. It can cut down documents by a lot.
Heh. Mine, before the diploma defense, literally told me "Assume that the panel knows everything about the math except for the stuff your did in your thesis, so tell them about that. Don't bother explaining what 'error correction codes' are, tell them about your specific construction and practical boundaries you've determined". Which, I guess, is precisely "the reader knows everything I know except this one thing" antipattern but then again, blogging is different from e.g. conference presentation, isn't it?
Yeah, deciding on your assumptions about the audience's prior knowledge is one of the toughest parts of presenting information well, I think. If you give too much info, you come across as boring or patronizing; if you don't give enough info, most (if not all) of your audience will rapidly lose interest. But it's all gotta be based on your exact audience in the moment, and that's really hard to take into account a lot of the time.
The difference is that anything an academic audience does not already know about the topic it took your own brain years to fully grok can't be taught in the three minutes before your own work has to be explained.
Case in point: "slide one, the Lagrangian of the standard model."
Many folks are great writers, but bad editors and the meandering intro is what kills most blog posts for me. Too bad because we really need more personal stories.
I start with the conclusion in the first paragraph[1], and the user can decide if it’s worth their time or not. Unless you’re Gabriel Garcia Marquez, no one’s going to read your rambling.
While I understand where you are coming from, I think some of those are subjective.
I personally prefer articles that link to other(better) sources for definining concepts instead of trying to explain everything.
So several times I read articles like a stack, starging with A, then in the middle going to B and after finishing B going back to A. It doesn't bother me at all. It actually says to me that the author understands they cannot be experts on everything and recognize other articles.
I also enjoy articles with reveal their twist late if they are not super long.
On my personal blog I am actually writing both styles (just explain right away, or build up to something that will become clear later in the article)
Last week, after following an HN link, I found myself thinking that tech blogs were starting to need that "Jump to Recipe" link that has taken over the food blogging world (for the better).
"The meandering intro" might be the most common mistake, by far, but the most damaging mistake, by far, is the failure to connect the topic with something the readers are familiar with (anti-pattern #2). Some things simply require a certain level of expertise/prerequisites to begin to understand, but I've repeatedly seen in software blogging, READMEs, etc. a failure to answer "what is this, compared to what I'm familiar with, and if I'm not familiar with anything relevant, why should I want to be?"
This applies to almost everything in the software space. New tool? New design pattern? New library? Language idiom? Language? Or, for more modern takes, new model? New harness? New harness option? New use pattern? Give a brief summary of what a project looks like without it, to convey the problem that its existence alone is solving. Then go into the details of how it might compare to other solutions.
Maybe it's just a specific way of how my brain works that finds this sort of information intuitive, and the lack of it particularly annoying.
This is a pet peeve of mine when there is a news story, opinion piece, case study where they spend like several paragraphs (or much more) telling story like it was a novel when in reality you it about maybe one or two paragraphs explaining what happened to a particular person/couple/family etc. and then get into the facts.
It is a massive turn off for me and I just simply close the window if I find they don't get start getting to the point.
I am much more forgiving if the meandering intro is done by someone that is clearly just someone writing up their own work.
It comes down to your target audience. Everyone has preferences on what they read, someone who prefers formality might not enjoy casual blogs written how people talk. And vice versa. Software engineers in general probably prefer casual blogs, but there are software engineers that hold PhDs and prefer some rigor in the writing too.
I dunno. I know it makes me an enemy of humanity and all, but LLMs have mostly replaced Stack Overflow and dev blogs for me. A dialog with something that writes well (or can take a totally different swing at an explanation if the first one isn't so good), has expert-level knowledge, and isn't egotistical. But maybe most of all the dialog part.
Anyway, I'm learning so much more so much better than I ever have before. Turns out the ultimate slop tools are also the ultimate learning tools if you use 'em right.
It doesn't really, as you can see in their traffic numbers. People are not stopping to use it because they dislike the platform (Most people would not even be aware of any moderation criticism, especially if they are just readers).
People are not using it any more as any AI assistant will give you the answer in seconds, perfectly adapted to your use case and with an easy way to ask follow up questions.
Doesn't Stackoverflow exist because people can in fact not read the documentation or source code, at least not to the point where it helps them understand their problem.
If the LLMs could get the same results by just reading documentation and source code, then the content on programming forums would be worth nothing, yet AI companies scrape them constantly... why?
Regarding "The meandering info," I found this advice very helpful:
"The sole purpose of the first sentence is to get you to read the second sentence. The sole purpose of the second sentence is to get you to read the third sentence… and so on."
Sure, if you want empty, soulless writing, akin to TikTok mind-rot and engagement bait. Get your reader's emotions up so they hate-read it. A/B test your blog for which sentences, jokes, and moral stances get the most engagement. Sell your soul to the lowest common denominator. To fight the AI slop, you must become the AI slop.
Or write something that actually provides value to your reader, communicate that value effectively, and trust your reader to recognize that value. Which would you rather read: writing that was optimized for psychologically capturing your eyeballs, or writing that was optimized for providing you something of value?
I find that I'm actually not that picky when it comes to reading technical material, at least in blog form. There's very few pieces I dropped because of how they were written.
Steve Kalabnik gave me similar feedback a year ago,[0] and I'm curious about your reading style because that feels so alien to me.
If you click on a blog post, and the writing is poor or seems LLM-generated, you keep reading? Or do you mean that you're willing to forgive more superficial things like meandering or excessive formality if the post has other redeeming qualities?
As an example, I clicked a post a few weeks ago about orchestrating Claude Code sessions[1], as that's a topic I'm interested in, but I found the writing so poor that I felt like the post was either LLM-generated or written for someone who had different needs than I did. Would you read a post like that to completion if the topic interests you?
> Or do you mean that you're willing to forgive more superficial things like meandering or excessive formality if the post has other redeeming qualities?
This! Well, kind of!
I definitely do some type of screening for pieces that I read: I may look up who the author is or what they've worked on; the piece may have been recommended by someone else I respect on social media; the topic itself may have little other writing on it online which signals that it may contain original thought, it may have been up-voted on HN and had interesting comments, etc.
That is to say, I try to evaluate whether it's worth my time reading the article in full, even as I start reading it. I do have a habit of saving URLs of things I read, and typically jot down a few personal notes in a local .md as I read along.
I do use LLM writing as a negative signal: it could be that the author hasn't spent that much time thinking about the issue, and I can spend that time reading something else from my reading list. But there's definitely been a few cases where I read pieces in full, even though they were clearly heavily LLM assisted, only because the material just seemed worth tanking through for.
Perhaps, rephrased: I seldom drop pieces because of the prose, more often I do so because it lacks substance. And, to add, it could entirely be my selective process that leads me to dropping articles less!
I actually don’t like when technical blogging/writing is too casual, that’s distracting to me, the author isn’t my pal. It shouldn’t be excessively formal (as you’ve titled it) either, but neutral and matter-of-fact.
Great post, I am definitely guilty of overreliance on links. I need to get better about summarizing what I'm linking to to avoid a forest of homework to understand what I'm talking about.
> From the reader’s perspective, there are a billion other articles they could be reading. Why should they read yours?
I'd rather read something that shows any semblance of personality than yet-another engagement/reach/marketability-optimized "article" that just follows all the established tropes and could be written by any drone or clanker.
This is something I see a lot too, and I almost covered it in the post. I think it goes hand in hand with excessive formality where people think that if you're writing a blog post about something, you have to be an authority on the topic, but that's not true.
It's valuable and useful to write about things when you're still a beginner as long as you present yourself as a beginner. Julia Evans does this extremely well. My favorite example is "Some notes on using nix,"[0] which got me to start using Nix when I'd seen lots of other posts from more experienced Nix users that were too in the weeds for me to understand. But the way Julia approaches it is that she's learned a little bit more than someone who's never touched it, so you can read her progress and get a slight head start from where you would have started without her notes.
it's always appropriate to share, but share your actual findings, don't imply or assume they are generalized maxims representing more than what it looked like to one guy doing one thing one time without a lot of experience.
One way to make this even better is to include your questions about things you don't know. "I wonder if that means X or Y, perhaps one way to tell would be investigating it with method Z, whihc I haven't had time to do yet, I wonder if anyone else has or knows."
Not OP, but it's the "as if I were an expert" part that rankles. It's fine to share your experiments and learning projects, but frame them as such. Some writers present their imperfect weekend experiments as if they're doing us a favor by giving out their genius for free.
Sometimes it's very easy to be confident about your expertise if you are not aware of all the complexities of a problem (See programmers and their assumptions about names and dates). So my point is a bit that it's very hard to judge that and I'd rather have someone share their learnings on their personal blog without hesitation and feeling the need to gate-keep blogging.
> I'd rather have someone share their learnings on their personal blog without hesitation and feeling the need to gate-keep blogging.
I understand what you're saying, but often well-written articles end up getting passed around and relied upon as if they were well supported documents. I don't know if it's as common now, but the Rails community went through waves of fads as someone wrote an article and then everyone read it, and started following what it said, when often it wasn't good advice in the first place.
It got the point where, if you looked at an old enough codebase, you could get a rough sense of how old some code was by looking at whatever fads it contained, and look back to see when that coding quirk was popular.
LLMs have made this problem extremely worse. Imagine how'd you'd explain what an MCP is in a couple words and technically, then try to look it up. There's phone books worth of pages and text that never end up getting to the point.
A lot of Paul Graham and Joel Spolsky posts don't get straight to the point and usually do not follow an intro -> body -> conclusion format. A lot of them start with a story that makes the direction of the post unclear[0] or include long digressions whose value isn't immediately obvious.[1]
For a while, I struggled with this contradiction because I think good writing should quickly demonstrate the value a reader can expect, but I think Graham and Spolsky are excellent writers that frequently take their time in getting to their point.
The easy answer is that Graham and Spolsky are famous, so they can do whatever they want, and people will still read. I've come to think it's actually that writers like Graham and Spolsky are so good that the quality of the writing itself is the thing of value that keeps you interested even if you don't know what point they're going to make.
[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[1] https://paulgraham.com/worked.html
0) https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
Case in point: "slide one, the Lagrangian of the standard model."
Maybe someone can tell the LLM's about these anti-patterns, like, seriously, would it help?
I'd prefer of course if people just actually themselves wrote the text that they expect me to read my human self.
I start with the conclusion in the first paragraph[1], and the user can decide if it’s worth their time or not. Unless you’re Gabriel Garcia Marquez, no one’s going to read your rambling.
[1] https://samkhawase.com/blog/email-is-crazy/
I personally prefer articles that link to other(better) sources for definining concepts instead of trying to explain everything.
So several times I read articles like a stack, starging with A, then in the middle going to B and after finishing B going back to A. It doesn't bother me at all. It actually says to me that the author understands they cannot be experts on everything and recognize other articles.
I also enjoy articles with reveal their twist late if they are not super long.
On my personal blog I am actually writing both styles (just explain right away, or build up to something that will become clear later in the article)
I find that LLM-written software blog posts generally spend like 3x as many words as would be ideal, but of course take a lot more editing and care.
This applies to almost everything in the software space. New tool? New design pattern? New library? Language idiom? Language? Or, for more modern takes, new model? New harness? New harness option? New use pattern? Give a brief summary of what a project looks like without it, to convey the problem that its existence alone is solving. Then go into the details of how it might compare to other solutions.
Maybe it's just a specific way of how my brain works that finds this sort of information intuitive, and the lack of it particularly annoying.
Not only the intro. Many bloggers try to write as if they'd writing a story, building suspense and all. For technical writing, don't bury the lede.
But also in the case where the writing is actually not technical, then... obviously the parent comment's complaint wouldn't apply? C'mon.
It is a massive turn off for me and I just simply close the window if I find they don't get start getting to the point.
I am much more forgiving if the meandering intro is done by someone that is clearly just someone writing up their own work.
Not everything is a product.
Anyway, I'm learning so much more so much better than I ever have before. Turns out the ultimate slop tools are also the ultimate learning tools if you use 'em right.
People are not using it any more as any AI assistant will give you the answer in seconds, perfectly adapted to your use case and with an easy way to ask follow up questions.
StackOverflow was always just an "answer machine".
They wanted it to be a community, but it never was.
Today LLMs have completely replaced the original role of StackOverflow.
If the LLMs could get the same results by just reading documentation and source code, then the content on programming forums would be worth nothing, yet AI companies scrape them constantly... why?
"The sole purpose of the first sentence is to get you to read the second sentence. The sole purpose of the second sentence is to get you to read the third sentence… and so on."
(quoted from https://thehustle.co/write-like-hustle-boring-stuff-writing-...; the original idea is apparently from Joseph Sugarman)
Or write something that actually provides value to your reader, communicate that value effectively, and trust your reader to recognize that value. Which would you rather read: writing that was optimized for psychologically capturing your eyeballs, or writing that was optimized for providing you something of value?
https://www.youtube.com/watch?v=vtIzMaLkCaM
If you click on a blog post, and the writing is poor or seems LLM-generated, you keep reading? Or do you mean that you're willing to forgive more superficial things like meandering or excessive formality if the post has other redeeming qualities?
As an example, I clicked a post a few weeks ago about orchestrating Claude Code sessions[1], as that's a topic I'm interested in, but I found the writing so poor that I felt like the post was either LLM-generated or written for someone who had different needs than I did. Would you read a post like that to completion if the topic interests you?
[0] https://lobste.rs/s/youq7y/how_write_blog_posts_developers_r...
[1] https://news.ycombinator.com/item?id=49772806
This! Well, kind of!
I definitely do some type of screening for pieces that I read: I may look up who the author is or what they've worked on; the piece may have been recommended by someone else I respect on social media; the topic itself may have little other writing on it online which signals that it may contain original thought, it may have been up-voted on HN and had interesting comments, etc.
That is to say, I try to evaluate whether it's worth my time reading the article in full, even as I start reading it. I do have a habit of saving URLs of things I read, and typically jot down a few personal notes in a local .md as I read along.
I do use LLM writing as a negative signal: it could be that the author hasn't spent that much time thinking about the issue, and I can spend that time reading something else from my reading list. But there's definitely been a few cases where I read pieces in full, even though they were clearly heavily LLM assisted, only because the material just seemed worth tanking through for.
Perhaps, rephrased: I seldom drop pieces because of the prose, more often I do so because it lacks substance. And, to add, it could entirely be my selective process that leads me to dropping articles less!
Happy to take any feedback or questions about this post or hear your favorite software blogging anti-pattern.
I'd rather read something that shows any semblance of personality than yet-another engagement/reach/marketability-optimized "article" that just follows all the established tropes and could be written by any drone or clanker.
This is something I see a lot too, and I almost covered it in the post. I think it goes hand in hand with excessive formality where people think that if you're writing a blog post about something, you have to be an authority on the topic, but that's not true.
It's valuable and useful to write about things when you're still a beginner as long as you present yourself as a beginner. Julia Evans does this extremely well. My favorite example is "Some notes on using nix,"[0] which got me to start using Nix when I'd seen lots of other posts from more experienced Nix users that were too in the weeds for me to understand. But the way Julia approaches it is that she's learned a little bit more than someone who's never touched it, so you can read her progress and get a slight head start from where you would have started without her notes.
[0] https://jvns.ca/blog/2023/02/28/some-notes-on-using-nix/
Yep, I agree with this.
One way to make this even better is to include your questions about things you don't know. "I wonder if that means X or Y, perhaps one way to tell would be investigating it with method Z, whihc I haven't had time to do yet, I wonder if anyone else has or knows."
I understand what you're saying, but often well-written articles end up getting passed around and relied upon as if they were well supported documents. I don't know if it's as common now, but the Rails community went through waves of fads as someone wrote an article and then everyone read it, and started following what it said, when often it wasn't good advice in the first place.
It got the point where, if you looked at an old enough codebase, you could get a rough sense of how old some code was by looking at whatever fads it contained, and look back to see when that coding quirk was popular.