Drowning in Data,
Starved for Information

What is Information?

We have never produced more information than we do today, and we have never felt more starved for it. Every day pours another flood of feeds, alerts, dashboards, and documents over us, and somehow the more of it arrives, the harder it gets to find anything that actually tells us something. That paradox is what this piece is about, and it starts with a deceptively simple question: what is information, really?

It’s a question I bumped into at work, where I kept hearing people use the word “information” to mean, well, almost anything. I figured I’d write a short piece to clear it up. You can probably guess how that went: the more I dug, the bigger the hole got.

I’ll come at this through my own corner of the problem, technical writing, because that’s where I watch it play out every day. But the question is much bigger than docs. It’s the same one sitting underneath your overflowing inbox, the report nobody reads, and the news feed that leaves you knowing less than when you started.

A memory from high school came back to me as I started: studying for an informatics exam, learning the definition of information for the first time. So I did the obvious thing and looked it up. Here is where I should admit something: I write technical documentation for a living. My entire job is turning murky things into clear information. And yet the one word I built a career around, information itself, was nowhere to be found in any clean, usable form online. The expert was stumped by the dictionary. What I found instead was this:

Every one of these is true enough in its own way, and not one of them is any help. They all circle the word without landing on it, which is exactly the problem in an age where we’re buried under so-called “information” from every direction. Nowhere does this sting more than in technical documentation, where clarity is the entire point. And yet plenty of IT companies still treat their docs as a billboard, slipping marketing into the instructions. It’s a strange instinct: nobody opens documentation hoping to be sold to. They’re there because something is broken and they want it fixed. Mix the pitch in with the help, and you weaken both.

Nobody opens documentation hoping to be sold to.

It’s worth saying too: documentation can never be better than the thing it describes. If the product is a tangle, the docs are stuck trying to make sense of a tangle, and no amount of clean writing fully hides a mess underneath.

Somewhere around here I realized this wasn’t going to fit in a single tweet.

Definition of Information and Data

The best definitions I’ve ever found didn’t come from a dictionary at all. They came from József Holczer, specifically his 2008 study guide for the Hungarian informatics graduation exam. Yes: a high-school cram book quietly out-defined the entire internet. I’ve never quite gotten over it, and I owe him this article.

Information: Information refers to new knowledge that is necessary and understandable for the person acquiring it. For example, the chemical formula of ethanol does not constitute information for a preschooler, as they neither need it nor understand it. However, during a chemistry test, that same formula can be of great value.

Data: Data is a specific manifestation of information. It’s important to note that different data can convey the same information. For example, the information represented by the ethanol formula can be expressed as C2H5OH or ethyl alcohol. Similarly, a specific day can be referred to as “Tuesday” or as “the day before Wednesday.”

See the difference? The definitions floating around online, and the way most of us toss these words around, just don’t hold up next to this. Holczer’s do, especially once you step into technical territory.

A high-school cram book quietly out-defined the entire internet.

It’s worth pulling the definition of information apart word by word, because every single one is carrying weight. Drop any one and the whole thing falls over:

• New knowledge: If the person already knows it, it isn’t information to them. It’s a reminder at best. For exampleThink of the help page that says “To save the file, click Save.” Flawlessly accurate, and it tells you nothing you didn’t already know. It has to be news to the receiver.
• Necessary: If they don’t need it, it isn’t information to them either. For exampleWe’ve all hit the page that opens with three paragraphs on the history of the config format when all we wanted was to change one setting. A perfectly true fact nobody asked for is just noise wearing a tie.
• Understandable: And if they can’t make sense of it, it doesn’t count. For exampleThe error message that just says “Exception thrown: see logs” is technically information and practically a locked door. The most brilliant explanation in the world is useless the moment it sails over the reader’s head.

Notice what’s missing from that last part: language. I never said the expert had to speak your language, and that’s the point. Communication is bigger than the words. Two people can share a language perfectly and still fail to communicate, buried under jargon, a confusing diagram, or a step that assumes knowledge you don’t have. Understanding is about clarity and accessibility, not vocabulary. The bomb doesn’t care what language the instructions are in. It cares whether they actually land.

