One thing I missed during my initial days was reading the company’s internal design docs and documentation. During my internship, I didn’t understand many things, so I frequently asked my mentor and colleagues for help. Looking back now, I feel it was a mistake not to read the documentation. It is created for us to become better engineers, and many problems can be solved by referring to these design docs and documentation.
After transitioning to a full-time Software Engineer role, I developed the habit of reading design docs, even if they didn’t belong to my team. Since multiple developers write these docs and managers review them, they provide essential context and detailed implementation nuances. If you want to adopt this practice, don’t hesitate—don’t fear the initial complexity. Everything seems challenging at first, but with time, it becomes familiar and simpler.
I developed a habit of viewing pull requests (PRs) of multiple developers and observing the suggestions provided by managers or team leads. Paying attention to these reviews helps improve productivity and teaches us how to write production-ready code with fewer suggestions from managers and team leads.
If your company or organization follows a practice of writing design docs, spend time reading them, even if they’re from different teams. It will give you a deeper understanding of your product or project and significantly enhance your skills.
Reading design docs and reviewing pull requests helps me understand the system better, write cleaner code, and solve problems faster. Make it a habit, and you’ll grow into a stronger and more productive engineer.