How to take notes in CS classes?
February 1, 2013 12:35 AM Subscribe
I find taking notes in my Computer Science classes challenging. Can you share with me your techniques for taking useful notes that are specifically helpful for CS courses?
Some situations that are tough:
- sometimes the professor gives us deliberately buggy code and asks us to talk through its issues - what's the best for replicating the debugging process in my notes?
- sometimes we get many many slight modifications of the same basic program
- sometimes there's stuff I don't fully get, or stuff I know I'll want to refer to in the future - how to keep track of these?
I'm asking because among my classmates, I see three types of note-takers:
a. People who use Microsoft Word or a different word processor to just type notes like I'd do for my history classes - works, but formatting gets all messed up, no handy color coding of different components of the language, and just generally unwieldy if you want to experiment with each snippet of code.
b. People who work directly inside their text editor (we used gedit last semester, using emacs now). If we're working on variations on a change calculator, they save change1, change2, etc - I feel like it's harder to get a sense of the lecture without clicking through every one of those. And what do you do when the professor goes into theory mode and you end up needing to take notes for 5 minutes straight?
c. People who don't take notes at all, who feel comfortable with only thinking through and understanding something once - That is great for them, but I really like being able to recreate sudden blasts of understanding in my notes and reviewing them before exams or when I'm stuck on a bug or whatever.
Metafilter, I know you're lousy with computer scientists and technical folk - here's your chance to shine!
Some situations that are tough:
- sometimes the professor gives us deliberately buggy code and asks us to talk through its issues - what's the best for replicating the debugging process in my notes?
- sometimes we get many many slight modifications of the same basic program
- sometimes there's stuff I don't fully get, or stuff I know I'll want to refer to in the future - how to keep track of these?
I'm asking because among my classmates, I see three types of note-takers:
a. People who use Microsoft Word or a different word processor to just type notes like I'd do for my history classes - works, but formatting gets all messed up, no handy color coding of different components of the language, and just generally unwieldy if you want to experiment with each snippet of code.
b. People who work directly inside their text editor (we used gedit last semester, using emacs now). If we're working on variations on a change calculator, they save change1, change2, etc - I feel like it's harder to get a sense of the lecture without clicking through every one of those. And what do you do when the professor goes into theory mode and you end up needing to take notes for 5 minutes straight?
c. People who don't take notes at all, who feel comfortable with only thinking through and understanding something once - That is great for them, but I really like being able to recreate sudden blasts of understanding in my notes and reviewing them before exams or when I'm stuck on a bug or whatever.
Metafilter, I know you're lousy with computer scientists and technical folk - here's your chance to shine!
Best answer: Do your professors / instructors present with slides? Do they release them a day or so in advance so that students can print them out (4 to a page)? That was standard for my courses, and I wrote all over the .ppts.
posted by batter_my_heart at 1:16 AM on February 1, 2013 [2 favorites]
posted by batter_my_heart at 1:16 AM on February 1, 2013 [2 favorites]
Use a basic text editor and save versions of the program file using git or svn. You can then easily view the differences between versions. (and even label your commits with useful notes about what changed).
For blasts of understanding, you could (and this will make me seem old), write down a quick note or sentence onto actual paper in a notebook. This keeps your code variations and your straight up lecture notes separate. I always found that writing down those sentences helped me to remember the blast of understanding, and I almost never had to go back and read my written notes.
posted by molecicco at 4:11 AM on February 1, 2013
For blasts of understanding, you could (and this will make me seem old), write down a quick note or sentence onto actual paper in a notebook. This keeps your code variations and your straight up lecture notes separate. I always found that writing down those sentences helped me to remember the blast of understanding, and I almost never had to go back and read my written notes.
posted by molecicco at 4:11 AM on February 1, 2013
Actually. Writing on printed PPTs is even better than a regular notebook.
posted by molecicco at 4:12 AM on February 1, 2013
posted by molecicco at 4:12 AM on February 1, 2013
I might just embed the code's text file in Evernote and set it up to open the file in a text editor of choice. That makes it nice and portable, lets you stick lots of versions in the same place with notes floating around it, etc. Evernote is super duper fantastic for its ability to take little bits of all sorts of stuff.
I'd probably record the lecture in Evernote as well. I find recording meetings frees me up to pay attention. My notes are more along the lines of "@10m: discussion of XXXX" or just record separate files for each block of lecturing. If I need to, I can always come back and transcribe stuff later if necessary.
Evernote for all things not pure text.
posted by pjaust at 6:50 AM on February 1, 2013
I'd probably record the lecture in Evernote as well. I find recording meetings frees me up to pay attention. My notes are more along the lines of "@10m: discussion of XXXX" or just record separate files for each block of lecturing. If I need to, I can always come back and transcribe stuff later if necessary.
Evernote for all things not pure text.
posted by pjaust at 6:50 AM on February 1, 2013
I teach CS and for classes where I discuss code I use my usual editor and project what I am doing on the screen. My solution for what you are asking about is to save multiple copies of files as I work on them and make the various changes, and then after class to upload them to Blackboard so students can go back and look at them. Because I am working on a computer instead of the board, I also use a program provided by my University that does screen and voice capture, and I upload that as well - it is essentially free for me to do so in terms of my workload, and it shows up on Blackboard as well. Students really seem to like this as they can listen and take brief notes and then go back and check the parts they want to review. Perhaps you can ask your professor if your university supports something similar?
posted by procrastination at 7:20 AM on February 1, 2013 [1 favorite]
posted by procrastination at 7:20 AM on February 1, 2013 [1 favorite]
Best answer: Forget Word. Get a good text editor - Sublime 2 (with 3 coming out soon) is my current favourite. (Unless you are already super confortable with emacs/vim, but you need to be fast, and terminal editors aren't fast until you're super conformable with all the keybindings)
Use git. Change things as the prof does, and each time commit with helpful commit messages - use the commit messages as your explanatory notes. Push this project to a github or bitbucket repo to see prettier diffs, or use built in tools. (Personally I much prefer the command line and github. The terminal git diff is okay... but something like github or even a visual diff application is much easier to see the progression of changes.) And when the professor goes into theory mode, just type these notes in a giant comment block. Or a text file in the same project (using markdown if you need formatting; github will even pretty this up for you).
As a bonus, this is so much closer to what happens in the real day-to-day world than academia.
posted by cgg at 7:49 AM on February 1, 2013
Use git. Change things as the prof does, and each time commit with helpful commit messages - use the commit messages as your explanatory notes. Push this project to a github or bitbucket repo to see prettier diffs, or use built in tools. (Personally I much prefer the command line and github. The terminal git diff is okay... but something like github or even a visual diff application is much easier to see the progression of changes.) And when the professor goes into theory mode, just type these notes in a giant comment block. Or a text file in the same project (using markdown if you need formatting; github will even pretty this up for you).
As a bonus, this is so much closer to what happens in the real day-to-day world than academia.
posted by cgg at 7:49 AM on February 1, 2013
I would just start with the code in whatever text editor you use to write code with, and write your notes as comments. For example, if a line of code gets changed, comment out the original line and add the new changed line, possibly with an additional comment about why the change was made. If you have questions or unclear things, write them as comments in the appropriate part of the code. Multiple copies of the files would be more annoying to diff and whatnot in my opinion, having everything in a single file will look uglier but would make it easier to keep track of everything.
posted by burnmp3s at 8:29 AM on February 1, 2013 [1 favorite]
posted by burnmp3s at 8:29 AM on February 1, 2013 [1 favorite]
In school, I was in group c, so I can't help directly, but I will say how I take notes of what I do at work now.
I have one big text file that I edit with Notepad++ (a great free windows text editor.) I keep it in outline form like this:
1/28/13
----Project1
-------Found bug in Foo(). It was caused by using == instead of .equals().
------------Fixed and committed.
-------Added initial sort to acccounts table.
-------Etc.
----Project2
-------Acquired laptop 1.
The code is kept in various version control systems (varies by project, annoyingly) and I commit everything with a comment and (obviously) a timestamp. I almost never have to go back to look at old code though -- if I need to remember what I did with that bug in Foo, I just hit Ctrl+F in my text file and search for "Foo()" or "equals" or whatever, or I can browse by date and project.
That's kind of a long way to say that you might think about capturing important details (like why and how the teacher is changing one part of the code) rather than capturing the whole state of the code before and after.
posted by callmejay at 8:39 AM on February 1, 2013
I have one big text file that I edit with Notepad++ (a great free windows text editor.) I keep it in outline form like this:
1/28/13
----Project1
-------Found bug in Foo(). It was caused by using == instead of .equals().
------------Fixed and committed.
-------Added initial sort to acccounts table.
-------Etc.
----Project2
-------Acquired laptop 1.
The code is kept in various version control systems (varies by project, annoyingly) and I commit everything with a comment and (obviously) a timestamp. I almost never have to go back to look at old code though -- if I need to remember what I did with that bug in Foo, I just hit Ctrl+F in my text file and search for "Foo()" or "equals" or whatever, or I can browse by date and project.
That's kind of a long way to say that you might think about capturing important details (like why and how the teacher is changing one part of the code) rather than capturing the whole state of the code before and after.
posted by callmejay at 8:39 AM on February 1, 2013
Best answer: Let me add, I actually do some "thinking out loud" in my notes that could be useful for recreating that sudden blast of understanding. E.g. "Confused about session variables. Looked at http://spring493.deliciousrobots.com/page/session. Trying Step 1. It worked!" Or "Trying http://www.128bitstudios.com/2011/11/21/authentication-with-sinatra/. Hmm, the foo isn't working right. Modifying the ID variable. Nope, that didn't work, reverted. Oh, I needed to set a primary key on the Foos table. Done, and it works."
posted by callmejay at 8:46 AM on February 1, 2013
posted by callmejay at 8:46 AM on February 1, 2013
Wow. Seriously??
I got through an undergraduate and master's degree in computer science taking notes with a pen, on paper. There's tons of code in my notes, although the further I got in my CS classes the less code shows up, replaced by math. I replicated the debugging process of professors by crossing things out or correcting them, sometimes numbering them to show what order changes were made. I think this is the kind of thing that's still a lot easier to do with a pen than a keyboard or even a stylus.
posted by town of cats at 9:10 AM on February 1, 2013 [4 favorites]
I got through an undergraduate and master's degree in computer science taking notes with a pen, on paper. There's tons of code in my notes, although the further I got in my CS classes the less code shows up, replaced by math. I replicated the debugging process of professors by crossing things out or correcting them, sometimes numbering them to show what order changes were made. I think this is the kind of thing that's still a lot easier to do with a pen than a keyboard or even a stylus.
posted by town of cats at 9:10 AM on February 1, 2013 [4 favorites]
Maybe you need to think about why you're trying to keep track of code at all. There shouldn't be any rote memorization of code necessary, debugging is about the thought process and concepts. Once you switch languages or use a different library, most of the code that you wrote down becomes meaningless.
posted by meowzilla at 9:04 PM on February 1, 2013
posted by meowzilla at 9:04 PM on February 1, 2013
Best answer: I used pen and paper, and so did the majority of my classmates. But, then again, I don't try to transcribe the lecture. I focus on understanding the material as it's presented, and use my notebook to write down important results, or summaries of the professor's points, or questions I have to ask later.
- sometimes the professor gives us deliberately buggy code and asks us to talk through its issues - what's the best for replicating the debugging process in my notes?
(estlin)
It's awesome that your professor does this! If he cares this much about helping you write good code, can you ask him for the source files? Then, since his examples will usually be chosen to demonstrate common classes of bugs, you can use your notebook just to summarize the underlying principles he's demonstrating.
- sometimes we get many many slight modifications of the same basic program
(estlin)
I would save all the files in a version control system (I like git). You can use the commit messages to summarize what changed between files, which will also be a good exercise in understanding the changes. When you need to study them, most version control systems have a way to display the commit log with each patch set. (E.g., git log -p)
- sometimes there's stuff I don't fully get, or stuff I know I'll want to refer to in the future - how to keep track of these?
(estlin)
There was a typophile discussion a few years ago where people started designing ligatures for common internet abbreviations, including WTF. I draw that in the margin whenever I have a question, so I can glance through and out those lines quickly when I'm talking to the professor after class or during office hours.
posted by d. z. wang at 10:53 PM on February 1, 2013
- sometimes the professor gives us deliberately buggy code and asks us to talk through its issues - what's the best for replicating the debugging process in my notes?
(estlin)
It's awesome that your professor does this! If he cares this much about helping you write good code, can you ask him for the source files? Then, since his examples will usually be chosen to demonstrate common classes of bugs, you can use your notebook just to summarize the underlying principles he's demonstrating.
- sometimes we get many many slight modifications of the same basic program
(estlin)
I would save all the files in a version control system (I like git). You can use the commit messages to summarize what changed between files, which will also be a good exercise in understanding the changes. When you need to study them, most version control systems have a way to display the commit log with each patch set. (E.g., git log -p)
- sometimes there's stuff I don't fully get, or stuff I know I'll want to refer to in the future - how to keep track of these?
(estlin)
There was a typophile discussion a few years ago where people started designing ligatures for common internet abbreviations, including WTF. I draw that in the margin whenever I have a question, so I can glance through and out those lines quickly when I'm talking to the professor after class or during office hours.
posted by d. z. wang at 10:53 PM on February 1, 2013
Response by poster: Thank you, guys!
The idea of writing on the Powerpoints is really great - my professor currently doesn't upload them until after class, but I'll email to see whether he'd consider doing this.
We're learning how to use git in this class, so I'll transfer over to making notes with every commit, as cgg and d. z. wang suggested. Still don't exactly get it right now (it's only week 1 in this course, I swear!) but seems like it'd be a great habit to develop.
posted by estlin at 12:26 PM on February 2, 2013
The idea of writing on the Powerpoints is really great - my professor currently doesn't upload them until after class, but I'll email to see whether he'd consider doing this.
We're learning how to use git in this class, so I'll transfer over to making notes with every commit, as cgg and d. z. wang suggested. Still don't exactly get it right now (it's only week 1 in this course, I swear!) but seems like it'd be a great habit to develop.
posted by estlin at 12:26 PM on February 2, 2013
This thread is closed to new comments.
posted by empath at 12:41 AM on February 1, 2013 [1 favorite]