I’ve been reading technical content for over a decade, and there’s a pattern that trips up junior developers and frustrates seniors more than anything else: most articles explain what to do, but skip the why. They hand you a snippet, maybe a step-by-step list, and leave you with a working solution and zero understanding. That’s not education—it’s copy-paste bait.
When I was first learning C, I stumbled across a tutorial on pointer arithmetic. It showed me how to increment a pointer to walk through an array. The code worked. But I didn’t grasp why adding 1 moved the pointer by the size of the data type. I spent hours debugging a buffer overflow later because the article never mentioned memory layout or alignment. That gap cost me real time.
This isn’t just a beginner’s problem. I’ve seen senior engineers argue in code reviews about patterns they learned from articles that never explained the underlying trade-offs. A React component wrapped in useMemo everywhere because “the blog said it improves performance”—without understanding that memoization has its own overhead and isn’t free. The “what” without the “why” creates cargo-cult programming.
The Real Cost of Skipping the Why
Let’s get concrete. Consider a typical article on SQL indexing. It might tell you to “add an index on columns used in WHERE clauses.” That’s the what. But if you don’t understand how B-tree indexes actually work—how they maintain sorted order, how they affect write performance, how the query planner chooses them—you’ll blindly index every column and wonder why your inserts are slow.
I once consulted for a team that had indexed every foreign key in their PostgreSQL database because a popular blog post said so. Their write throughput tanked. The article never explained that indexes are a trade-off: faster reads for slower writes and more storage. The why would have made that obvious.
This pattern repeats everywhere. A Python article shows you a decorator like @staticmethod but doesn’t explain the method resolution order or how descriptors work. A Git tutorial tells you to git rebase without covering the DAG (directed acyclic graph) underneath. You end up with developers who can follow recipes but can’t debug when something breaks.
Why the Why Gets Left Out
I think there are a few reasons. First, explaining the why is harder. It requires the writer to actually understand the system deeply, not just know the incantation. Writing a shallow how-to is fast; writing a deep explanation means wrestling with edge cases and mental models.
Second, there’s pressure to keep articles short and “actionable.” Many platforms optimize for time-on-page or quick wins. An article titled “How to Use React.memo” will get more clicks than “The Reconciliation Algorithm and When Memoization Actually Helps.” But the latter is what prevents bugs.
Third, some writers assume the reader doesn’t care. They think developers just want the answer. In my experience, that’s wrong. The best engineers I know are relentlessly curious. They want to build a mental model, not collect snippets.
A Concrete Example: JavaScript Array Methods
Let me show you what I mean with a real code example. Here’s a typical “what” article on Array.prototype.reduce:
// Sum all numbers in an array
const numbers = [1, 2, 3, 4];
const sum = numbers.reduce((acc, curr) => acc + curr, 0);
console.log(sum); // 10
That’s fine. It works. But here’s what’s missing: why would you use reduce over a simple loop? What’s the time complexity? What happens if the array is empty and you omit the initial value? What about sparse arrays? None of that gets covered, and suddenly you have a developer using reduce for everything because it’s “functional”—even when a for...of is clearer and often faster.
Now contrast that with a “why” approach. I’d start by explaining that reduce is a general-purpose iteration tool derived from fold operations in functional languages. It’s useful when you need to accumulate a value that doesn’t match the array’s shape. But it’s also easy to misuse. Here’s a case where reduce obscures intent:
// Bad: using reduce to filter and map
const activeUsers = users.reduce((acc, user) => {
if (user.isActive) {
acc.push({ name: user.name, id: user.id });
}
return acc;
}, []);
This works, but a filter followed by map is more readable and often more efficient because the engine can optimize chained array methods. Understanding the why—the performance characteristics and readability trade-offs—lets you make better decisions.
The Performance Angle: Why Understanding Matters
Let’s talk about performance, because this is where shallow articles cause real damage. I recently read a post about Python list comprehensions that claimed they’re “always faster” than loops. That’s dangerously incomplete.
Yes, list comprehensions are implemented in C and can be faster for simple cases. But if you’re doing complex logic inside that comprehension, you’re still paying the Python bytecode cost. Worse, if you’re building a large list in memory when a generator expression would suffice, you’re wasting RAM. The why—understanding that comprehensions eagerly evaluate and allocate a full list—is critical.
Here’s a quick benchmark I ran:
import timeit
# List comprehension
comp = timeit.timeit('[x**2 for x in range(1000)]', number=10000)
# Generator expression summed
gen = timeit.timeit('sum(x**2 for x in range(1000))', number=10000)
print(f"List comp: {comp:.4f}, Generator: {gen:.4f}")
On my machine, the generator sum was slightly slower for this trivial case, but it used constant memory. With a million elements, the list comprehension would allocate ~8 MB, while the generator stays lean. If the article doesn’t explain memory pressure and evaluation strategy, you won’t know when to pick one over the other.
What a Good Why Article Looks Like
I’m not saying every article should be a PhD thesis. But a solid technical piece should answer three questions:
- What is the mechanism? Explain the underlying system—the algorithm, the data structure, the protocol. Don’t just show the syntax; show the state machine or memory model.
- What are the trade-offs? Every technical decision has downsides. Be explicit about them. If you’re advocating for microservices, talk about network latency and data consistency. If you’re pushing TypeScript, mention the build step complexity.
- When should you not use it? This is the killer. A tool or pattern isn’t universally good. Give concrete counterexamples. For
useMemo, show a case where the comparison cost outweighs the rendering savings.
For instance, a good article on Docker wouldn’t just show you a Dockerfile. It would explain namespaces and cgroups, discuss how layering affects image size, and warn you about running databases in containers without proper volume management.
The Reader’s Responsibility
This isn’t just on writers. As a reader, you need to be skeptical of any article that gives you a solution without context. When you see a code snippet, ask: Why does this work? What assumptions does it make? What happens if I change the input? Break it. Poke at it. Read the source code or the specification.
I’ve made it a habit to never use a pattern until I can explain it to someone else. If I can’t teach it, I don’t understand it. That discipline has saved me more times than I can count.
Writing the Articles We Need
If you write technical content, I challenge you to shift your focus. Before you hit publish, ask: did I explain the why? Did I show the downsides? Did I give the reader a mental model they can apply elsewhere?
Some of the best articles I’ve ever read were deep dives that took me an hour to work through. They didn’t give me a quick fix; they gave me a foundation. That’s what lasts. That’s what turns a junior developer into a senior one.
Let’s stop feeding the copy-paste culture. Code without understanding is just typing.
FAQ
Why do so many tech articles skip the “why”?
Mostly because it’s easier and faster to write a surface-level how-to. Deep explanations demand more expertise and time, and many platforms reward shorter, click-driven content. There’s also a misconception that readers don’t want the theory—but in practice, the best developers crave understanding, not just answers.
How can I tell if an article explains the “why” well enough?
Look for three things: the underlying mechanism (how it actually works), the trade-offs (what you’re sacrificing), and explicit counterexamples (when not to use it). If an article only shows you happy-path code without discussing edge cases or performance implications, it’s likely shallow.
Isn’t it okay to just get a quick solution sometimes?
For one-off scripts or throwaway code, sure. But if you’re building production systems or trying to grow as an engineer, quick solutions become technical debt in your brain. Without the why, you’ll struggle to adapt the solution to new problems or debug it when it fails. Invest the time to understand.