Holczer’s definition of data is almost perfect. Almost. I’d add one thing, with the pedantry of someone who does this for a living: in IT and technical documentation, data is always precise and unambiguous. Not necessarily measurable (“the day before Wednesday” isn’t a measurement, yet it still points to exactly one day), but always pinned down to a single, clear reading. It’s a unit of information that means something to the right audience, and it has to be exact and specific, so that whatever it’s carrying arrives intact.

Creating Information in Technical Documentation

Turning data into information is part craft, part science, and a fair bit of stubbornness. You’re taking something complex and jargon-heavy and reshaping it into something a person can actually pick up and use. That’s harder than it sounds, and it all hinges on one thing: the reader. Not the data, not the feature, the reader. Nobody curls up with the docs for fun. They’re there because they have to be, maybe a developer pushing to production at 2 a.m. with the deploy hanging, or someone poking at a new feature that won’t behave. Documentation earns its keep at exactly that moment, when intuition runs out and the obvious fix doesn’t work. To help, it has to hand them something findable, readable, and usable, fast, something that clears the same three bars as any other information: new, necessary, understandable.

Here’s what that looks like in practice. Picture the raw data as one line in an API reference. True, precise, and almost useless on its own:

Same underlying fact, but now it’s new (you didn’t know the default or the tradeoff), necessary (you were about to set it), and understandable (nobody has to guess what the bare number meant). That’s the whole job in miniature: take the screw, and tell me where it goes.

The rest is judgment calls, and every one of them is about the reader, not the data. Include too little and they leave with more questions than they arrived with. Include too much and they’re lost in the weeds, hunting for the one sentence that saves them, so lead with whatever gets them unstuck fastest. Give every fact enough context to be usable, because an API endpoint is just a string until you know what it does and when to reach for it. Choose the shape that lands easiest (a sentence, a screenshot, a diagram, a flowchart), and keep it clean enough that a stressed reader on a deadline, a colorblind reader, and someone reading it in translation can all still follow it. None of these are rules. They’re just the difference between data that sits there and information that actually arrives.

Bringing It All Together: Data to Information

So, what’s the big takeaway? Picture that flat-pack desk arriving from the factory. You tip out the box and it’s already wrong: a bolt missing, a fistful of screws that clearly belong to some other product, and, naturally, no note admitting any of it. That’s where most data actually starts. It's called dirty data: incomplete, inconsistent, the gaps and mismatches left undocumented. Try to build straight from that pile and you’ll end up with a wobbly table, or worse, a piece of modern art you didn’t ask for.

The first real job isn’t building. It’s cleaning up. You lay every piece out, set aside the screws that don’t belong, track down the missing bolt, and keep at it until what’s in front of you is a complete, trustworthy set of parts. That’s data: still just a pile, not useful yet, but finally honest, pieces with potential, waiting for instructions.

The first real job isn’t building. It’s cleaning up.

Only then can you build. Follow good instructions and that clean set of parts becomes a desk you’re not embarrassed to own: clear, structured, usable. That finished desk is information. And turning the clean parts into it is exactly what good technical documentation does, except the thing it assembles is understanding.

That’s the real work. You’re not dumping data into a document and calling it a day. You’re making something a stranger can pick up and use to fix their actual problem.

And that’s the whole journey, start to finish: from chaos to clarity, from a scattered pile of facts to something that finally clicks. Just like the desk: when it’s done right, every piece lands where it belongs, and nothing’s left over.

Which brings me back to where I started, staring at those three dictionary definitions. Google said information was “facts provided or learned.” Merriam-Webster, “knowledge gained from investigation.” Wikipedia, “something which has the power to inform.” None of them is wrong, exactly. They’re screws from three different sets, each true, each missing the piece next to it. Holczer’s definition is the one that actually assembles. New, necessary, understandable: knowledge that lands with the person who needs it. The whole reason we drown in data while starving for information is that the world is very good at producing the first three definitions and very bad at delivering the fourth. So the next time someone hands you a flood of “information,” it’s worth asking the only question that matters: new to whom, needed by whom, and understood by whom?