My way of documenting is a little different. I usually takes handwritten notes while writing code .

Then after that I refine my handwritten notes and write a blog on it so that even after months I want to look into how I did that thing I can always see my blog . Also you can share your knowledge with the world 🌏.

You can see my blogs here

My knowledge-base is powered by

• Nuclino
• Microsoft Todo

Nuclino is where I write short or detailed writeups about "Things I have learned" and Microsoft Todo is where my "Things I'd want to know better" goes.

While writing code or doing research, if I am finding some concept amusing but easy to understand I copy and paste few materials from the source into a Nuclino doc about the topic; and these snippets of information is usually sufficient for me to either convert it into a detailed writeup someday, so at least refer while solving something similar.

If I find something that I don't know, instead of diving deep into the newer concept, I add it to my todo list with few reference links, usually, the top k google search results. Thus whenever I want to pick something new to learn I just go through my todo list and pick a topic to dive and once I start understanding the topic in detail I start adding it in Nuclino.

In a way, Microsoft Todo and Nuclino act as my two columns in Kanban board.

 - if a concept is easier to understand
   - make an entry in Nuclino
   - keep adding snippets of information
   - if while diving deep I stumble upon something relatively new
        - make an entry in todo
        - add some reference links to it
   - some day convert those snippets into a detailed write-up

 - if I have the bandwidth to pick new things to learn
   - pick a topic from the todo list
   - use the reference links added as a note
   - start researching continue the first ritual

If the writeup is detailed enough and topic is interesting enough, it goes out to the community through my weekly newsletter and blog.

Francisco Quintero Your way of doing sounds great to me 👍.

Btw, I think this is not easy to do and maintain(at least with me). Over the time, I have learned what not to document so that, I do not feel paranoid of not following it often.

Finally, I have settled down to followings:

• Anything that is shareable publicly, must have an entry here. Wherever applicable, should have related examples in github.
• Something that is not shareable publicly(may be very much organization specific or proprietary), I would have private EverNote pages created to maintain those for future references. In these cases too, I try to create code examples and push to Organization's GHE.
• I also bookmark my contributions to StakeOverFlow so that, I do not have to search for what quick hack I found before 😆.

It is externally important to have documentation some ways. I feel, it is equally important to share those publicly wherever possible.

Thanks for asking this question and great to read other responses too! Cheers!

My code is usually documented in the code the doc headers have examples and links to the according rfcs or papers. The second level of documentation is in the tests where I write down how to use also explaining the why as comments.

I usually build everthing including the docker/VM images or ansible/puppet for the provisioning. So in there are certain compile steps and sometimes I add my own mirrors just for the version freeze and certain binaries are statically compiled in there as well. With an explaination of why and what should be in there.

The rest ends in the README as 'how' to use it, command examples etc. My scripts or programms are always meant to run 'out of the box'.

Also I tried writing some manuals in a markdown guide. But in my experience most people don't read it. that's why I stopped and started to put the documentation in the code or scripts. so I can generate the documentation from the code.

A rather pragmatic approach after spending weeks writing documentation that maybe one dev is skimming. I rather prefer them as MD in the repo I am creating.

Also my hashnode blog has some stuff in there. But I tend to put the information at the point where people are working with it or link it from the code.

I'm still just learning and have no formal experience in working with developer teams but will offer my own experience.

When I first started learning I also wasn't sure how to document my progress. In the beginning, I was just bookmarking everything in separate folders in Google Chrome. Eventually I thought I would try blogging but that didn't work out so I stopped.

Fast forward to last year, I discovered 100 days of code. The way they had you essentially journal each day was very clever, and it was all done on GitHub. Unfortunately I did not complete the 100 days but I still documented many days. I hope to restart the hundred days soon.

Fast forward to present time, I now have a devblog on hashnode and recently signed up for Notion. Both of these offer very intuitive ways to document, journal and share my progress. While everything on notion will most likely stay private unless I share templates, I'll be able to share my progress as well as establish a personal website dedicated to my developer journey on hashnode.

If you don't have a Devblog yet, I highly recommend it. I also recommend notion.

Your process of documenting what you learn is quite similar to mine Francisco Quintero. Usually, I write about what I have learned on either a book or on a Google doc created for the particular technology or programming language. I love to use my own words when documenting because whenever I come back to look at it, I quickly remember the function of that particular method or technology.

On a Google Doc, I add images, code snippets, and a brief explanation about the code snippet and links to resources that provide more explanation on the subject.

In my book, I draw out a diagram that explains the function of the technology or method, add brief examples of how it works, and when it can be used. For example, when I learn about padding and margin in CSS, I drew a box and indicated effects of either adding margin or padding to a box.

I think it is very important to document what you learn because you would most likely need that information someday.