In your first few months as a software engineer, you will be bombarded with information. It is extremely common to feel quite overwhelmed during this period. You observe experienced engineers around you seemingly flying through tasks. Meanwhile you are stuck trying to compile the project on your machine, blocked by some obscure console error.
One common route to resolving various issues you encounter is to simply ask a team member for help. Most likely, they will happily assist you, promptly demonstrating how to fix the problem and unblocking you. You thank them and are on your merry way.
At this point, it is extremely tempting to just move on to the next item on your to-do list, and assume you will remember the sequence of steps your colleague demonstrated to fix the issue at hand.
Don’t give in to this temptation. Stop and write a quick note, either digitally or on paper, of the steps followed to resolve the problem. You will be shocked how many times you may need to reference this information in the future.
I learned to do this the hard way when I had to pester team members on multiple occasions after forgetting some of the steps to get around a common problem. Eventually I started documenting each time I probed someone for help. I now have a vast database of team knowledge documented for easy access.
As I mentioned, you can write these notes either digitally or on paper. I would lean towards documenting them digitally for a couple of reasons. Firstly, it means they are more easily searchable. Say you are seeing a specific exception when trying to run the test suite. You can paste the exception name into the search field of your digital notebook of choice and promptly pull up the workaround shared by your colleague a few weeks ago. Secondly, digital notes are easier to share. Ideally you would formalize these notes at some point into a team wiki. But even being able to copy/paste the solution to a common issue into a team chat is really convenient.
Building up a notebook of these tricks, tips and mitigation steps is invaluable. Not only does it provide you with a reference every time you encounter a previously experienced issue. It also demonstrates to your colleagues that you respect their time and use it wisely. As a side effect you are also documenting tribal knowledge in the team that can easily be shared with newer (and not so new) team members who eventually hit the same issue in the future.
This sounds like such a simple idea that it is too easy to overlook the value of it. I experienced this first hand. This is now the first thing I recommend to new members of my team. Even if you’re not a software engineer, this same strategy applies to any role. Take it and start applying it today to see the benefits for years to come.