I might be a minority in doing this, but I still take notes by hand, with a pen and paper.
These are generally fairly high-level, and only go into specific detail if there’s something that it takes me a few goes to understand.
To give you an example, although these are typed (not hand-written) the gist is the same:
JavaScript Notes
Functions
Functions in JS can be defined in a number of ways. The “traditional” function declaration is similar to several other languages, looking like:
function functionIdentifier(parameters, optional) {
// JS functions have block-scope; variables defined with "let" here exist only within the block.
let blockScopeVariable = "some value";
// default return value if not otherwise specified in JS is "undefined"
return "some other value"
}
ES6 also introduced the concept of “arrow functions” (similar to a lambda in other languages), which are written like:
const arrowFunctionIdentifier = (parameters, optional) => {
// code block as usual
let arrowVariable = "yet another value";
return "42";
}
That’s just an example; it is impossible to be prescriptive about the notes you ought to take, because the notes that you need and which you will find helpful are unique to you.
As a recommendation, though, I would suggest that you take notes of the following:
- General notes on new concepts as they are introduced, like my functions example;
- Detailed notes on anything which you get stuck on, so (for example) if you find yourself frequently struggling with a
for
loop, then you should make sufficient notes on for loops to help you write them correctly every time until they stick.
As you go along, in whatever course you’re doing, when you get to the end of a lesson you may find it helpful to note down as much of the lesson content as you can remember without skimming back through the lesson.
Once you’ve made notes on everything you can remember, then go back through it and see whether you missed anything out. If you did, you know those bits which perhaps you didn’t retain as well as the bits you remembered at the end - and which bits you may need to revisit.
One last piece of advice I would offer you is to remember that educating yourself on coding, or anything really, is not a sprint. The 30-day challenge isn’t a competition to see how far you can get through the material in that time; it is a challenge of your time management to set aside a little time every day to learn the content of whatever path or course you’ve settled on.
Let’s say you’ve decided you want to learn Python 3. If, by the end of your 30-day challenge, you’ve got to the end of the Python 3 course you might feel accomplished. (The estimate for that course is 25 hours, so that’s less than an hour a day over 30 days.)
If you’ve got to that point, but you still can’t write a working function or keep getting for-loops wrong, then sure you’ve finished the course but you’ve not really assimilated the content. The whole point is to be able to use what you’ve learned, right? If you get to the end of the course and can’t reproduce the stuff you’ve learned, that’s no good.
This post has got a bit longer than I intended, so to summarise:
-
My notes will not be the same as your notes, but as a starting point:
1.1 Make general notes of every new concept, and
1.2 Go into greater detail on anything that you find difficult or get stuck using; enough detail that you can use your notes to get them right every time.
1.3 As you progress and make notes, adjust your note-taking as you learn what works for you. (Your notes are a unique, and personal, thing.)
-
At the end of each lesson, write (or type) out as much of the content as you can remember. This will make it easier to spot gaps in what you’ve retained.
-
The 30-day challenge isn’t a race; it’s a test of consistency, not speed. It’s about showing up every day and putting the work in to understand the content, not just sprint to the end.