I was never a fan of reading technical documentation of frameworks or overly complex packages. Most times, I check up articles or video tutorials that address my specific use case for these tools and just get the job done, the app works, 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 codes and learning new ways to approach problems, I wasn't gaining depth in the tools I am using. At best, after a project, all I learn is limited to the requirements of the 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 it works. 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 seeing video tutorials or reading up articles!

Documentations are oftentimes the authors' way of describing how it 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 and 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 out of the box when solving problems. You cant think out of the box if you don't even understand the box. So technical documentations arm you with more resources than articles and video tutorials.

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 sleep off 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 was for me to get the job done and it gets easier 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 and check out what the docs say.

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 table. 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. And I will sum up my experience in 4 statement s

1. I learned how experts in my field think and how 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 know were implemented in real projects
4. I learned how to use the frameworks and libraries better. Trust me, not every feature makes it to 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 can 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.

I hope you enjoyed reading this, I look forward to your view in the comments.