Read the Fucking Manual

There's a particular kind of engineer I've been noticing more and more lately. They show up in Slack channels with half-formed questions. They post screenshots of error messages on Twitter asking "anyone know what this means?" They copy-paste compiler errors into ChatGPT and treat whatever hallucination comes back as gospel. They interrupt their teammates with questions that could be answered in thirty seconds of reading documentation.

This isn't engineering. This is learned helplessness dressed up in collaborative clothing.

The Death of Self-Sufficiency

Engineering used to mean something. It meant you knew how to research. You could read a language specification and understand what the compiler was doing. You could trace through library source code to figure out why something wasn't working. You read academic papers, man pages, and RFCs. You debugged your own problems before asking for help.

Somewhere along the way, we convinced ourselves that this was inefficient. Why spend thirty minutes reading documentation when you could ask someone and get an answer in five? Why dig through source code when you could prompt an AI and get code back immediately? Why think for yourself when the collective intelligence of social media is just a post away?

Here's what we've traded for that convenience: actual engineering skill.

The Problem with Modern "Research"

Stack Overflow is dead. I'm not being dramatic. The quality has been declining for years, and lately it's gotten worse. The good answers are buried under years of outdated advice, version-specific solutions that no longer apply, and increasingly, AI-generated nonsense that looks helpful but doesn't actually work. The experts who used to answer questions there have moved on because why would they waste time competing with bots?

AI will confidently lie to you. ChatGPT and its cousins will generate API calls that don't exist. They'll suggest libraries that were deprecated years ago. They'll write code that compiles but does completely the wrong thing. And they'll do it all with the confidence of a junior developer on their first day, which is to say, absolute certainty masking complete ignorance.

Social media is full of grifters. Post a technical question on Twitter and watch the replies roll in. Half will be people trying to sell you their course, their book, their SaaS product. The other half will be people who didn't read your question carefully and are answering something completely different. The actual helpful responses? Buried somewhere in the noise.

Slack is a nerd snipe waiting to happen. Every time you drop a question into a channel, you're potentially derailing someone else's deep work. They see the notification. They context switch. They try to help because they're good people. And now you've cost the team thirty minutes of productive time across three people instead of spending ten minutes reading the docs yourself.

What Engineering Actually Is

Engineering is problem-solving through research and experimentation. It's:

• Reading the fucking language specification when you don't understand how something works
• Tracing through library source code to see what it's actually doing
• Writing small test programs to verify your understanding
• Reading error messages carefully and understanding what they're telling you
• Consulting API documentation as your first source of truth
• Looking at academic papers when you need to understand the theory
• Checking the release notes when something breaks after an upgrade

It's doing the work. The real work. The thinking work.

When you skip this step and go straight to asking someone else, you're not learning. You're getting a fish instead of learning to fish. And unlike the proverb, in engineering, you need to catch new fish every single day.

The Collaboration Fallacy

Someone is going to read this and say "but collaboration is important!" Sure. But collaboration isn't what's happening when you post "how do I parse JSON in Go?" in a Slack channel.

Real collaboration happens in:

• Code reviews where everyone has done their homework
• Design discussions where people have researched the problem space
• Standups where blockers are identified and documented
• Office hours where dedicated time is set aside for helping others
• Pair programming sessions where knowledge transfer is the explicit goal

What's not collaboration:

• Interrupting someone's flow state with a question you could answer yourself
• Expecting teammates to debug your code for you
• Using your colleagues as a replacement for documentation
• Treating your team as a just-in-time search engine

Respect for other people's time isn't optional. It's fundamental to being a good teammate. And the first way to show that respect is to try figuring things out yourself before you ask.

The Skills You're Not Building

Every time you take the shortcut, you're weakening your engineering muscles. You're not learning:

• How to read technical documentation effectively
• How to trace through unfamiliar codebases
• How to form and test hypotheses about what's wrong
• How to narrow down the root cause of a problem
• How to verify your understanding is correct

These skills compound. The engineer who has spent years reading source code can scan a new codebase and understand it in hours. The one who's always asked others for answers gets lost immediately.

The engineer who reads specifications knows not just what works, but why it works and when it breaks. The one who copies from Stack Overflow has a collection of magic incantations they don't understand.

The engineer who's debugged hundreds of issues can look at a stack trace and immediately narrow down the problem. The one who's always been handed solutions is helpless when something goes wrong.

When Asking Is Appropriate

I'm not saying never ask for help. I'm saying exhaust your options first.

Ask when:

• You've read the docs and still don't understand
• You've traced through the code and the behavior doesn't match what you expected
• You've spent a reasonable amount of time (30-60 minutes) trying to figure it out
• You have a specific question about a specific thing, not a vague "how do I...?"
• You can show what you've tried and where you're stuck

Don't ask when:

• You haven't looked at the documentation yet
• You got an error message and didn't bother reading it
• You want someone to write code for you
• You're being lazy and hoping someone else will do the work
• You're interrupting people's flow state for something non-urgent

Sources of Truth

When you do research, use actual sources of truth:

Language specifications - Want to know how something works? Read the spec. Not a blog post about the spec. Not someone's interpretation on social media. The actual specification.

API documentation - Official docs from the library maintainers. Not random tutorials. Not AI summaries. The actual documentation.

Source code - When the docs aren't clear, read the code. It's the ultimate source of truth about what something actually does.

Man pages - For Unix tools, the man page is the authority. Not a blog post from 2015.

RFCs and academic papers - For protocols and algorithms, go to the source. The people who invented the thing wrote down how it works.

Release notes and changelogs - When something breaks after an upgrade, start here. Don't ask why something changed. Read what changed.

Building the Skill

If you've been taking shortcuts, it's going to feel slow and frustrating to start doing the work. Good. That friction is where learning happens.

Start small:

• Next time you get a compiler error, read it carefully before asking
• When you need to use a library function, read its documentation first
• Set a timer for 30 minutes and try to solve the problem yourself
• Keep notes on what you learn so you don't have to learn it again
• Build a habit of checking the source code when docs are unclear

Over time, you'll get faster. You'll learn where to look. You'll develop intuition for what kinds of problems have certain solutions. You'll become self-sufficient in a way that makes you more valuable and less dependent.

Respect and Discipline

This comes back to the themes I keep hitting in my writing: discipline and respect for others.

Discipline means doing the work even when it's easier not to. It means reading the manual instead of asking. It means thinking through the problem instead of outsourcing your thinking to someone else.

Respect means not wasting other people's time. It means not interrupting their flow state with questions you could answer yourself. It means coming to code reviews prepared. It means treating collaboration as something precious, not something to be squandered on laziness.

If you want to be a senior engineer, this is part of it. Not just writing good code, but being someone who can solve their own problems. Being someone who does the research. Being someone who reads the fucking manual.

Do Better

The next time you're about to fire off a question in Slack, or paste an error into ChatGPT, or post "anyone know how to...?" on social media, stop. Open the documentation. Read the error message. Look at the source code. Think about the problem. Try something. Fail. Learn. Try again. This is engineering. This is the job. And if you're not willing to do it, you're not engineering. You're just asking other people to engineer for you.

Read the fucking manual. Your future self and your teammates will thank you for it. If you want to challenge yourself, cut the internet connection from your machine for an hour and see if you can without direct and immediate access to Slack and social media and use the local instance of your library documentation and in-memory unit tests to figure shit out.