In breaking down research of larger topics, I've found that it's been useful (for me) to place a higher emphasis on reading than swinging wildly at application. I'm sure anyone interested in Computer Science understands the sometimes overwhelming pressure to create and be 'deliverable', so much so that some discard reading altogether. However, I've found that by pacing myself and spending "loose time" reading, I'm further solidifying my understanding and setting myself up for success when it comes time to begin implementation.
Another I have chose to do this is I have a bad habit of picking up a lot of books when I'm in "The zone". I remember spending time in professors' offices at awe at the large collection of books and wondering how many they had read cover to cover, how many were gifts, how many are only reference, and etc. I want to do my best to make sure that any book on my shelf I've at least read through a couple of chapters in. It can be easy when you're concerned with output to be a bit on the impatient side with books, but the fact of the matter is that you're overlooking the opportunity to gain a better, passive understanding of the material at hand.
My present example would be my study of MP3 files. Amazing stuff really. A form of compression based human psychoacoustics. However, I wouldn't have been able to reap all the fascinating information I've learned so far if I hadn't spent the time throughout reading about it. Instead I'd just be staring down the frame header documentation, wondering what each component meant, and desperately googling for every answer. I say that, because that's where I was. Staring at each individual bit, unsure of what many of them were for... but the important part is that I encountered them casually in my reading, and coming back, the whole structure has come together for me. Now it's just a matter of doing more reading into encoding and decoding, and how I can go about that.
My big idea is to spend most of the week --when my dedicated programming time is sparse-- to reading, and then use part of my weekend block to execute a small, perhaps unrelated bit of programming. For example tomorrow I'll either be looking at a 6502 assembly application or coding through a neural network in C++. I suppose it's whatever I feel like!
I'll be sure to post more about what I've learned, I just thought this entry may be useful for those who want to learn but don't have a lot of consistent time on their hands! Let me know your study strategies as well.
Another I have chose to do this is I have a bad habit of picking up a lot of books when I'm in "The zone". I remember spending time in professors' offices at awe at the large collection of books and wondering how many they had read cover to cover, how many were gifts, how many are only reference, and etc. I want to do my best to make sure that any book on my shelf I've at least read through a couple of chapters in. It can be easy when you're concerned with output to be a bit on the impatient side with books, but the fact of the matter is that you're overlooking the opportunity to gain a better, passive understanding of the material at hand.
My present example would be my study of MP3 files. Amazing stuff really. A form of compression based human psychoacoustics. However, I wouldn't have been able to reap all the fascinating information I've learned so far if I hadn't spent the time throughout reading about it. Instead I'd just be staring down the frame header documentation, wondering what each component meant, and desperately googling for every answer. I say that, because that's where I was. Staring at each individual bit, unsure of what many of them were for... but the important part is that I encountered them casually in my reading, and coming back, the whole structure has come together for me. Now it's just a matter of doing more reading into encoding and decoding, and how I can go about that.
My big idea is to spend most of the week --when my dedicated programming time is sparse-- to reading, and then use part of my weekend block to execute a small, perhaps unrelated bit of programming. For example tomorrow I'll either be looking at a 6502 assembly application or coding through a neural network in C++. I suppose it's whatever I feel like!
I'll be sure to post more about what I've learned, I just thought this entry may be useful for those who want to learn but don't have a lot of consistent time on their hands! Let me know your study strategies as well.
