OP here, thanks for the feedback. Just curious - anything specific? I spent long time getting to some sort of framework for my writing and being called LLM is my constant struggle.
- the bloat, the amplified writes, the vacuum babysitting
- every charge traces to a decision, not a defect
- the verdict that spreads from community to community always stops one question early
- watch the damage happen yourself
Here's one way of how to write it in simpler language:
> These are not user mistakes and it's easy to reproduce these issues in a few lines of SQL on the latest version of Postgres. We're going to go through each of these problematic cases one by one to understand what's happening. Next, we're going to look at how other databases are solving it. Turns out there is no silver-bullet here: Postgres just makes a different set of trade-offs than other databases.
For me it's the rythm. It's a list of chapters, each with a list of subchapters, plenty of bulleted lists, and paragraphs of close to equal size with sentences of close to equal size. Everything is trying to be an element with an impact. Each sentence, each paragraph, each entry in a list, each list, each subchapter... feels like I'm being hit with an impact drill. This! Then this! Now this! Conclusion! But there's more!
I think jdnier nailed the phrases that most stuck out for me. I also agree that I would rather hear your own voice, even if you think it's less polished.
The problem is when reading something that has those LLM tells, I immediately wonder if any of the information has been vetted, and I wonder just how much LLM-fluff I'm going to have to wade through to get the information.
I can see you didn't just let the LLM do everything here and your own experience has guided and shaped the article. It is a good article overall, but the LLM-isms create a nagging sense of doubt about the quality which is hard to shake.
Do all the writing yourself, use LLMs for research and as an editor only. When using an LLM as an editor never copy its verbatim suggestion into your prose.
- while none of this is exaggerated
- it comes down to a real design choice
- the bloat, the amplified writes, the vacuum babysitting
- every charge traces to a decision, not a defect
- the verdict that spreads from community to community always stops one question early
- watch the damage happen yourself
Here's one way of how to write it in simpler language:
> These are not user mistakes and it's easy to reproduce these issues in a few lines of SQL on the latest version of Postgres. We're going to go through each of these problematic cases one by one to understand what's happening. Next, we're going to look at how other databases are solving it. Turns out there is no silver-bullet here: Postgres just makes a different set of trade-offs than other databases.
EDIT: And you can read for yourself how the LLM rates these two paragraphs compared to each other: https://chatgpt.com/share/6a6a3120-fec4-83eb-9c8b-dbb6294aa5...