Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This.

At school I was consistently the one who tried the "alternate" method. By which I mean; when setting a task to the class there was always a heavy suggestion of "how it should be done" or "the tool to use". Often with a "and you also might consider if you have the time..."

My approach was always to play with that alternative (which was really thrown in for us to say "we considered it" in the report :)). And as a result always used to suffer.

Sometimes because of unfinished work (but, hey, I was exploring something difficult!), or because it was unexpected. By about 16 this was massively disheartening; I've always had a deep interest in exploring a problem rather than having it laid out on a plate, but whenever I did the school frowned on it.

A lot of kids have this problem; when I teach clubs/classes now I get them expecting to be marked to a set scheme, having to hit certain keywords to get the marks.

On the face of it, sure, standardised marking has strong advantages when class teaching. But the objectives are too rigid and do not allow for individuals who are developing an understanding, rather than following the script.

The saving grace was 6th form (aged 17/18) where my Electronics teacher convinced me to try something really ambitious and explorative (for a 17 year old newbie engineer!). Mostly it went wrong - but our team got the highest marks in the class. The comment I distinctly remember being on our report(s) was: "I have no idea how you got that second part to work, but it was brilliant!"

Guess what I did at university



>Sometimes because of unfinished work (but, hey, I was exploring something difficult!)

This reminded me of a passage from Cryptonomicon which has previously been quoted on HN:

"They gave him an intelligence test. The first question on the math part had to do with boats on a river: Port Smith is 100 miles upstream of Port Jones. The river flows at 5 miles per hour. The boat goes through water at 10 miles per hour. How long does it take to go from Port Smith to Port Jones? How long to come back?

Lawrence immediately saw that it was a trick question. You would have to be some kind of idiot to make the facile assumption that the current would add or subtract 5 miles per hour to or from the speed of the boat. Clearly, 5 miles per hour was nothing more than the average speed. The current would be faster in the middle of the river and slower at the banks. More complicated variations could be expected at bends in the river. Basically it was a question of hydrodynamics, which could be tackled using certain well-known systems of differential equations. Lawrence dove into the problem, rapidly (or so he thought) covering both sides of ten sheets of paper with calculations. Along the way, he realized that one of his assumptions, in combination with the simplified Navier-Stokes equations, had led him into an exploration of a particularly interesting family of partial differential equations. Before he knew it, he had proved a new theorem. If that didn't prove his intelligence, what would?

Then the time bell rang and the papers were collected. Lawrence managed to hang onto his scratch paper. He took it back to his dorm, typed it up, and mailed it to one of the more approachable math professors at Princeton, who promptly arranged for it to be published in a Parisian mathematics journal.

Lawrence received two free, freshly printed copies of the journal a few months later, in San Diego, California, during mail call on board a large ship called the U.S.S. Nevada. The ship had a band, and the Navy had given Lawrence the job of playing the glockenspiel in it, because their testing procedures had proven that he was not intelligent enough to do anything else."

Re-re-quoted here for convenience, though the original davidw comment with quote can be found here: http://news.ycombinator.com/item?id=1866629


A fun quote, for sure.

And of course there is a risk associated with being too clever for your own good. Which is where a good teacher comes in...

:)


This. ;)

When I'm mentoring fresh-from-school developers at work I constantly have to try to get them to think for themselves. They seem to want me to lay out the entire problem+solution and tell them (almost) exactly how I would solve it, so all that's left is for them to implement.

I try to encourage them to develop an understanding of the problem, and poke my head in for pointers/quick tips "you're doing a billing system, better have transactions for everything", rather than "You'll need these 3 tables with these 5 fields, and you'll need to surround these methods in a database level transaction"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: