#4: Read ALL The Documentation
Read The 🤬ing Manual! How senior engineers consume documentation to improve their knowledge and productivity.
Technical documentation is the #1 online resource for learning how to code.1
As a software engineer, you’re already reading various docs. Programming languages, frameworks, pipelines, SaaS tools, and more are all referenced on a regular basis.
When’s the last time you read all of the docs offered by a particular language or tool?
I know, I know – your language’s standard library docs are far too vast and dull to read. Let me explain how senior engineers consume documentation:
Start by, well, actually reading the docs!
I hope you’re already reading documentation. 🔎
Manuals and docs are there to help you use the software and tools to their fullest. If you are only skimming through documentation and jumping right into the code, well, I don’t ever want to assemble an IKEA bookcase with you!
Don’t make assumptions.
Don’t read the source code first (as fun as that is).
Don’t rely on third-party information that might be out of date.
Seniors ensure the information they’re consuming is relevant, accurate, and useful.
Okay, so I don’t mean all of the docs… 🫣
Reading literally every word of documentation for a language, framework, or tool is usually not the best way to spend your time.
Here’s how seniors make the most out of documentation:
Guides vs. Reference
Documentation usually consists of two types of content: guides and reference material.
Guides such as “Getting Started” are meant to tell more of a story; to walk (guide) you through the steps of understanding the software, a particular feature, concept, etc. They help you get from nothing to a finished goal (shout out to our favorite “Hello, World!”)
Reference material usually documents specific parts of the software. API endpoints, standard library functions, client libraries, that sort of thing. Reference material is read more like a dictionary.
Seniors know whether guides or reference material contains the information most likely to help with their needs.
Must Read Sections
Whether checking out a brand new piece of tech or returning to an old favorite, here are some must-read sections of documentation:
Release Notes / Change Logs – Check out what’s new, especially if you’re using the product already. 💡 Seniors think: When was this last updated? What release cadence is used? Is there anything new that would be useful for us?
Installation & Upgrade Guides – Some tools have strict installation requirements or complex steps. A tool you already use might have a new, more convenient way to install it. 💡 Seniors think: Can I install this in our existing stack easily? How difficult will it be to maintain?
Best Practices – The authors and community that know the software best have already solved a lot of problems for you. Follow their lead. 💡 Seniors think: Is there anything we’re already doing that we can improve? What should we watch out for as we get started?
Fundamentals / Architecture Concepts – Understand the core principles that the software employs, and the fundamentals that drive its development moving forward. 💡 Seniors think: Does this align with what our team is used to? What’s critical for us to know?
When Looking For A Specific Thing
Have a problem to solve. Docs are great at helping you solve problems, but they aren’t going to come up with the problems for you. If you aren’t sure what you’re trying to accomplish, the docs might be harder to read. They don’t usually have a plot, after all. Seniors come to the docs with a clear problem to solve.
Utilize search. Both internal and external (e.g. Google), search for the specific topic or issue you’re having. Google pro tip: include the documentation’s URL to search within the docs when they don’t provide an internal search:
how to refund a customer site:https://stripe.com/docsCheck for community comments. If the docs support it, see if the community has made any comments about the reference material you’re using. Communities are great at pointing out common gotchas or better options. If the docs don’t have community options, a quick Google should help.
Look around a bit! If you’re in a reference section that’s pretty dry, maybe looking at a function in the standard library of a language, take some time to wander around a bit! See what related methods do. You never know what bits of information might stick in the back of your brain and become useful later in your career.
I Still Don’t Get It
Still feeling hesitant about why you need to read so many parts of the docs?
Reading = Learning. Never turn down a chance to learn.
Learning = Experience. Okay, I’m stretching a little on this one, but hear me out. Part of being a senior means having experience. But not all experience needs to be raw, hands-on work. Knowing about a tool and what situations it fits well into can be equally valuable when a future scenario calls for it.
They know better! Even as a senior with 20 years of experience, I’ve been surprised when the Best Practices section has a tip for a situation I tried to solve myself only looking up reference material.
It’s practice. You’ll read documentation for the rest of your engineering career. Get good at it.
It’s part of your job. Of course writing code is the fun part of your job, but that doesn’t mean you can ignore the boring parts. Still better than meetings!
It can make you more useful to your team. The better you understand, the more you can be a reference to your teammates. Even if that means sharing a link to a piece of documentation, you have information that can level up those around you. That’s what being a senior is about.
Write Documentation When You Can
Senior engineers look for opportunities to document and teach others. It is a exercise in communicating with those without the knowledge you possess, which translates well into teaching engineers more junior than you. It also makes you appreciate good documentation and the effort that goes into it.