An informational post tells you what happened: which technology was chosen, what the architecture looks like, what the numbers were before and after. A generative post tells you how to think about a class of problem — what questions to ask, which signals to look for, which tradeoffs to surface explicitly. Both are valuable, but they're valuable in different ways and require different extraction strategies.
The distinction between informational and generative engineering posts is not about length, detail, or prestige of the source. Short posts can be generative. Lengthy case studies from major companies can be purely informational. The difference is whether the post gives you something you can apply to a problem you haven't encountered yet, or whether it gives you knowledge about a specific problem that's already been solved.
Most engineers read informational posts more effectively than generative ones — because informational posts are easier to extract from. The lesson is explicit: this technology, this decision, this result. Generative posts require active translation: the reader has to identify the decision frame, abstract it away from the specific context, and reconstruct it as something that could apply elsewhere. That translation work is where most of the value lives, and most engineers skip it.
What a decision frame looks like
A decision frame is a structured way of approaching a class of decision — a set of questions to ask, a set of signals to look for, or a model for thinking about a tradeoff. The best engineering posts contain decision frames explicitly or implicitly, and learning to extract them is the highest-leverage reading skill in engineering.
An example: a post about choosing between synchronous and asynchronous API design might be purely informational if it says "we chose async because our operations take longer than 30 seconds." That's the decision for one system at one moment. The same post is generative if it says "we use this heuristic: if the operation's expected duration exceeds the client's comfortable wait time, and if the client has a way to receive the result later, prefer async — the crossover point shifts based on client type and SLA." Now it's a decision frame that applies to any API design decision involving operation duration and client patience.
Decision frames don't need to be stated explicitly. A post that's thorough enough about why a specific decision was made will contain an implicit frame — the criteria that would lead you to the same decision, or a different one, depending on your specific context. Extracting that implicit frame is the active reading work that makes engineering posts generative rather than merely informational.
The "what changed first" technique
One of the most reliable techniques for extracting a decision frame from an engineering post is asking: what changed first? Not which technology was adopted, not which metric improved, but what specific condition changed that made the old approach no longer acceptable.
In a post about migrating from monolith to microservices, the technology change is the surface. The "what changed first" question asks: what became intolerable in the monolith before the migration began? Was it deployment coupling between teams? Build times? Inability to scale a specific service independently? The answer tells you the actual condition that drives this class of decision — and more importantly, tells you whether your system has that condition.
This technique surfaces the operative constraint more reliably than reading for the conclusion because it forces attention to the before state, which is where the engineering judgment happened. The after state is the result of that judgment; the before state is where the frame was applied. Most posts describe both, but treat the before state as context (background to be absorbed) rather than content (the frame that generated the decision). Treating it as content is the reframe.
When reading an engineering post, ask "what changed first?" before asking "what did they do?" The first answer tells you the constraint. The second tells you one possible response to that constraint. The first is more broadly applicable.
Posts that contain explicit decision criteria
Some engineering posts are explicitly designed to transfer a decision frame rather than document a specific decision. These posts are usually structured around criteria — "here are the signals that tell you to choose X, here are the signals that tell you to choose Y" — and they're among the most durably useful things in engineering writing.
The challenge with criteria-based posts is that the criteria are only as good as the number and variety of cases that informed them. A post that derives criteria from one large migration project may have criteria that are specific to that project's constraints. A post that derives criteria from observing multiple teams making the same class of decision across different contexts is more likely to produce criteria that generalize.
Reading criteria-based posts requires asking: where did these criteria come from? Were they derived from observation of multiple cases, or rationalized from a single decision? Posts that acknowledge the limits of their criteria — "this heuristic works for teams with X characteristic; if your team has Y characteristic, you need a different frame" — are more honest and often more useful than posts that present criteria as universally applicable.
Building your own decision frame library
Engineers who read widely and extract decision frames accumulate something more valuable than a list of technologies they've heard of: a library of structured ways to think about recurring engineering problem classes. That library compounds over time in a way that informational knowledge does not.
Informational knowledge has a half-life. Technologies change, specific metrics from specific systems at specific scales become irrelevant as your context changes. Decision frames are more durable because they operate at a higher level of abstraction — they're about how to think about a class of tradeoff, not which specific option to choose.
The practical recommendation: when reading an engineering post, take thirty seconds at the end to write one sentence that captures the decision frame, not the decision. "This team chose X" is not a frame. "When operational complexity of managing two systems exceeds the benefit of their separation, consolidation is worth the migration cost" is a frame. The sentence should be applicable to a situation the original post never described. If it isn't, you haven't abstracted far enough.