Hacker News Reader

Comment by larrik | Hacker News Reader

I think he's right.

In college, my CS 2 class was taught by a professor very different than the rest of the teachers there. He wanted all of your programming assignments on paper[1]. Then, you'd get it back with every possible bug marked in your program, and he very rarely missed any[2].

That was the first time in college I thought "I really need to learn how to do that!"

I went to a state school, so maybe all you guys with your degrees from fancy schools wouldn't be that impressed, but the difference between this professor and the rest there was gigantic. (He retired that year in a round of state-wide budget cuts, so that's the last class I had him.)

[1] A lot of the other teachers wanted you to hand in binaries so they can see it run. Sometimes with the code, sometimes not.

[2] I actually don't know of any case where he did, but I'm not saying "never."

View on HN

One thing I picked up (luckily) early on was that when you are learning something the fastest way to actually learn it was try to help other people learn the same thing. For programming this meant helping out on assignments in the labs, reviewing code etc. Very quickly you find yourself seeing a wide variety of bad practices and can recognize common mistakes and good practices. As a bonus you have to actually know the answers to the questions, but it is ok because if you don't know at the start you will soon enough.

tl;dr Pretending to be an expert until you actually are seems to be one of the fastest way to learn something.

this is very true. at my current company the last person who worked with the huge part of the code i write left about a month after i started. this left me constantly scrambling to figure out how to fix bugs that would come up in parts of the code i never even knew existed. I was managing ok but when we hired new developers, me having to teach them the little bit i knew caused me to understand the code way better than i had before.

I've decided my new method of training employees will have the most recently hired employee train the new hire.

> I actually don't know of any case where he did, but I'm not saying "never."

If he missed it, chances are, pretty much any student would have as well.

I agree as well. I've noticed that in ALL problems, once I establish a solid consistent language around the feature I'm building, the programming part is easy. This is true even on complex problems. Its very rare to have a problem I can talk about in detail that is not easily solvable.

I've also noticed that peers struggling with implementing solutions usually have an inconsistent language.

At Georgia Tech up until 2000 or so.

In the class it was often referred to as psudocode, but unlike psudocode in examples in random books/specs, it had a real syntax and you had to put everything you would in a real language or you'd get points off.

It was a great way to learn programming (and teach it too).

*(To disambiguate for the left cost people, GT isn't like ITT, it's of quality closer to Caltech, but much cheaper. Best salary for the tuition school in the nation apparently today)

As in, you didn't get to execute code on a computer at all?? That seems kinda odd--I think a large part of the pleasure of programming, for most people, is seeing your code actually do something. I think Logo was captivating because made this aspect especially prominent.

Yup. The point was to make people not randomly throw guesses at the compiler like the monkies flinging poo experience many people have, but instead you had to learn how it worked, and think the right way to write the right thing.

First job out of school was Andersen Consulting. Went to their programming boot camp which was two or three weeks of 14-hour days learning their methodology and (sigh) COBOL. One of the final assignments was to write the code for a particular set of requirements. Then desk check it (i.e. on paper) until you were certain it was correct. Then you saved it and submitted the file. You got one chance, it had to compile cleanly and pass their suite of tests.

Most people passed; it was not a "gotcha" problem, you just had to be able to read carefully and pay attention to detail. Andersen hired a lot of liberal arts majors who had done a lot of writing, I was one of only a few in that group who had done a C.S. curriculum.

Do you mean handwritten, or just a printed hardcopy? If it was handwritten, cue loading up my handwriting as a font and typing it anyway. ;)

A couple of my programming instructors use a build system that compiles your code with three different compilers, and runs it with various tests and diffs the output with a master copy (or sometimes stress-testing and tracking memory/time/probe counts). One of them also ran valgrind on submissions. So you'd get your "accuracy score" on the same day or so as the programs were due, then the teacher/TAs would grade the source and dock points for bugs not found in the test, supreme ugliness, etc.

I transferred to an under funded state school from a well funded community college. The CC has computer labs that CS classes were taught in. The state school taught CS with chalk boards. I learned much more with chalk boards.

When I first started university, I didn't realise how important pen and paper is. In my course, we use pen and paper more than we do computers.

From what I've heard, professors in prestigious schools aren't any better at teaching. They're hired for their prestige and research ability.

All true facts unfortunately. To get better teachers you have to attend a "teaching" college/university. This name is detrimental, as most students would probably be happier at such a place. The "research" university really isn't for everyone but they get the most prestige and people think, oh I should go there learn from the "brightest mind in the field".

The value of Stanford, MIT, CMU, etc. isn't that the professors are so good at teaching; it's that they are smart student aggregators. Nothing motivates you like not being the smart one anymore.

That might be true of some people. For someone coming from a small town where everyone told him that he would go on to do amazing, wonderful things, it can be very depressing for him to learn that he is nothing special.

That's more of a feature than a bug.

The opposite can be true too, I expected to get tanked at CMU and did pretty well (3.65 gpa, senior thesis, going to Facebook). If I'd gone to Ohio State like the majority of my peers from High School (Hilliard Darby High School has sent a whopping two people to top tier engineering schools (CMU and MIT) and none to Harvard) and even gotten a 4.0, I never would have believed I was more than a "talented state school kid."

At the end of the day, it's on you to put yourself in the most challenging situation you can possibly survive so that you can learn the most. Sheltering one's fragile ego never did much for anyone in the long run.

It certainly motivated me.

(former small town kid, went to Carnegie Mellon and realized I wasn't "the smart one" any more)

More accurately, their grant-winning ability, which is a function of prestige etc sure, but it's not why they're hired.

Generally true, although the Engineering department at my university (Waterloo) had a focus on making sure the teachers met a high "you must be this good at teaching bar" so the professors I had were routinely good.

Stanford's CS department hires lecturers (not professors) to teach many undergraduate classes, especially the introductory ones. Lecturers aren't expected to do research, and are hired based on their teaching ability. The ones I had were all incredible teachers.

Reply on news.ycombinator.com