Learning new material

N2IT

Just curious on how you delve into a new concept.

Something you have very little or no knowledge of?

I've been trying to learn some scripting techniques and VBA and it's coming along slowly. I was hoping to get some ideas other than my own.

Read a book - Lab some - Read some more - etc.

Mutata

When I'm learning something new - After I do the traditional Read/Lab/Refresh I try to create some scenarios that I may encounter that would force me to use whatever I had just worked with, and then defend my use of it. I've always found labs too "do-this-then-this" and tadaa it works.

Depending on what type of scripting you are learning - I always liked taking something on the PC, or in real life that I would write/manually do and try and automate it.

SteveO86

Depending on the topic, I'll start with something small like a few blog articles, or some KB articles from the vendor.

Then go something more in-depth such as book or video learning series. Then anything that I want learn further about I'll lab it.

N2IT

Mutata and Steve thanks for the follow up.

I find myself typing the code in as well. A lot of times I will create my own project like Paul mentioned and reverse engineer the code along with adding the different variable to the code to make it run properly.

Thanks for the awesome ideas!

chmod

I first read the terminology related to the topic i'm trying to understand then i watch videos for some reason is easier for me if I watch some videos(different persons, different explanations) and then I read than if i do it the other way around.

wes allen

One of the things that has been helping me learn Python is, even if I am copying existing code, I go ahead and type it all again myself. Even if it a pretty big chunk. It really helps me understand what is going on, as does going back to fix my typos. Also, adding my own comments to the code sections helps me learn as well.

paul78

When it comes to learning new programming API's, languages, or sub-systems, I find that I learn and retain best by actually picking some project to do and actually using the technology. It may be a less efficient way to learn but for me, it improves the retention greatly.

ally_uk

I will give you a example I was a avid windows user started with 3.1 so when one day at work in a new position I was told to put Debian on a Pentium 3 to build a firewall my initial reaction was "wtf is Debian? it's a form of linux? wtf is Linux?"

So then began my new journey of diving into the wonderful world of Open Source Technologies, Distributions, Terminal Windows and lot's of other stuff completely alien to me at the time.

With everything new best approach is to break everything down into baby steps i.e the way I learnt linux was like this.

* How to Install ( Disk partitioning best practices)
* How is filesystem laid out
* How to install Packages
* How to navigate the command line
* How to get help i.e man pages info
* Basic Command Line Skills i.e ls, pwd, mkdir, touch, clear, sudo etc.
* Text editor I started with Nano now I use vim
* Package management

Then you move onto more advanced stuff

* Piping commands, Alias, command redirection i.e stdin out, error
* users and permissions
* configuring services

I knew none of this before it comes with practice it's like riding a bike more you do it more stuff cements and your typing commands in the command line like a ninja. Way I do is get hands on with the technology I have a ring binder set aside which I print off documentation and work through. I also read books watch videos and use Evernote to take and sync my notes.

instant000

"I'm not much of a coder, but when I do, I use a text editor."

Hah, just kidding.

I'm not much of a coder. I'm more of "just whip up something to fix my problem." I search specifically for my problem, find something close to what I need, and then figure out whatever syntax I need to get the job done.

