When Page Count Became a Measure of Effort
Published:
In July 2010, I wrote a short entry about why people write long entries.
My answer was not especially noble.
It was basically:
Look how much effort I put into this. You are not animals. Appreciate it.
Then I compared that instinct with something more serious.
Books.
Documents.
Customers.
Work.
When buying a book, I wrote, people look at the price and the number of pages.
When sending a document to a customer, the customer first looks at the number of pages.
And if the Word file is so large that it still has not opened after half an hour, people may even think:
This guy must have worked incredibly hard.
At that point, I joked, perhaps he deserves a quarter gold coin.
It was absurd.
But, as I wrote then:
That is how it works.
The joke was about page count.
The real subject was effort.
More precisely, visible effort.
Human beings have always had difficulty evaluating work they cannot directly see.
A finished result may be excellent because someone knew exactly what to do and completed it quickly.
Another result may be mediocre but visibly enormous.
Hundreds of pages.
Dozens of tables.
Huge attachments.
Complicated formatting.
Many meetings.
Late nights.
The second one often looks more serious.
Not necessarily because it is better.
Because it leaves evidence.
Effort creates debris.
And organizations love debris.
Documents.
Spreadsheets.
Presentations.
Reports.
Minutes.
Emails.
Versions.
Files named final, final2, final_revised, final_revised_last.
The work becomes easier to believe because it has weight.
This is especially interesting in engineering because engineering is supposed to value efficiency.
A good solution should remove unnecessary complexity.
A good design should make the difficult thing simpler.
A good explanation should reduce confusion.
Yet professional environments often reward the opposite signal.
The thick report.
The long specification.
The meeting that lasts three hours.
The document nobody can open.
Somewhere between engineering logic and organizational psychology, difficulty becomes proof of seriousness.
That contradiction has always amused me.
Imagine two engineers.
The first spends a week understanding a problem deeply.
Then writes ten clear pages.
The second understands it partially and writes one hundred and twenty pages.
Which one appears to have worked harder?
The answer depends on who is looking.
If the evaluator understands the subject, perhaps the first.
If the evaluator mostly sees output volume, the second has an advantage.
One hundred and twenty pages can look like dedication.
Ten pages can look suspiciously easy.
This is a dangerous incentive.
Because once people learn that visible quantity is rewarded, they produce visible quantity.
The document expands.
Simple diagrams become complicated.
Definitions repeat.
Tables multiply.
Every possible sentence gets included because removing material creates a strange fear:
What if somebody thinks we did not do enough?
This is how documentation stops serving understanding and starts serving defense.
The report no longer says:
Here is what you need to know.
It says:
Please observe how much labor happened.
Those are different purposes.
The first is communication.
The second is evidence.
Many professional documents try to do both.
That is why they become strange objects.
They must inform the reader.
But they must also reassure managers, customers, auditors, reviewers, and sometimes the authors themselves that the project contained sufficient seriousness.
Page count becomes ceremonial.
The document has to look like work.
This does not mean long documents are bad.
Some systems are genuinely complex.
Some specifications need detail.
Some reports need hundreds of pages.
Reducing everything to ten pages can hide important information just as easily as expanding everything to one hundred pages can hide weak thinking.
Length itself is neutral.
The problem begins when length becomes a substitute for evaluation.
A document is not good because it is long.
It is not good because it is short.
It is good if it helps the intended reader do the intended thing.
That sounds obvious.
In practice, it is surprisingly difficult.
Because clarity creates a psychological problem.
Clarity makes work look easy.
If I explain something well, the reader may think the thing itself was simple.
The struggle disappears from the final result.
This is one of the strange punishments of competence.
Good work often hides the labor required to produce it.
The messy drafts are gone.
The failed approaches are removed.
The unnecessary parts are cut.
The final explanation looks inevitable.
Of course this is the answer.
Of course the design should work this way.
Of course the report is only fifteen pages.
The reader sees the cleaned room.
Not the cleaning.
This happens in many professions.
A good lecturer can make a difficult concept feel obvious.
A good programmer can make a solution look small.
A good designer can make an interface feel natural.
A good writer can make a paragraph feel effortless.
The better the work, the less visible the struggle may become.
Then someone asks:
Why did this take so long?
Because the visible artifact is small.
This creates pressure to leave complexity visible.
Not because the complexity helps.
Because it proves something happened.
The old joke about the Word file taking half an hour to open captures this perfectly.
The document is practically unusable.
Yet its size becomes evidence of labor.
The failure itself becomes impressive.
Look at this monster.
Somebody really worked.
That is almost the opposite of engineering.
A technically successful document should open.
It should be navigable.
The reader should find what matters.
If size prevents use, size is not achievement.
But organizations do not always evaluate artifacts according to use.
Sometimes they evaluate them according to theater.
Effort theater.
Complexity theater.
Professionalism theater.
The appearance of rigor can become more important than rigor.
A report can look serious because it contains many sections.
A presentation can look strategic because it contains complicated diagrams.
A project can look controlled because it produces many status reports.
None of those signals guarantee the underlying work is good.
They merely produce confidence.
Confidence is valuable.
But confidence can be manufactured cheaply.
This is why experienced people learn to ask different questions.
Not:
How long is it?
But:
What decision does this support?
What uncertainty did it reduce?
What changed because of this?
Can someone use it?
Can someone maintain it?
Does the document answer the question it was created for?
These questions are harder because they require understanding.
Counting pages requires almost none.
Metrics become popular partly because understanding is expensive.
If I supervise ten people doing work I do not fully understand, I need proxies.
Hours.
Lines of code.
Number of tickets closed.
Number of pages.
Number of commits.
Number of meetings.
Number of slides.
These measurements are attractive because they are easy.
But easy measurement can distort behavior.
People optimize what is visible.
This is one of the oldest problems in management.
Tell people that page count matters, and documents get longer.
Tell programmers that lines of code matter, and code gets larger.
Tell researchers that publication count matters, and papers multiply.
Tell customer-service workers that call duration matters, and conversations change.
Measurement creates direction.
Even informal measurement does this.
Nobody needs to officially say:
Long documents are better.
People only need to observe that long documents receive more respect.
Culture handles the rest.
Then the quarter-gold joke becomes plausible.
The giant Word file appears.
The customer cannot open it.
Instead of asking why the file is badly constructed, somebody says:
The poor guy must have worked so hard.
This is funny because we recognize the instinct.
Suffering legitimizes work.
If something was difficult, it feels more valuable.
If somebody stayed at the office until midnight, they must be dedicated.
If they completed the same task at five and went home, perhaps they were less committed.
This logic rewards inefficiency.
The employee who solves problems quickly can look less busy than the employee who remains visibly overwhelmed.
That creates another kind of theater:
busyness.
Always typing.
Always carrying a notebook.
Always in meetings.
Always answering mail.
Always saying:
I am buried.
Busyness communicates importance.
Calm competence can look suspicious.
This is especially dangerous in knowledge work because the most important work may look like nothing.
Thinking.
Reading.
Staring at a diagram.
Walking.
Deleting.
Deciding not to build something.
There is very little visual evidence.
A person can spend an hour thinking and remove three months of future work.
Another can spend three months producing artifacts for a problem that should never have been solved.
Which one looked busier?
Probably the second.
I do not think organizations can eliminate this problem completely.
Invisible work will always be difficult to evaluate.
But they can avoid making it worse.
One way is to reward outcomes rather than volume.
Another is to value editing.
Reduction.
Deletion.
Simplification.
These are forms of work too.
A shorter report may represent more thought than a longer one.
A smaller codebase may represent better design.
Fewer meetings may represent clearer responsibility.
A simpler interface may represent deeper understanding.
The absence of complexity can be the product.
This takes maturity to recognize.
Beginners often add.
Experienced people learn to remove.
That does not mean minimalism for its own sake.
It means being able to distinguish necessary information from accumulated anxiety.
Many long documents are partly anxiety made visible.
What if somebody asks this?
Add a section.
What if they want that?
Add an appendix.
What if this is challenged?
Add a paragraph.
What if someone says we did not consider something?
Add another table.
Eventually the document contains every defensive thought the team ever had.
No reader can understand it.
But nobody can accuse the authors of leaving something out.
That is not communication.
It is litigation against hypothetical criticism.
I understand why it happens.
Professional life contains accountability.
Things go wrong.
People ask:
Why did you not document this?
So teams respond by documenting everything.
Then another problem appears:
Important information disappears inside excessive information.
A five-page critical instruction can become buried in a four-hundred-page manual.
Technically documented.
Practically invisible.
The existence of information is not the same as communication of information.
This distinction matters enormously.
A document can contain the truth and still fail.
If the reader cannot locate, understand, or act on it, the author has only partially succeeded.
This is why good technical writing requires empathy.
Who is reading?
Why?
Under what conditions?
What do they already know?
What are they trying to do?
What could they misunderstand?
These questions should determine structure.
Not the desire to create a heavy file.
The original entry began with Ekşi Sözlük, not engineering.
Why do people write long entries?
Because they want appreciation for the effort.
That is a universal impulse.
Writers feel it.
Engineers feel it.
Students feel it.
Teachers feel it.
You spend hours creating something.
Then somebody looks at it for thirty seconds.
Painful.
The natural response is to make the effort visible.
Maybe if it is longer, they will understand.
Maybe if the presentation has more slides.
Maybe if the report is thicker.
Maybe if I explain every step.
But readers do not owe us attention proportional to our effort.
This is difficult to accept.
The writer may spend five hours.
The reader may still give five minutes.
Communication must respect that imbalance.
Good work often means compressing five hours of thought into five useful minutes for someone else.
That can feel unfair to the creator.
It is also the point.
The reader is not responsible for witnessing the labor.
They need the result.
This is one of the transitions from student work to professional work.
In school, showing your work is often explicitly required.
The teacher wants to see the process.
In professional life, sometimes the opposite is true.
The customer does not want your struggle.
They want the answer.
Of course, traceability and justification may be necessary.
But they should exist because they support trust and verification, not because suffering needs an audience.
This is something I understand better now than I did in 2010.
The younger version of me noticed the absurdity.
He saw that page count was being treated as evidence of quality.
He laughed at it.
That instinct was correct.
But there is another side.
People use superficial signals because evaluating real quality is hard.
A customer may not have time to deeply inspect every document.
A manager may not understand every technical decision.
So visible effort becomes a shortcut.
The solution is not merely to mock them.
The solution is to make quality easier to evaluate.
Clear summaries.
Good structure.
Traceable decisions.
Useful metrics.
Explicit conclusions.
A short document should not feel like a black box.
It should feel compressed.
There is a difference.
Compression preserves information.
Omission destroys it.
Good technical communication compresses.
Bad short documents omit.
Bad long documents accumulate.
The best length is whatever lets the reader understand the required truth with the least unnecessary burden.
That is not a dramatic principle.
It will not earn anyone a quarter gold coin.
But it is probably better engineering.
Looking back, I still enjoy the image of a Word document so large that the customer watches it fail to open and becomes impressed.
It is workplace comedy because the priorities are reversed.
The file is failing at the moment it is being admired.
That kind of absurdity deserves preservation.
Every profession develops its own version.
The spreadsheet that takes ten minutes to calculate, therefore it must be serious.
The presentation with microscopic text, therefore it must be detailed.
The dashboard with fifty indicators, therefore it must be comprehensive.
The architecture diagram nobody understands, therefore it must be sophisticated.
We should be suspicious whenever incomprehensibility starts looking like expertise.
Real expertise can handle complexity.
It does not need to display all of it at once.
A pilot does not prove competence by making the passenger understand the cockpit.
A doctor does not help the patient by reciting the entire medical literature.
An engineer should not make a customer excavate the answer from page 183 simply to prove that page 183 exists.
Complexity belongs behind the interface whenever possible.
And perhaps that is the mature version of the old entry.
In 2010 I wrote:
People see a huge document and think, “He really worked.”
Today I would add:
The highest-quality work may be the document that lets them forget how hard the work was.
Because the difficulty was absorbed before it reached them.
That is not less effort.
It is effort converted into clarity.
