5 exercises on opinionated tech writing — “ORMs are overrated” and “premature microservices considered harmful.” Identify the author’s stance, spot hedging, and tell claims apart from evidence.
Reading opinion & analysis effectively
Title vs. thesis — a provocative headline is bait; the real position is usually softer and qualified
Hedging — “in my experience,” “arguably,” “YMMV” lower the strength of a claim
Claims vs. evidence — ask whether a point is asserted or actually supported
Burden of proof — notice when an author shifts who must justify a decision
Figurative language — “the ORM fights you” is friction, not a literal event
0 / 5 completed
1 / 5
Passage: Opinion: ORMs Are Overrated (For Some Teams)
Title: ORMs Are Overrated (For Some Teams)
Let me be clear up front: I am not saying ORMs are bad. For CRUD-heavy apps with a
small team and a tight deadline, an ORM like Prisma or ActiveRecord can be a genuine
productivity win. My argument is narrower than the title suggests.
What I am claiming is this: once your queries get complex, the ORM stops helping and
starts fighting you. I have seen teams spend an afternoon coaxing an ORM into
generating a query they could have written by hand in five minutes. The abstraction
that saved time on simple queries now costs time on hard ones.
To be fair, modern ORMs let you "drop down" to raw SQL when needed, and that escape
hatch is valuable. But in my experience, teams reach for it too late, after they have
already contorted their code around the ORM's limitations.
I should note that this is largely anecdotal. I have not run a controlled study, and
your mileage may vary depending on your ORM, your database, and your team's SQL
fluency. A team that is uncomfortable with SQL may well be better off with an ORM even
for complex queries.
My actual recommendation is modest: learn SQL well enough that the ORM is a
convenience, not a crutch. Then use whichever tool fits the query in front of you.
What is the author's actual stance, despite the provocative title?
A modest, balanced recommendation.
The closing line is the real thesis: "learn SQL well enough that the ORM is a convenience, not a crutch. Then use whichever tool fits the query in front of you."
Reading past a provocative title: Opinion posts often use a strong headline ("ORMs Are Overrated") to attract readers, then immediately soften it. Here the author does so in the first sentence: "I am not saying ORMs are bad... My argument is narrower than the title suggests." Never take the headline as the thesis — read for the qualified position underneath.
Why the distractors fail:
Option A overstates — the author explicitly calls ORMs "a genuine productivity win" for some teams.
Option C contradicts the whole critique.
Option D reverses the author’s praise of the raw-SQL "escape hatch."
2 / 5
Passage: Opinion: ORMs Are Overrated (For Some Teams)
Title: ORMs Are Overrated (For Some Teams)
Let me be clear up front: I am not saying ORMs are bad. For CRUD-heavy apps with a
small team and a tight deadline, an ORM like Prisma or ActiveRecord can be a genuine
productivity win. My argument is narrower than the title suggests.
What I am claiming is this: once your queries get complex, the ORM stops helping and
starts fighting you. I have seen teams spend an afternoon coaxing an ORM into
generating a query they could have written by hand in five minutes. The abstraction
that saved time on simple queries now costs time on hard ones.
To be fair, modern ORMs let you "drop down" to raw SQL when needed, and that escape
hatch is valuable. But in my experience, teams reach for it too late, after they have
already contorted their code around the ORM's limitations.
I should note that this is largely anecdotal. I have not run a controlled study, and
your mileage may vary depending on your ORM, your database, and your team's SQL
fluency. A team that is uncomfortable with SQL may well be better off with an ORM even
for complex queries.
My actual recommendation is modest: learn SQL well enough that the ORM is a
convenience, not a crutch. Then use whichever tool fits the query in front of you.
The author writes "this is largely anecdotal" and "I have not run a controlled study." What is the author doing with this language?
This is hedging.
Hedging is language that limits or qualifies a claim so the author does not overstate it. Markers here include: "largely anecdotal", "I have not run a controlled study", "your mileage may vary", and "in my experience."
Distinguishing claim strength from evidence: Hedging is not the same as conceding the argument is wrong (option C). The author still holds their position — they are just honest that it rests on experience, not data. Strong writers hedge to stay credible; spotting hedges tells you how much weight to give a claim.
Common hedging vocabulary to recognise:
in my experience, anecdotally, arguably
your mileage may vary (YMMV)
tends to, may well, I suspect
The opposite — unhedged claims like "always" or "never" — signal stronger (and riskier) assertions.
3 / 5
Passage: Opinion: ORMs Are Overrated (For Some Teams)
Title: ORMs Are Overrated (For Some Teams)
Let me be clear up front: I am not saying ORMs are bad. For CRUD-heavy apps with a
small team and a tight deadline, an ORM like Prisma or ActiveRecord can be a genuine
productivity win. My argument is narrower than the title suggests.
What I am claiming is this: once your queries get complex, the ORM stops helping and
starts fighting you. I have seen teams spend an afternoon coaxing an ORM into
generating a query they could have written by hand in five minutes. The abstraction
that saved time on simple queries now costs time on hard ones.
To be fair, modern ORMs let you "drop down" to raw SQL when needed, and that escape
hatch is valuable. But in my experience, teams reach for it too late, after they have
already contorted their code around the ORM's limitations.
I should note that this is largely anecdotal. I have not run a controlled study, and
your mileage may vary depending on your ORM, your database, and your team's SQL
fluency. A team that is uncomfortable with SQL may well be better off with an ORM even
for complex queries.
My actual recommendation is modest: learn SQL well enough that the ORM is a
convenience, not a crutch. Then use whichever tool fits the query in front of you.
In the phrase "the ORM stops helping and starts fighting you," what is the author conveying?
A figure of speech: the tool becomes an obstacle.
"Starts fighting you" is figurative — the ORM does not literally fight. The author explains the meaning in the next sentence: "The abstraction that saved time on simple queries now costs time on hard ones." So for complex queries, the ORM works against your goals rather than for them.
Vocabulary in context — personification: Tech writers often personify tools ("the compiler complains", "the linter yells at you", "the ORM fights you"). Read these as vivid descriptions of friction, not literal events. The surrounding sentences almost always restate the literal meaning — use them to decode the image.
Options B, C, and D all read the metaphor too literally, inventing a technical mechanism the text never describes.
4 / 5
Passage: Opinion: "Premature Microservices" Considered Harmful
Title: "Premature Microservices" Considered Harmful
Every few years our industry rediscovers that splitting a system into many small
services has costs. This is one of those posts. I will argue, perhaps controversially,
that most teams adopting microservices today are doing so prematurely.
Here is the claim, stated plainly: microservices solve an organisational problem, not
a technical one. They let large numbers of teams work and deploy independently. If you
do not have that problem — if you are a team of eight — you are paying the full
operational tax of microservices (network calls, distributed transactions, complex
deployment) to solve a problem you do not have.
Now, I want to be careful here. I am not claiming microservices are never appropriate.
At sufficient organisational scale, they may be the only sane option. The evidence I
can offer is mostly from war stories — my own and those of colleagues — rather than
rigorous data, and I acknowledge that limitation freely.
But the burden of proof, I would argue, should sit with the person proposing the split.
"We might need to scale later" is a hypothesis, not a justification. Build the
well-structured monolith. Earn your microservices.
According to the author, what kind of problem do microservices primarily solve?
An organisational problem, not a technical one.
The central claim is stated plainly: "microservices solve an organisational problem, not a technical one. They let large numbers of teams work and deploy independently."
Finding the core claim: The author flags it for you: "Here is the claim, stated plainly..." Signal phrases like "stated plainly", "my central point is", or "the claim is this" mark the thesis — the one sentence the rest of the post defends.
Why the distractors fail:
Option A is the opposite of the author’s point — they list network calls as a cost, not a speed benefit.
Options B and D introduce benefits the passage never claims; in fact the author calls the overhead an "operational tax."
5 / 5
Passage: Opinion: "Premature Microservices" Considered Harmful
Title: "Premature Microservices" Considered Harmful
Every few years our industry rediscovers that splitting a system into many small
services has costs. This is one of those posts. I will argue, perhaps controversially,
that most teams adopting microservices today are doing so prematurely.
Here is the claim, stated plainly: microservices solve an organisational problem, not
a technical one. They let large numbers of teams work and deploy independently. If you
do not have that problem — if you are a team of eight — you are paying the full
operational tax of microservices (network calls, distributed transactions, complex
deployment) to solve a problem you do not have.
Now, I want to be careful here. I am not claiming microservices are never appropriate.
At sufficient organisational scale, they may be the only sane option. The evidence I
can offer is mostly from war stories — my own and those of colleagues — rather than
rigorous data, and I acknowledge that limitation freely.
But the burden of proof, I would argue, should sit with the person proposing the split.
"We might need to scale later" is a hypothesis, not a justification. Build the
well-structured monolith. Earn your microservices.
The author says '"We might need to scale later" is a hypothesis, not a justification.' What argument is being made here?
Claims need justification, not speculation.
The author distinguishes a hypothesis ("we might need to scale") from a justification (evidence that you actually do). The point: "the burden of proof... should sit with the person proposing the split." A guess about the future is not enough to pay the cost today — hence "Build the well-structured monolith. Earn your microservices."
Claims vs. evidence — and intellectual honesty: Note how the author also marks the limits of their own evidence: "mostly from war stories... rather than rigorous data, and I acknowledge that limitation freely." That is hedging again — so option D (claiming rigorous data) directly contradicts the text.
Reading argumentation: watch for the rhetorical move of shifting the burden of proof. The author is not proving microservices are wrong — they are arguing the proposer must justify the added cost.