My basic methodology is this:
1 - Write pseudocode (in comments) for what I'm trying to do
2 - Look up syntax to do what the pseudocode asks for
3 - Run the program, get errors
4 - Write error handlers, and/or rewrite the code to eliminate the errors
5 - Repeat steps 3-4 until no more errors (or until the errors don't affect my outcome)
6 - End


Haven't done any hard coding since the college days.

The closest thing I've done to code recently was to to use an AutoIt script to automate printing several pages of a web site to a PDF. It wasn't anything special. During the course of fixing my specific issue, I realized that this was the same type of scripting that people used to automate web-based games. That is, performing certain actions in response to certain on-screen events or memory values. (Basically, I was using it as a GUI version of "Expect", if that makes any sense.) Occasionally, something unexpected happens, and you need an "error handler" to handle the exception. I used "if then else" but there could have been more elegant ways of doing it, but if it works ... no need to reinvent the wheel.

I invested a few nights into the script, but since I had many, many printings to do, the script more than paid for itself within a few hours of operation.

tbgree00

I haven't really learned anything new for a long time. It's sad how long I've stayed inside my little bubble. I will be going a different direction in a few months and this thread is a big help.

When I'm doing a new server cert or learning something in VMware I typically hit up webinars and youtubes to get a basic understanding of the new concept and then read a book or the official documentation. I'm not sure where to start if I have little to no understanding of the concepts of something completely new though.

varelg

Great topic N2IT! I think you first have to decide if you are a top-down learner (learn the concepts first and then go for the details) or you learn from bottom up (learn as much details as you can before you study concepts) and then search for literature that suits your style of learning.
I like to see discussion on the concepts first, get a grasp on them and then see them applied through code or commands or conf files.

N2IT

I think I am a bottom up learner. I've never thought of learning that way but that is very interesting you brought that up. +1 Rep

Slowhand

I suppose I'm a top-down learner, I find that I have trouble learning the details and how they fit together until I've seen the big picture. Once I do, though, I find myself being able to BURN though the details.

For me, especially when studying for a new cert, I find it important to get a feel for what I'm learning first. I like to sit down with the CBT Nuggets and watch them all the way through, taking no notes of any kind but rather just taking in the concepts and seeing what I'm in for. Then I sit down with a book and start reading and labbing, (sometimes more than once.) After that, I'll go back and re-watch the videos, particularly on topics that I find myself not grasping as well, along with some re-reads of chapters and possibly some more hands-on work with a few things.

I do the same for topics in school: I like to either read through a whole chapter first, or watch a video if I have any available, then go back through and begin working on details and start solving assigned problems. (Usually in math or science classes is where this applies.)

When it comes to writing or creative endeavors, I'll work through a similar process: brainstorm for a while, get the whole concept formed in my head. After that, it's just a matter of putting the pieces together on paper.

N2IT

@ Slow

Funny how we all learn differently but the schools, high schools and universities seem to teach one particular format.

UnixGuy

I tend to read different books by different authors (and usually end up picking a favorite book). Sometimes the learning pace is (much) slower than I thought it would be - no problem, I stick to it, and give it more time, repeat some examples, and do some more until I get it

varelg

N2IT wrote: »

I think I am a bottom up learner. I've never thought of learning that way but that is very interesting you brought that up. +1 Rep

Thank you N2IT Cognitive science at least to me is an ever- intriguing topic. Many "a-ha!" moments while reading about cognitive scientists' discoveries on how we learn, why we remember some things and forget others, how can we motivate ourselves to learn something we don't deem important...
Emotional attachment to a topic seems to be of particular importance in how successful we are at learning about that topic.

N2IT

The emotional piece has got to be right on the money. When a job or some deliverable is contigent on knowing a certain technology it never fails you pick it up, maybe not quickly but you get it. When it's for fun or just because I always seem to forget it.

Good call on the emotional piece.

onesaint

Fascinating topic N2!

When studying for the CCNA I found the CBT Nuggets to give a fantastic overview conceptually, while Odom's CCNA books were thoroughly in depth. I went top down for that exam. However, I think the material for the top down approach in programming is more difficult to find.

paul78 wrote: »

When it comes to learning new programming API's, languages, or sub-systems, I find that I learn and retain best by actually picking some project to do and actually using the technology. It may be a less efficient way to learn but for me, it improves the retention greatly.

What sort of projects do you end up doing? I'm currently looking for just that (apps to write to learn) in Python 2.7.

N2IT

I wanted to revisit this thread and see if anyone had any other insights.

paul78

I don't really have any new insight really but your original post had jogged a thought about how people get really good at something - whether its a sport, job, or their craft. I went and re-read a chapter from a book called Outliers by Malcolm Gladwell. The chapter was about the 10,000 hour rule. The premise was that to be one of the best, an individual needed to spent at least 10,000 hours on learning. As an example, the author cited Bill Joy (one of the founders of Sun Microsystems and arguably one of the main contributors to Unix) and provided an argument which I found quite interesting. It disputed the idea of innate talent but instead focused on the idea that to be one of the best, passion and continual learning/practice was paramount.

The notion is that it was mostly about continual practice and learning as the key and not so much about the approach. For me, there is a certain appeal in that theory

@onesaint - I usually just pick some random topic that happens to interest me a the time. Some that I've played around with - btree library, tcp packet parser, simple graphing for stock prices, a huffman encoder, etc...

dave330i

If it's a topic I have very little or no knowledge, then I start with training videos. They tend to be the easiest info to digest. After the videos, I go into reading material & lab.

onesaint

paul78 wrote: »

I went and re-read a chapter from a book called Outliers by Malcolm Gladwell...

@onesaint - I usually just pick some random topic that happens to interest me a the time. Some that I've played around with - btree library, tcp packet parser, simple graphing for stock prices, a huffman encoder, etc...

Thanks Paul.

Gladwell is an excellent author. Outliers, Tipping Point, & Blink were all fantastic reads. Fot a taste, here are some articles he's written. He gives a great social perspective on interesting topics. I dug the Joy reference as well.

N2IT

Thanks Dave

Paul that is very intriguing. Thanks for sharing that GEM!

Paul my wife this morning said MD's spend about that much time in residency (at least)

varelg

An article that may sheds a light on how we process language (and learn something in that process):
Imagine A Flying Pig: How Words Take Shape In The Brain : Shots - Health News : NPR

If someone read a sentence like, "the shortstop threw the ball to first base," parts of the brain dedicated to vision and movement would light up, Bergen says. "The question was, why?" he says. "They're just listening to language. Why would they be preparing to act? Why would they be thinking that they were seeing something?"
The answer that emerged from this research is that when you encounter words describing a particular action, your brain simulates the experience, Bergen says.

In the process of understanding, it seems also important to think in metaphors:

Sathian has been studying an area of the brain that responds to the texture of an object — whether it feels smooth or rough. And he wondered whether the same area would respond when we use textures like smooth or rough as metaphors.So he had people lie in an fMRI scanner while they listened to metaphors like, "he had a rough day," as well as similar sentences with no metaphor like, "he had a bad day."
The results suggest that, at least to the brain, a rough day has something in common with a sheet of sandpaper, Sathian says. "When listening to these sentences containing textural metaphors, we found activity in the part of the brain that's involved when we feel surfaces," he says

varelg

So for example, you would try to learn network traffic and you arrive at the term "packet". Push comes to shove, you actually MAKE a paper packet and draw on it all its elements, or better yet- make a box for each element of a data packet and stick them together at one room (packet assembly), take them to the other room and dissasemble them in the order described in the book you are studying... Lego squares maybe?

gorebrush

Slowhand wrote: »

I suppose I'm a top-down learner, I find that I have trouble learning the details and how they fit together until I've seen the big picture. Once I do, though, I find myself being able to BURN though the details.

For me, especially when studying for a new cert, I find it important to get a feel for what I'm learning first. I like to sit down with the CBT Nuggets and watch them all the way through, taking no notes of any kind but rather just taking in the concepts and seeing what I'm in for. Then I sit down with a book and start reading and labbing, (sometimes more than once.) After that, I'll go back and re-watch the videos, particularly on topics that I find myself not grasping as well, along with some re-reads of chapters and possibly some more hands-on work with a few things.

I do the same for topics in school: I like to either read through a whole chapter first, or watch a video if I have any available, then go back through and begin working on details and start solving assigned problems. (Usually in math or science classes is where this applies.)

When it comes to writing or creative endeavors, I'll work through a similar process: brainstorm for a while, get the whole concept formed in my head. After that, it's just a matter of putting the pieces together on paper.

+1 - pretty much identical to how I approach certs.