This is in response to: How Do You Take Notes?

Disclaimer: the points below are more geared toward a code newbie. I'm betting that an experienced programmer won't find this helpful. But if you are one, do let me know if you did this or not, and if it helped, or what worked for you instead.

Here's what worked for me when I was a code newbie:

Write. Down. Code. Physically write it down... in your notes.

The "Success" Testimonial

A little backstory - I took web development courses back in college. At one point, we learned about an API called XMLHttpRequest. It's an old tech, but it's just another API that allows you to fetch data from a server.

Anyway, I wrote the whole thing down in my notebook - from setting up HTTP headers, to sending the request and accepting the response, along with all the magic you could do with the data. You know, typical web dev stuff.

I read it during my commute to class. I made it my goal to do all those things on the computer without referring to my notes.

Eventually, a lab test came, and guess what we had to do? You guessed it! Fetch data from some URL, display the "objects" on the browser, and so on. (I remember when using HTML tables to display responsively was the norm. Eugh ) Basically, we had to come up with a tiny CRUD app within the time given to us.

Needless to say, I passed the test since I already knew the process at heart. I remember toying with how I wanted to display the stuff on the screen (the last thing you want to spend time on). Meanwhile, my seatmates were still figuring out how to successfully get the stuff we needed to display.

Do Not Copy and Paste, But On Steroids

You've probably heard of the "do not copy and paste" tip from the coding community. This is in the context that you're learning something new. It's not a secret - the new and unfamiliar code you copy-pasted is too easy to forget. But when you write them on paper, you're applying some variation of "do not copy and paste"... it's on steroids.

What distractions?

You make it harder to get distracted from your computer (or phone). This is especially true for students who need to study for school. Interestingly, the longer I worked as a developer, the less I kept these kind of notes. It's easy to Google syntaxes and commands nowadays.

Beyond the syntax

But even experienced people in the industry still keep some notes... they're just a different kind of content.

For example, soon you might need to draw a diagram to help decide where and how to put relationships in your schema. Or you might need some mockups for this new feature you have to build.

In other words, you spew out quick and "messy" notes of your headspace. These are the kind of content you come up with during the planning and design phases of your work... before they get translated into the more beautiful diagrams and charts for your bosses and clients.

The point is, the notes may vary from person to person, but the purpose is the same - to get it out there, to make it reside in a place that won't go away. Your brain can only hold so much information.

Cheat sheets

Last but definitely not the least, you have your personal knowledge bank.

Remember when you Googled that unfamiliar thing? You had many tabs open. You then arrived with the answer after putting together some different sources. Well, you could pull out those chunks and keep them in a single place, where you can easily access them when you need them again.

Another thing - I noticed a popular term that people use is "cheat sheet". So if you've never done this before, here's some examples for inspiration: React + TypeScript Cheatsheets

The "Failure" Testimonial

Anyway, I felt the need to share this "tip" because I noticed that not everyone does it.

I don't know why, but even my classmates back in college didn't do this. They took down notes during lectures when we talked about theory, but they never did it during laboratory when we wrote actual code on the computer (and presumably applied the aforementioned theory).

I don't blame them - I myself didn't always know it was important to write things down. I was thinking, what's the point, I have a copy in my USB drive!

On my first year in college, we had a Programming Fundamentals course. To learn (and apply) these so-called "fundamentals", we solved small problems on our computer using the Java programming language.

It was fun. We did it all the time, so I found a way to solve the problems faster: I created a template of all boilerplate code, so all I had to do for each new problem is copy and paste the template, and then jump straight to coding my solution. Good bye boilerplate code, hello speed.

One day we had a "test" but there was a catch - no notes allowed. No plugging of USB drives. No Googling. Those were all considered cheating.

I understood the reasoning - the given test was meant to asses our problem-solving skills, applied through programming. When given a business problem, how would you approach solving it, and how would you translate your solution to code?

That said, how could you evaluate your real skills if you didn't solve the problem yourself, right? I repeat, this was school, not the real world where copy-pasting is actually common. There's really nothing wrong about it (unless you didn't even bother to understand why the solution worked).

Anyway, I knew how to solve the given problem. I was excited to implement it, except...

I couldn't get started because I didn't know the syntax of declaring the main method in a Java class. You know, the freaking

public static void main(String[] args)

That's it! That's literally all I had to type to get started, but alas, I couldn't remember

Imagine the frustration of knowing how to do steps one to ten but you can't because you're stuck at step zero. In other words, help the poor girl, she's f*cked.

I want to add, the no-notes rule was kinda stupid, right? I mean, it's stupid to make a test unpassable if the student doesn't know the syntax. In the real world, you can Google the syntax. But then again, it was common for students to cheat. Meaning, a few gifted students already have a copy of the solution in their USB drives. How do they have it, you ask? They copy it from students from an earlier class. These are the students that can graduate but are f*cked once they get a job (if they can get one).

A Word of Caution

Eventually, these seemingly tiny things are things you'll naturally memorize as you keep doing them in your day-to-day life... as a student in your classes, or as a developer at your job.

But in the beginning when you're trying to learn a new language, framework, algorithm, or any new tech... writing things down helps you get familiar with them faster.

But don't just memorize! Obviously you also have to understand what the code does. In fact, make it more fun - simulate! On that same paper, give it different inputs and come up with the supposed output. If your textbook or course is teaching a concept in Java, and you're learning a different language in parallel, then re-write the solutions in the other language. This way, you'll know if you're truly proficient with that language.

I'm in no way telling you to write down every single code you come across with. That just doesn't make any sense. It's your job to determine what you think is important, what you think you'll need later, or what you think is fundamental that you'll need all the time. Then ingrain that in your brain (wow it rhymed). See again: example of a really thorough cheat sheet

What's To Expect

Sometimes what you wrote down in the past has finally become second nature to you now. When you revisit those old notes, you'd be ashamed at how noob you were to even need to write those things down. That's good! It means you made progress, you're growing as a programmer.

Keep growing your knowledge repository, and within months (and years), you'll be amazed at how far you've gone. If you're an absolute newbie, your notes might consist of syntax stuff like how to declare a variable, how to loop over an array, how to assign a value, and so on. In months time, your notes may evolve into a collection of your data models of this new module you're building, and so on. You know, the kind of stuff that you can't possibly keep in your head, so you have to write them down?

Parting Words and More Theory

Back to my original story... as a new student, I had an itch to code most of the time, and I couldn't do that during my commute (I had no laptop back then). One can say that reading my physical notes was a way for me to scratch that itch even when I couldn't truly scratch that itch. Sure. But writing those notes and reading them when I had nothing to do... it helped me progress faster than if I just played with my phone during the commute.

I hope you have as much fun learning as I do. Happy coding!