I  Don't Take Notes, I Comment My Code

I Don't Take Notes, I Comment My Code

Nothing against note-taking

Don’t get me wrong, I am a firm believer in the benefits of note-taking as a learning tool that helps retain information. It’s what got me through my entire education from primary school to university, so I’m definitely not trying to “bite the hand that fed me”. Besides, there are tons of studies that tout its benefits.

But with code it was different…

New challenges sometimes require new solutions

On my code learning journey, I’ve found that note-taking isn’t enough to help me retain key information. I would take notes while following a tutorial and the next day, I couldn’t make sense of parts of my follow-along code and my notes were little help as I was often unable to match them to the confusing parts of the code because they were disconnected.

Ok, ok, you may be thinking:

  • ‘Well, maybe that’s because you did not review your notes within the first few hours of making them (everybody knows that’s the best way to get value out of one’s notes, durrhhh)’ or

  • 'Your note-taking is probably haphazard and unstructured, that’s why you can’t figure it out the next day', or

  • 'This is crazy!? Why would anyone do this?’

Maybe you’re right, but people are different. With notes not only was I forgetting what I had learned and noted, but I also sucked at remembering to review the very notes that were supposed to help jog my memory😥😥, and well-organized notes are a great alternative but I wasn’t really good with those either.

Making the switch...

So I decided to switch to commenting my code as I followed along with tutorials, wrote my own code from scratch, or solved coding challenges. This one change proved to be a game-changer for my ability to learn to code and retain what I was learning from one day to the next.

Depending on the complexity of the concept, my comments would range from single lines to entire paragraphs (I kid you not) which obviously meant super messy and non-DRY code but I wasn’t too worried because my goal was to learn effectively and this was helping me achieve that.

Below is an example of type coercion where I played with a mixture of strings and integers in mathematical operations. This cemented the concept of type coercion in JavaScript that was previously very confusing and which I now remember effortlessly.

//Type coercion is when JavaScript automatically converts a wrong type I have entered, into the right type. 
//For example:
//12/"6"  outputs 2 
//because JavaScript automatically converts the string "6" to the integer 6 in order to perform the division operation

//How type coercion works with if-else statements

const money = 0;
if (money) {
    console.log("Don't spend it all;)");
} else {
    console.log("You should get a job!");
}
/* in all 'if' statements, JavaScript converts to Boolean and since money is zero (zero being a falsy value), JavaSrcipt automatically converts it to a false value (from number 0 to Boolean of false) and the 'else' block is executed.*/

But those notes were short compared to how long-winded some of my comments looked. See my 'novel'😅 below on database connections in MongoDB.

//db = variable that holds  my entire database
//dbConnectionStr= link from Mongo Atlas that connects my server to the database or Mongo Atlas
//db=name of my Mongo database 
// that one 'let' with a comma in line 15 lets you declare all your variables at once, instead of using 3 'let'(s)

let db,
dbConnectionStr ='mongodb+srv://demo:demo@cluster0.yv5k1.mongodb.net/todo?retryWrites=true&w=majority',
dbName= 'todo'

//the connect() method comes with MongoClient and takes in two parameters:
//1) the connection string, and 
//2) useUnifiedTopology object which prevents us from getting errors in the terminal when building our //project.
//MongoClient.connect is a promise that resolves with the connection to the database, so we add a .then() handler to consume the response we get back from Mongo Atlas.

This was my follow-along code from learning to build a full-stack app using Node.js, Express and MongoDB. The aim was to ensure I understood exactly what each line of code was doing under the hood, and my comments helped me to do that.

It may not be pretty but it works

As I progress and grasp new concepts, my comments become leaner and my code cleaner, but only because I initially wrote longer comments/notes that enabled me to actually understand the code so I could write it better in the future. I can now write MongoDB connections without needing to comment the code so profusely, and that is largely thanks to the comments in my code.

The advantage of this approach over conventional note-taking is having the notes and my code in one place, that way I could hit two birds with one stone: review my code and the accompanying explanatory notes at the same time.

Boom! and Boom! No more confusion, no more worries about forgetting to review notes in the immediate aftermath of making them.

How about you, do you have any learning methods that have helped increase your retention levels? What do you think of commenting code as a learning tool? I’d love to hear your ideas and suggestions in the comments below.

Thanks for taking the time to read me!