#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/docs
Check 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.