Sunday, April 09, 2006

Some random links...

Some random links. I found this interesting graphic the other day. Made me laugh out loud. I can really relate to it – for sometimes I explain something and think “it is crystal clear now”, but later given a follow up question on the same topic I can see my explanation missed the mark by a mile. You can see on that page how the student could really have come to the conclusion they did – without proper understanding of the symbols and what the notation really meant.

Then there was this Dave Barry page. His humor (along with Scott Adams – his blog is simply awesome. Required reading with coffee in the morning) resonates with me. His point number 8 reminds me of this character from “The Office”. I like how Dave Barry mixes “real” (#6) with “funny” (#1). Although, #1 is undoubtedly true as well.

Lastly, there was this page. At first I thought it was tongue in cheek – but apparently it was “real”. I guess if that list is “true and accurate” – things have really changed. Point number one about doing development on a really fast computer. Ok – I can buy that (I want the fastest one I can get my hands on for selfish reasons) – but not for the reason given. The author seems to be saying “don’t think in advance about how the code will work – just type something in and run it and see how it behaves”. That is just so wrong. Point number 4 – “Don’t learn APIs too well”. That is the one that had me convinced I was looking at an Aprils fools post or a tongue in cheek sarcastic article. But no – the author was serious. Don’t learn the APIs well, hmm. Interesting. Worst one of all – point 9 – Don’t ask people for advice. Oh no, you shouldn’t do that – you might learn from their mistakes or something disastrous like that. That would be really bad. Unfortunately these points were all mixed with some acceptable advice.


Blogger jimk said....

I stumbled upon the limit example also and thought is was rather poiniant.

For me the rule about not asking people for help is different. I use the 20 minute rule. If I can't find the answer, or reasonable progress towars the answer, in 20 minutes then I ask someone else. It is instructional to do a search, read a manual, etc. There is a lot of value in looking for the information yourself. On the other hand, flailing around for hours isn't productive. Yes, asking other people for help or to critisize your work is fruitful and enlightening.

Sun Apr 09, 11:14:00 AM EDT  

Blogger Niall said....

why would you want a rock star programmer anyway? surely you want rock star, well rock stars really, and programmers to be the guys who turn ideas into things that make something work better, faster, more reliably or easier. Mind you some of the code I've seen does rather suggest excessive stimulants, late night and noise, all good things providing you don't want to concentrate.

Sun Apr 09, 01:58:00 PM EDT  

Blogger Roderick said....

The last list may have been more of a writing issue. I'd probably rephrase #4 as "Don't memorize APIs in fine-grain detail." It's more important to understand the underlying concepts of what the API can do and how to best leverage it. Leave memorizing things like the order of arguments to the documentation or IDE.
For example with Oracle, I use the Reference manual or the describe command if I need a list of columns in a V$ view. I just have to be aware that Version N of Oracle may now have a V$ view that has info I need (or remember to query V$FIXED_TABLE when in doubt). Okay, maybe I'd rewrite that whole thing as "Memory of pointers to information is usually more compact than the memory needed to remember the information itself." Undestanding concepts would be a separate piece of advice.
#9 is more like "Don't ask questions if you can find the answer yourself in 10 seconds." The author misses that (to me at least) asking a discussion question is almost equivalent to getting advice. So the paragraph conflicts with the tip. In general, I imagine this article would get a low score in the essay portion of the SAT.
I'm not 50 yet, so I can't comment on Dave Barry's list. I still haven't learned to remove the fortune from the fortune cookie first. I'm too greedy about losing crumbs if you break them open by hand.

Sun Apr 09, 04:05:00 PM EDT  

Blogger Moans Nogood said....

Dave Berry rocks. I read his travel book(s) 10 years ago or so, and I still think highly of his evaluation of certain European nations.

He's not too PC either. Very cool dude. His books are highly recommended.

Mon Apr 10, 05:23:00 AM EDT  

Blogger Joel Garry said....

The author seems to be saying “don’t think in advance about how the code will work – just type something in and run it and see how it behaves”. That is just so wrong.
That is the essence of RAD/extreme/prototyping paradigms. It isn't quite so wrong if it is set up to simply hide proper design/normalization techniques from the end-user. More often the sad truth is it is done just like all the other bad design you've seen, throw all attributes into one object or whatever.

The really sad thing is that most of the time it is good enough, where "good enough" is for the PHB.

The guy who discovered Dave Barry.

Mon Apr 10, 10:04:00 AM EDT  

Anonymous Patty C. said....

The Dave Barry page was blocked from my view due to it being part of 'gross and tasteless jokes'. Now I am really curious.

Mon Apr 10, 01:38:00 PM EDT  

Blogger Doug said....

While funny, this Dave Barry list is not quite Dave Barry and not quite complete.

Go to and look for the text "16 things" on that page for the explanation.

For the original, either get Dave's book "Dave Barry turns 50" or search the 'net for "25 Things I Have Learned in 50 Years". His original has a brilliant insight about advertising (and does not include the one about laxatives).

Fri Apr 14, 02:08:00 PM EDT  


<< Home