Why you should always read the docs

I was never a fan of reading technical documentation for frameworks or overly complex packages. Most times, I would check out articles or video tutorials that addressed my specific use case for these tools and just get the job done. The app works, there is no stress for me, my client likes it, and everyone is happy.

However, it didn't take long for me to realize that while I was writing code and learning new ways to approach problems, I wasn't gaining depth in the tools I was using. At best, after a project, all I learn is limited to the requirements of that project. Most times, I only know how to use the tools to solve the unique case I am trying to solve and never get to learn how they work.

Articles and video tutorials are amazing, and a great shout-out to those who produce such content to help so many people like me. However, you won't become a senior developer by only watching video tutorials or reading articles!

Understanding the Box

Documentation is oftentimes the authors' way of describing how a tool works; some could even go as far as explaining why it works. The amazing benefit that comes with this is that a proper understanding of a tool's documentation allows you to explore an unending world of creativity with the tool.

You can better predict how and why your code works, which gives you the ability to think outside the box when solving problems. You can't think outside the box if you don't even understand the box. So, technical documentation arms you with more resources than articles and video tutorials.

Overcoming the Dryness

An experience I have, which I believe might be common to many people, is that technical documentation is not always the friendliest material to read. I have often found myself falling asleep while reading some of them. And yes, it takes time, which you might not be able to give based on project deadlines.

However, what I have learned is that the more I read technical documentation, the easier it is to get the job done and the easier it gets for me to comprehend subsequent documentation I read. So, while you might want to focus on getting the job done, you can always spare some time when you are less busy to check out what the docs say.

Reading Source Code

Taking it a bit further, beyond reading the documentation, you can even take time to study the code. You definitely won't be doing this when you urgently need to get a feature working or have deadlines to meet, but it is something you can always do when you don't have so much on your plate.

Now, someone might be wondering: why would I want to delve into an ocean of code that I didn't write? Well, it never made sense to me either until I started. I will sum up my experience in four statements:

1. I learned how experts in my field think and their approach to solving problems.
2. It greatly improved my sense of code architecture and software design.
3. I learned how several things I have always known were implemented in real projects.
4. I learned how to use the frameworks and libraries better.

Trust me, not every feature makes it into the documentation for several frameworks. A more recent experience was when I had to generate regular expressions from a gitignore file. I couldn't seem to find any resource online that could efficiently get it done.

However, before that time, I had been studying the codebase of the Symfony Finder component and I came across a public class that Symfony itself uses to achieve just what I wanted. This was not in the documentation and I would never have known if I didn't open up the codebase to see what it looked like.