Summer of 2017, I had finished my entrance exams, and I was back from a US trip. I had time on my hands, and I approached my uncle for something I could work on. He gave me a task, and it took me quite some hours of research to get it done. Basically, he wanted me to learn how to create static and dynamic linking libraries in C++, both from the command line as well as using an IDE (Integrated Development Environment) such as Netbeans.
My task for the first day was just to create a static linking library using from the command line. The next morning, when I went to him with the task done. He just asked me how much effort it took, and I said a lot. He smiled and told me that I did not have a new task for the day. Instead, I just had to recall everything I did the previous day, and make a documentation of the steps needed to create a static linking library from the command line. Over the next week, I would do a task every other day, and spend the rest of the days documenting the previous day’s work.
Documenting is something that has saved me a lot of time over the last few years. Not just that, it has also been helpful for my fellow developers!
I would also try to develop different games, some of which turned out good, others not so much. Whenever I told my elder sister about a game idea that I had even just tried to make a game out of, irrespective of whether it turned out good, she would ask me, “And where is the report for this game?”
She would ask me to include things like what the game was, what new things I had to learn to develop the game, what turned out difficult, why the game did/did not turn out very well, and what my takeaway from the project was. Another important thing she had me include in my reports was what I would do differently if I had to do the same project again. In some cases, it was the code design that I thought I could have done better, at other times it was how I should have done it in a team instead of attempting it alone.
It so turns out that quite a few of these things are potential interview questions that I might have to answer, related to the projects that I put on my resume. Also, when I document my small projects, it becomes a habit, and the habit makes sure that I do it for my larger projects too!
The fact that I document things has also been appreciated by some people. I did a 15 day workshop on networking in my first year, and after a few days of learning the basics, we had started to do things like creating DNS servers, or mail servers. Every night, after the workshop, I would document whatever we did. I also sent it to my instructor for feedback, and he really liked the fact that I was documenting my work.
Other than that, I also created documentations when it took me hours to solve some error, which was especially the case with react native. I also post these articles on medium, and a few days ago, I found out that it ranks among the top links when you google the error. If you want, try looking up “Duplicate Resources error React Native”.
I’ll also post some of my old documentations sometime, and you can take a look at them. However, the next time you work on a project, whether it be a small, personal project or a big one that you do as a member of a team, try documenting your role in the project. I promise you it’ll be a huge help in the future.
That’s it for this article- if you think documenting is a good idea, drop a like. Also, if you start documenting because of this article and it saves you time or turns out to be a useful habit, don’t forget to drop a like!