The Clash Between “Read the Error Message” and the Missing Translation Layer
In IT workplaces, you sometimes hear comments like this:
“Isn’t the answer written in the error message?”
“Am I supposed to be your English translation tool?”
“Please read before asking.”
“Do not ask without trying anything first.”
The frustration is understandable.
Error messages often contain useful clues.
Search engines often show similar cases.
At minimum, the person asking should explain what they tried, what they expected, what actually happened, and where they got stuck.
But when that frustration is expressed directly, it can sound aggressive.
This is not just about bad personalities.
Of course, some people are simply rude.
But structurally, IT workplaces contain many conditions that make this kind of conflict likely.
Some People Enter IT Because Systems Feel Easier Than People
IT is not a job without human interaction.
In reality, IT work often requires:
- Gathering requirements
- Clarifying specifications
- Receiving bug reports
- Explaining issues to non-engineers
- Adjusting explanations to the listener’s understanding
- Extracting information from people who do not know what they do not know
That is advanced communication work.
However, some people enter IT because they feel:
“Computers are easier than people.”
“Sales or customer service sounds harder.”
“Logs, specifications, and code feel more reliable than human emotions.”
This creates a mismatch.
IT is not an escape from humans.
It is often the work of translating vague human needs into forms that machines can process.
When someone who dislikes interpersonal communication enters IT, they may later feel:
“The request is too vague.”
“Why don’t they read the error message?”
“Why am I being treated like a translation tool?”
The feeling is understandable.
But in many workplaces, that translation function becomes part of the job.
The Person Asking Also Has Responsibility
Of course, the person asking also has responsibility.
The hardest IT questions are vague questions.
Examples:
“It does not work.”
“There is an error.”
“It worked before.”
“It suddenly stopped.”
“Please fix this.”
With only that information, the responder has to start with an interrogation rather than troubleshooting.
A useful question should include:
- Error message
- What action caused it
- Expected result
- Actual result
- What was already tried
- Steps to reproduce
- OS, browser, app version
- When the problem started
- Urgency
Without this, the responder is forced to do information gathering before problem solving.
So the engineer’s frustration is not baseless.
The problem is not feeling frustrated.
The problem is throwing that frustration directly at the other person.
“Correct” and “Acceptable at Work” Are Different
“The answer is in the error message” may be technically correct.
But if said bluntly, it can create reactions such as:
“I was mocked.”
“I am scared to ask.”
“I do not want to consult this person anymore.”
“This person is hostile.”
That hurts the responder too.
If people become afraid to ask early, they stop reporting small problems.
Then the problem grows and appears later as a larger incident.
In the end, the engineer’s firefighting work increases.
Aggressive communication may feel satisfying in the short term.
But in the long term, it often increases your own workload.
This is a common IT workplace pattern.
It is the problem of being able to read logs, but not human logs.
Psychological Safety Is Not Weakness
This is where psychological safety matters.
Psychological safety is sometimes misunderstood as “being nice all the time” or “never pointing out mistakes.”
That is not the point.
Google’s re:Work identifies psychological safety as a key factor in effective teams. In psychologically safe teams, members can take risks, ask questions, and admit mistakes more easily.
Reference: https://rework.withgoogle.com/intl/jp/guides/understanding-team-effectiveness
In IT, this matters because bugs, configuration mistakes, and misunderstandings are cheaper when surfaced early.
If people are punished for asking, problems go underground.
Problems that go underground usually explode later.
A strong IT workplace is not merely a kind workplace.
A strong IT workplace:
- Allows people to ask questions
- Improves vague questions
- Teaches people to read error messages
- Shares a question template
- Avoids unnecessarily hostile answers
- Moves repeated explanations into documentation
Professionalism Includes Respect
IT work is technical work, but it is also professional work.
The ACM Code of Ethics and Professional Conduct asks computing professionals to avoid harm, respect others, and strive for high quality processes and products.
Reference: https://www.acm.org/code-of-ethics
This means that technical skill is not enough.
Communication, explanation, and accountability are also part of professional work.
There will be moments when you want to say, “Just read it.”
But professionalism is not about insulting people who cannot read the message yet.
It is also about creating systems that help people understand what to read next.
But Do Not Treat Engineers Like Free Translation Tools
Both sides matter.
The responder should not be hostile.
But the asker should not throw vague, unprocessed problems at engineers either.
When someone asks without reading, trying, or organizing anything, they are treating the engineer as a free translation tool or repair machine.
That exhausts people.
So the asker needs a minimum standard.
A Better Question Template
Goal:
I want to do X.
Problem:
I am getting error Y.
Error message:
XXXXXX
What I tried:
1. Restarted the app
2. Checked setting A
3. Read this help page
Expected result:
I expected Z to happen.
Environment:
Windows 11, Chrome, version XX.
This alone reduces the responder’s burden significantly.
Safer Ways to Respond
Internally, you may think:
“Read the error message.”
“Am I your translation tool?”
“Tell me what you tried first.”
“How many times do I have to explain this?”
But saying that directly at work often creates damage.
A safer version is:
The error message contains an important clue, so let’s look at this part first.
Next time, please send the error message, what you tried, and what you expected.
That will help us solve it faster.
A stronger version:
With this information alone, I cannot narrow down the cause.
Next time, please include the error message and reproduction steps.
That will make support much faster.
For repeated questions:
This issue has come up several times, so I will summarize the steps.
Please check this guide first next time, and ask if it still does not work.
This turns frustration into a process.
IT Workplaces Need a Translation Layer
What IT workplaces really need is a translation layer.
Someone or something must translate:
- Vague non-engineer language into technical details
- Technical language into understandable explanations
- Error messages into next actions
- Repeated questions into documentation
- Individual frustration into team processes
Without this layer, engineers and non-engineers collide directly.
Then the pattern becomes:
Asker: “It does not work.”
Engineer: “Read the error message.”
Asker: “That sounds aggressive.”
Engineer: “Why don’t you read before asking?”
This is not just an individual personality issue.
When there is no translation layer, humans become unhandled exceptions.
Label: “Read the Error Message” vs. “Missing Translation Layer Engineer”
The label for this structure is:
“Read the Error Message” vs. “Missing Translation Layer Engineer.”
The asker has a problem if they do not read, search, or organize.
The responder has a problem if they use correctness as a weapon.
The workplace has a problem if it does not provide templates, documentation, education, or translation roles.
So the reason IT people can seem aggressive is not simply “IT people are rude.”
It is the combination of:
- People who prefer systems over humans entering IT
- IT work actually requiring lots of human communication
- Askers sending vague, low-information questions
- Responders getting exhausted by repeated clarification
- Correct feedback being delivered as a weapon
- Workplaces lacking a translation layer
Conclusion: IT Requires Reading Logs and Human Logs
IT workers need more than the ability to read code.
They need to read error messages.
They need to read specifications.
They need to read how the other person is stuck.
They need to read what the other person does not understand.
They need to translate frustration into process.
The asker also has responsibility.
They should provide error messages, what they tried, and what they expected.
But the responder should not assume that being correct gives them the right to attack.
IT sits between machines and humans.
Machines require precision.
Humans carry emotions and context.
That is why IT is difficult.
There will be days when you think, “Am I your translation tool?”
But at work, it is better to turn that feeling into a system.
Do not throw anger.
Create a question template.
Do not insult.
Create documentation.
Do not explain the same thing forever.
Move it into an FAQ.
If you do not, the same pattern repeats:
“Read the error message.”
“You sound aggressive.”
“Just read it.”
“Now I do not want to ask.”
Then the problem goes underground.
So the conclusion is simple.
IT work does not only require reading error messages.
It also requires reading human logs and building a translation layer.
