Amusing Algorithms
Mickwest
Many years ago, In a pub in Manchester, England, I was having a pint with
a friend. We were discussing programming something and he said something
like "Phil is crap, he can't even wrap a word counter at 256", I snorted
and said "The stupid git! It's obvious, all you do is AND it with 256" I
then paused for a second, then hurridly said "er, I mean 255".
We both laughed a little, then totally cracked up with laughter, nearly
falling off our bar stools and spilling our drinks.
We were not just laughing because what I said was amusing, but because we
both suddenly realised the strangeness of sitting in a pub, laughing over
something that NOBODY in the pub would understand, or even if they did
understand it, find it funny. We were sharing an in-joke that was
impossible to explain.
Someone on this newsgroup (rec.games.programming) mooted the relevance of
amusingly bad algorithms, saying they were "off-topic". Well, I feel that
the ability to laugh at an algorithm is something that sets good games
programmers apart from the bad ones.
To be able to laugh at an algorithm, you really need to get inside the art
of programming to such an extent that it becomes a part of you. If you can
laugh at an algorith, then it shows you REALLY understand it. If you don't
find a really bad algorithm amusing, then you do not really understand it.
For all those people out there striving to become good programmers: When
you laugh at an algorithm, you are nearly there.
Mick
Pete Rowley
[in-joke story snipped]
> Someone on this newsgroup (rec.games.programming) mooted the relevance of
> amusingly bad algorithms, saying they were "off-topic". Well, I feel that
> the ability to laugh at an algorithm is something that sets good games
> programmers apart from the bad ones.
>
Yeah, that was me, and it's still off topic. As for be able to
laugh at algorithms, I think that's what sets really sad people
apart.
> To be able to laugh at an algorithm, you really need to get inside the art
> of programming to such an extent that it becomes a part of you. If you can
> laugh at an algorith, then it shows you REALLY understand it. If you don't
> find a really bad algorithm amusing, then you do not really understand it.
>
First off, if you believe that programming is an art, then I don't
think you understand the nature of *programming*, let alone algorithms.
BTW, I've spent my entire life avoiding people who laugh at algorithms,
that pretend they know loads of really complex complexity type complex
stuff. They are usually full of BS, and find it difficult to operate
in the real world because they can't discuss anything other than
computers.
> For all those people out there striving to become good programmers: When
> you laugh at an algorithm, you are nearly there.
For all those people out there striving to become good programmers: When
you can design something so that it is maintainable, well-structured,
understood by others and coded likewise - then you've still your whole
life left to get better.
--
________________________
| | ()()_________________________
| Pete Rowley | |______ ____ _ ___ _ _ | GIG: 11/4/95
| Edinburgh | | _ \ | || || __ | / _/| |/ / The Venue, Edin.
| pe...@adder.demon.co.uk | | |_| || || |||__||| |_ | < supp. Freaker,
|________________________| |____/ |_||_||_||_| \__\|_|\_\ Pierced
Mickwest
>Yeah, that was me, and it's still off topic. As for be able to
>laugh at algorithms, I think that's what sets really sad people
>apart.
From my perspective, it is on-topic, if a little esoteric. As part of my
job at a small but growing computer games devlopment company, I have to
evaluate prospective programmers. Before this role was thrust upon me I
never really thought very much about what makes a good programmer or a bad
programmer, or how you can tell them apart in a quick and easy manner.
So, I've been thinking about what makes the good games programmers that I
know good? What do they have in common? What do the bad programmers have
missing? Can we winnow out the chaff?
And based on personal experience, I came up with the amusing idea that
people who laugh at certain algorithms understand those algorithms more
than people who do not laugh at them. I feel that their amusement implies
a deep understanding of the underlying programming concepts behind the
algorithm.
Back to recruiting games programmers. Before hitting on the "Amusing
Algorithms" idea, I had devised a test of 20 questions and problems to
give to prospective programmers. This test has worked very well, I have
got two excellent programmers and discarded scores of others who did not
quite reach the mark.
I wonder if perhaps now I should incorporate a test of Amusing Algorithm
Appreciation. Several ideas come to mind:
Give them five implementations of a line draw routine and ask them to
pick the funniest and explain what's so funny about it.
Give them a boring shuffling algorithm and ask them to make it more
amusing.
Give them five different algorithms and ask them to pick the only one
that is not funny.
Ask them to relate the funniest thing they ever did programming.
Ask them what the most amusing 80386 instruction is.
>First off, if you believe that programming is an art, then I don't
>think you understand the nature of *programming*, let alone algorithms.
I'm sorry, perhaps I should have said "the craft of programming" which was
the sense I was using "art" in. Programming is not usually an art form,
but it obviously is a craft as defined in the Oxford English dictionary
thus : "An art, trade or profession requiring special skill or knowledge".
>BTW, I've spent my entire life avoiding people who laugh at algorithms,
>that pretend they know loads of really complex complexity type complex
>stuff.
Surely you exaggerate? Surely not everyone who laughs at algorithms is
doing it to pretend they know more than they do. Surely there are a few
people who simply deal with algorithms on such a regular basis that find a
few incongrously bad ones amusing.
Hmm, by saying "...people who laugh at algorithms, that pretend they know
loads of really complex complexity ...", were you actually implying that
laughing at algorithms is actually ALREADY seen as a sign of a good
programmer, to such an extent that people will pretend to laugh at
algorithms which they do not find at all amusing, just to appear clever?
It seems I have missed the boat if that is the case, if what you say is
real then my brave new theory is already common knowledge. Darn!
> They are usually full of BS, and find it difficult to operate
>in the real world because they can't discuss anything other than
>computers.
As well as only hiring good programmers, I also only hire good people. The
people I have hired can (and do) laugh at algorithms, but are also very
pleasant, fairly unencumbered people that operate very well in the real
world.
If you feel this is off topic, then feel free to ignore it. Personally I
find the whole topic fascinating and rather amusing. :)
Mick.
NewOrder Demo Group
Mickwest <mick...@aol.com> wrote:
>Pete Rowley <Pe...@adder.demon.co.uk> wrote:
>>Yeah, that was me, and it's still off topic. As for be able to
>>laugh at algorithms, I think that's what sets really sad people
>>apart.
>know good? What do they have in common? What do the bad programmers have
>missing? Can we winnow out the chaff?
>
>And based on personal experience, I came up with the amusing idea that
>people who laugh at certain algorithms understand those algorithms more
>than people who do not laugh at them. I feel that their amusement implies
>a deep understanding of the underlying programming concepts behind the
>algorithm.
I have to agree with this. Laughing at [bad] algorithms is like laughing at
physics or math jokes. Q: What do you get when you cross a grape with an
elephant? A: Grape elephant sin theta. Q: Why do programmers not know the
difference between haloween and Christmas? A: Because oct 31 is equal to
dec 25. Personally, I find those two a riot, but I have found that I can
only tell them to math and CS professors or else I get confused looks. One
has to have some math background for both jokes (although CS would qualify
for the latter).
>Back to recruiting games programmers. Before hitting on the "Amusing
>Algorithms" idea, I had devised a test of 20 questions and problems to
>give to prospective programmers. This test has worked very well, I have
>got two excellent programmers and discarded scores of others who did not
>quite reach the mark.
>
>I wonder if perhaps now I should incorporate a test of Amusing Algorithm
>Appreciation. Several ideas come to mind:
[several ideas snipped]
> Ask them what the most amusing 80386 instruction is.
Hmm...I'd say that LoadAllD is probably the most interesting. Rep lodsb
is the most useless. If HCF or DWIWNWIS existed, they certainly would
be kinda neat (although my friend Danny figured out how to blow up a monitor
by messing with the VGA registers... but it wouldn't [Halt &] Catch Fire).
I don't think I've really laughed at an instruction until I started reading
the new instructions on the 486 and Pentium. Xadd would probably be the most
interesting on the 486. And I have yet to see someone use cmpxchg8b for
anything useful...although I suppose it would be a good trivia question to
ask a potential employee as to which instruction uses the longest mnemonic.
Or a better question would be: What non-math instruction takes the longest
amount of time on the Pentium (2000+ clocks)?
[snip]
>Mick.
--TCA of NewOrder
newo...@carina.unm.edu
Scott Coleman
>Back to recruiting games programmers. Before hitting on the "Amusing
>Algorithms" idea, I had devised a test of 20 questions and problems to
>give to prospective programmers. This test has worked very well, I have
>got two excellent programmers and discarded scores of others who did not
>quite reach the mark.
Well don't just leave us dangling, what are the questions?!?!?!?!?!? ;-)
--
Scott Coleman, President ASRE (American Society of Reverse Engineers)
as...@uiuc.edu
"An Irishman is never drunk as long as he can hold onto one blade of grass and
not fall off the face of the earth."
Mickwest
>Well don't just leave us dangling, what are the questions?!?!?!?!?!? ;-)
I'd rather not upload them, as people would just pick at their obvious
failings, and any prospective programmer would get far too long to prepare
their answers.
If you want to see the test, you could apply (to Neversoft Entertainment),
though we have no programming openings until October.
Mick.
Scott Coleman
> col...@alexia.lis.uiuc.edu (Scott Coleman) wrote:
>>Well don't just leave us dangling, what are the questions?!?!?!?!?!? ;-)
>I'd rather not upload them, as people would just pick at their obvious
>failings, and any prospective programmer would get far too long to prepare
>their answers.
Fine, I'll sign an NDA. Sheesh!
>If you want to see the test, you could apply (to Neversoft Entertainment),
>though we have no programming openings until October.
Wow, you'll fly me out for an interview so I can see the test questions?
Now THAT is an amusing algorithm! ;-) ;-) ;-)
Mickwest
>Wow, you'll fly me out for an interview so I can see the test questions?
>Now THAT is an amusing algorithm! ;-) ;-) ;-)
Well, I was thinking more along the lines of: you show me your resume, I
show you my test.
Here's a sample question:
7) a) Briefly describe how the beam moves on a TV screen (ie how the
picture
is built up). Explain how this relates to displaying graphics. Explain
what
the Vertical Blank (or Vertical Retrace) and Horizontal Blank are, and
what
related interrupts could be used for.
b) Explain Double and Triple buffering.
Mick
Pete Rowley
>
> And based on personal experience, I came up with the amusing idea that
> people who laugh at certain algorithms understand those algorithms more
> than people who do not laugh at them. I feel that their amusement implies
> a deep understanding of the underlying programming concepts behind the
> algorithm.
>
There are many types of humour, some people laugh at one thing, and
some at others, the ability to laugh at an alogorithm does not imply
deeper understanding over someone who doesn't. Have you never laughed
at something and not really known why? Have you ever been with people
laughing at something and you just don't find it funny?
> Back to recruiting games programmers. Before hitting on the "Amusing
> Algorithms" idea, I had devised a test of 20 questions and problems to
> give to prospective programmers. This test has worked very well, I have
> got two excellent programmers and discarded scores of others who did not
> quite reach the mark.
>
How do you know for sure that you some of the people
who didn't reach the mark were not the best programmers you'd ever
had through the door? How do you know that the programmers you got
were even in the top ten of all those interviewed? The trouble
with selection tests is that they are difficult to set so as to
achieve the desired result, and impossible as an employer to prove that
they are indeed doing what you hope. All you've got to go on are
the people you employed as a result, you may be satisfied with them,
but you cannot be sure you wouldn't be more satisfied with the guy that
got zero.
> I wonder if perhaps now I should incorporate a test of Amusing Algorithm
> Appreciation. Several ideas come to mind:
See above about humour.
>
> >BTW, I've spent my entire life avoiding people who laugh at algorithms,
> >that pretend they know loads of really complex complexity type complex
> >stuff.
>
> Surely you exaggerate? Surely not everyone who laughs at algorithms is
> doing it to pretend they know more than they do. Surely there are a few
> people who simply deal with algorithms on such a regular basis that find a
> few incongrously bad ones amusing.
>
Well, I did yes, I've been avoiding them from about 14 years old. I
quite understand that occasionally something might crop up
that would make you laugh, I find that de-bugging others (bad) code
often brings a wry smile directed at noone in particular. What I'm
talking about is a symptom that is indicative of a type, the type that
gets by by laughing in the right places. I've seen enough of them so
that I can spot the BS at 50 paces, other clues are sentences containing
buzzwords that don't quite mix, these will increase exponentially while
you are still playing dumb.
There are plenty of them in the biz, I'm sure you've met a few at least...
> Hmm, by saying "...people who laugh at algorithms, that pretend they know
> loads of really complex complexity ...", were you actually implying that
> laughing at algorithms is actually ALREADY seen as a sign of a good
> programmer, to such an extent that people will pretend to laugh at
> algorithms which they do not find at all amusing, just to appear clever?
>
What I'm saying is that that is the way those people see it, it's
more of a cover, sleight of hand.
> It seems I have missed the boat if that is the case, if what you say is
> real then my brave new theory is already common knowledge. Darn!
>
I don't know if it's common knowledge, or if it's real knowledge to be
common. I am quite perceptive, I notice a great deal about people
even though I try to, but then I my assessment of these people may
be wrong - but I don't think so.
> > They are usually full of BS, and find it difficult to operate
> >in the real world because they can't discuss anything other than
> >computers.
>
> As well as only hiring good programmers, I also only hire good people. The
> people I have hired can (and do) laugh at algorithms, but are also very
> pleasant, fairly unencumbered people that operate very well in the real
> world.
>
Well, I'm pleased it works for you. All I would say is bear in
mind what I said before. It may be that you have struck on
something that is just right for you and your company by chance -
in that you are unwittingly also testing for other things that are
important to you. But as I said, you can't be sure you wouldn't
be over the moon with the guy who got zero.
> If you feel this is off topic, then feel free to ignore it. Personally I
> find the whole topic fascinating and rather amusing. :)
Hey, sure it's off topic - but it just got interesting :)
Drizzt Do'Urden
: col...@alexia.lis.uiuc.edu (Scott Coleman) wrote:
: Mick
That seems pretty silly to me. How long would it take someone to learn that?
Just you sitting there telling them in 2 minutes would probably be somewhat
suffecient!.. What would be more valuable for your "questionairre", would be
questions on HOW FAST they learn stuff, where they think they are in the
programming world, and how far they think they can get. I really love
programming, but I cannot say I am a pro at it.. or even an expert.. But I can
tell you what you asked in that question, and I am sure even a non-computer
person can tell you that once they have heard it one time.
-- Drizzt
Phil Jones
Here's a gag that always cracks me up. Not actually an algorithm joke,
but a computing one nonetheless:
bill_gates > god
Hmmm, maybe that joke's a bit too controversial.
--
+------------+----------------------------------------------------------+
| Phil Jones | f...@muon.demon.co.uk |
+------------+----------------------------------------------------------+
Mickwest
>Mickwest (mick...@aol.com) wrote:
>: 7) a) Briefly describe how the beam moves on a TV screen (ie how the
>: picture
>: is built up). Explain how this relates to displaying graphics. Explain
>: what
>: the Vertical Blank (or Vertical Retrace) and Horizontal Blank are, and
>: what
>: related interrupts could be used for.
>: b) Explain Double and Triple buffering.
>
>: Mick
>
>That seems pretty silly to me. How long would it take someone to learn
that?
>Just you sitting there telling them in 2 minutes would probably be
somewhat
>suffecient!.. What would be more valuable for your "questionairre",
would be
>questions on HOW FAST they learn stuff, where they think they are in the
>programming world, and how far they think they can get. I really love
>programming, but I cannot say I am a pro at it.. or even an expert.. But
I can
>tell you what you asked in that question, and I am sure even a
non-computer
>person can tell you that once they have heard it one time.
This was just one question out of 21, so it only constitutes a small part
of the test.
There is no simple "correct" answer to the above question. All the
questions are intended to give me a little bit of the big picture. I don't
simply mark a question "Right" or "Wrong". The above question can be
answered in many different ways, and with many different levels of
understanding. I look for the highest level of understanding, and
understand most relevant to games programming.
There are also three different graphics techniques that people call
triple buffering, you get vauge points for understanding more than one.
The key word is "understanding" not "knowledge".
It's very easy to pick my question apart, why don't you answer it and let
the rgp folk pick your answer apart.
Mick.
Piche Patrick
:That seems pretty silly to me. How long would it take someone to learn that?
That's exactly why the guy didn't wanted to post the whole questionnaire!
Of course a totally non-programmer could learn all the answers to all the
questions! But if you haven't seen the questions before, there are big
chances that if you know all the answers, that's because you have enough
experience in the field he's hiring people... Of course, this only question
can't tell if the guy is really a good programmer, but it tells if the guy
knows anything about intense graphics required in game programming. Just
my 0.02$...
Bye, Patrick
PS: Of course, I still beleive that to know if someone is a good programmer,
you only have to ask him about a short demo with the source code.
John Tessin
: There is no simple "correct" answer to the above question. All the
: questions are intended to give me a little bit of the big picture. I don't
: simply mark a question "Right" or "Wrong". The above question can be
: answered in many different ways, and with many different levels of
: understanding. I look for the highest level of understanding, and
: understand most relevant to games programming.
: It's very easy to pick my question apart, why don't you answer it and let
: the rgp folk pick your answer apart.
NO! NO! Not another Shuffling Thread!
* Everyone just watches as JTessin grabs his head screaming and flees
from the thread
Nuff said
Regards
--
jte...@netcom.com
CIS: 71774,1731
Mitchell Skiba
wrote:
> >Mickwest (mick...@aol.com) wrote:
> >: 7) a) Briefly describe how the beam moves on a TV screen (ie how the
> >: picture
> >: is built up). Explain how this relates to displaying graphics. Explain
> >: what
> >: the Vertical Blank (or Vertical Retrace) and Horizontal Blank are, and
> >: what
> >: related interrupts could be used for.
> >: b) Explain Double and Triple buffering.
> >
> >: Mick
> >
[snip--irrelevant other poster in between]]
> The key word is "understanding" not "knowledge".
>
> It's very easy to pick my question apart, why don't you answer it and let
> the rgp folk pick your answer apart.
>
> Mick.
skipping over the easy part of 7.a., you need to be careful in using the
interrupts associated with either of the blankings. In fact, one could
argue that, depending on the platform, it is unwise to use an interrupt
associated with the blanking. Reasons: multiple monitors; refresh faster
than code causes shearing; locked in to certain memory ops during interrupt
time.
7.b. Double buffering--a tried an true technique also called page flipping or
sometimes known as offscreen drawing.
Triple Buffering--got me
Does this demonstrate anyting about my level of programming? I gave no
really relevant programming info. I gave no code snippets, but did (at least
to me ;-) demonstrate a passing knowledge in the vocabulary.
I realize that the test is longer, and this is only one question. But I have
a hard time with 'tests' per se. Sure an interviewer needs to do something,
and a few well chosen questions can eliminate some real dogs, but I think
nothing demonstrates ability better than a piece of demo code they sent in
then explain to you. You've got to be smart enough to ask good questions
about the code and then assess their answers.
As for finding algorithms amusing, well, I really don't put too much stock
in that. In fact, I find the single most problematica area in sw development
is a fundamental lack of good engineering instruction. CSci folks learn
a great deal in school; unfortunately, I've found that most (I am being
stereotypical here, but my job is to bridge hw and sw) sw folks never learned
the fundamental engineering process: take a big problem and break it down,
iterate until it is 'just' small enough to be solved in a clear manner. What
does that mean? Don't start coding because you think you have a solution.
Actually take the time to work out a concept, flow down requirements, prepare
a preliminary design, double check requirements are still being met, now
start coding...still more stuff to do, but the point is coding doesn't come
to way down the line. That IMHO is what separates the true professionals from
the hacks (not hackers, mind you, but that is a whole different topic ;)
Cheers,
Mitchell
sk...@aerie.dgsys.com------- -------------------------------------------
Pushing the technology rope.| Disclaimer: I do speak for Aerie Ltd; |
| I'm not just a client, I'm the president. |
------------------------------------------------------------------------
William Jeremiah
: 7) a) Briefly describe how the beam moves on a TV screen (ie how the
: picture is built up)
So you would like a description of the physics that make a TV screen display
a picture? Isn't that a bit complex for a "brief" description? Or is it
as simple as saying:
"Magically the electons come out of the woodwork and hit the screen,
They start at the top left and move left to right, top to bottom
only hitting the spots that are supposed to be illuminated.
Then it starts all over again."
Doesn't seem like much of a useful description to me. Even if someone
had that the knowledge what possible use could they make of it?
If they knew why the electrons only hit the spots that are supposed
to be illuminated or if they knew why it had to be done again and again
wouldn't that be more useful. But it makes it verbose instead of breif.
Jerry
: Mick
--
GCS/E d(++) H s+: g? !p+ !au a- w+ v- C+++ U++ P+ N+++ y?
E--- W+ !M V -po+ Y !tv b+++ D++ B-- e* u+ h+ f !r n----
Mickwest
>Mickwest (mick...@aol.com) wrote:
>: 7) a) Briefly describe how the beam moves on a TV screen (ie how the
>: picture is built up)
>
>So you would like a description of the physics that make a TV screen
display
>a picture? Isn't that a bit complex for a "brief" description? Or is it
>as simple as saying:
>
>"Magically the electons come out of the woodwork and hit the screen,
>They start at the top left and move left to right, top to bottom
>only hitting the spots that are supposed to be illuminated.
>Then it starts all over again."
The question presumes a little basic knowledge, you don't have to explain
what the beam is, or where it comes from, just how it moves on the screen.
It's just a tiny little part of one question.
The real part of the question is in the application of this knowledge.
Explaining vertical and horizontal blanking, and related interrupts, and
what they are used for. (Hblanks arn't used that much on the new consoles
though). Vertical blanking has the "obvious" uses of updating the screen
without flicker, and providing timing (on a 60Hz console, not on a
variable frequecy PC to the same extent).
You get few fuzzy points for demonstrating a clear understanding of these
things (and double and triple buffering). It is only one small questions
out of a large test. The test is just one part of the whole application
process, which includes comprehensive interviews, looking at actual code
they have written, seeing how they react to our slightly strange office
environment, checking if they understand sarcasm, asking how many balls
they can juggle and finally going out for a beer and a chinwag.
Mick.
Mickwest
> Agreed, IQ tests, Rechorst (Ink Blot) test etc test very little,
>except the conformity to standard norms. So wat you end up testing is how
>much candidates lack innovation.
Indeed, so I don't give them a raw IQ test,. Instead I give them a test
with a number of vauge and open ended questions, many involving problem
solving. Every person who applies answers the problem solving questions in
a different way, giving me far more information than a simple IQ test,
which has just right or wrong answers.
I have never hired anyone who put their IQ on their resume. Any good
programmer will have a testable IQ of above 120, exactly how far above is
not important. Anyone who thinks their IQ of 160 is a valuable asest is
usually lacking in an appreciation of what useful intelligence really is.
The Rorscach ink blot test does not test "conformity to standard norms",
it's just a tool, quote:
"The Rorschach test has however, turned out to be extremely difficult to
validate objectivly, and it's success depends very much on the intuitive
grasp of the psychologist who interprets the patient's responses or
comments" - Oxford Companion to the Mind, p686.
My test is far closer to the Rorschach test than an IQ test. I don't look
at the answers and mark them right or wrong, I just use the whole thing as
a guide, providing clues as to the worth of the person. The test would be
usesless to a personell department, as they would not understand the
answers. It takes an expert programmer to spot an potentially expert
programmer who will actually be useful.
Mick.
Monika Weikel
are a qualified applicant, testing should not be a problem. If you are not,
well... isn't it best to know that before you are hired? For everyone's sake,
including yours?
Some people "choke" on tests and this is a valid reason against them. However,
if you explain that you are nervous and ask for extra time or privacy, they
should be understanding. If you are that nervous and they are cruel enough
not to let you work in private, do you really want to work there?
I've worked at companies that do and do not require testing, and the companies
that require testing are more pleasant places, because most of the phonies are
weeded out.
Monika Weikel
designed using the curses library and needed to include four boxes.
He made available to us a directory containing "good" examples from previous
classes.
Well, I ignored this directory and set about studying the curses man pages. My
program ran into a problem extracting data while in curses mode, so I peeked at
the examples to see how they got around this. What I saw had me ROTFL. These
"good" examples had only two curses calls. One to enter curses mode, then one
to exit. The truly funny thing was that each and every example had a function
called box(1x,1y,2x,2y) which drew a shoddy unprofessional looking box using
the = and + keys. There is a function with an identical call in the curses
library which yields much nicer results!
I don't know which is funnier, the shoddy wasted effort, or the fact my
professor (who is a very smart man) put his stamp of approval on it!
*sigh* I guess you had to be there...
John Tessin
: I have never hired anyone who put their IQ on their resume. Any good
Are you serious? People actually put their IQ on a resume? Good Lord!
How do they get their EXPANDED cerebriums through normal doorways.
Paul Johnston
Phil Jones <f...@muon.demon.co.uk> wrote:
>
>Here's a gag that always cracks me up. Not actually an algorithm joke,
>but a computing one nonetheless:
>
>bill_gates > god
>
>Hmmm, maybe that joke's a bit too controversial.
>
That's interesting, I was thinking about those roman numerals on the pope's
hat and...
int sum=0;
char *ptr,name[]="BILLGATES";
for (ptr=name; *ptr; ptr++)
sum+=*ptr;
printf("BILLGATES+3 = %d",sum+3);
the three is added for Bill Gates the 3rd
so does that mean Bill Gates == antichrist?!?!
how's that for controversial?
Junaid A. Walker
: In article <3tc3ns$c...@newsbf02.news.aol.com>, mick...@aol.com (Mickwest)
: wrote:
: > The key word is "understanding" not "knowledge".
: >
: > It's very easy to pick my question apart, why don't you answer it and let
: > the rgp folk pick your answer apart.
: >
: > Mick.
: I realize that the test is longer, and this is only one question. But I have
: a hard time with 'tests' per se. Sure an interviewer needs to do something,
Agreed, IQ tests, Rechorst (Ink Blot) test etc test very little,
except the conformity to standard norms. So wat you end up testing is how
much candidates lack innovation.
As a uni tutor, i find that the most promising students are those
that have that special glow in their eye, at times find it difficult to
stop talking when a flash of briliance overcomes them, are not afraid
to explore (sometimes bezarre) alternative solutions, and show a general
depth of understanding that you can only get by reading K&R , Stroustrup,
or a few of the other programming gurus. You can smell these students a
mile off...and usually there is only one in a class.
: and a few well chosen questions can eliminate some real dogs, but I think
: nothing demonstrates ability better than a piece of demo code they sent in
: then explain to you. You've got to be smart enough to ask good questions
: about the code and then assess their answers.
Precisely why unis only test students on technical issues. The others-
communication, sociability, innovation, problem solving etc are very
difficult to examine in a lecture/exam/interview enviornment. To a small
extent they are explored in projects and tutorial work.
: As for finding algorithms amusing, well, I really don't put too much stock
: in that. In fact, I find the single most problematica area in sw development
: is a fundamental lack of good engineering instruction. CSci folks learn
: a great deal in school; unfortunately, I've found that most (I am being
Too right - many honors grads dont know how to bit twiddle
(what the binary stuff in first year, why would you ever use that).
In electrical engineering, we get a several semester subjects covering
managment+design and the design process. This can only attempt to cover
the major issues in a superficial way, without applying them in any
concrete form.
: stereotypical here, but my job is to bridge hw and sw) sw folks never learned
: the fundamental engineering process: take a big problem and break it down,
: iterate until it is 'just' small enough to be solved in a clear manner. What
Oh dear. Vertical think is particulary myopic problem solution
technique. Read Edward de'Burno. You can get any number of vertical thinkers
, and yes they will gurantee you a solution, but very often it is far
from optimal. Unfortunately optimal is a key component in competing in the
market place, especially if you want to maximize profits.
: does that mean? Don't start coding because you think you have a solution.
: Actually take the time to work out a concept, flow down requirements, prepare
: a preliminary design, double check requirements are still being met, now
: start coding...still more stuff to do, but the point is coding doesn't come
I find the more you spend on design, the better code. Naturally you
can go overboard.
: to way down the line. That IMHO is what separates the true professionals from
: the hacks (not hackers, mind you, but that is a whole different topic ;)
Yes and no. Dont fear hackers (man did i flip a few bits in my
youth). The trick is to choose a hacker that has outgrown the hacker ethic
of "quick and dirty". The more perceptive (ie thru experience and different
perspectives) a person is, the better they can size up competing solutions
and via whatever heuristics they have in their tool belt, choose the best.
Maybe we will never know how a good designer designs. Maybe we dont even
properly understand the implementation process either, but that never
stoped humans solving problems.
I can only suggest to look, listen, and never judge. Feel your
way thru a persons mind, and monitor continuously. Correct where possible,
even educate, and boot out of camp regularly!
Junaid
: Cheers,
Rabies
> Mickwest (mick...@aol.com) wrote:
> : col...@alexia.lis.uiuc.edu (Scott Coleman) wrote:
>
> : Here's a sample question:
>
> : picture
> : what
> : the Vertical Blank (or Vertical Retrace) and Horizontal Blank are, and
> : what
> : related interrupts could be used for.
> : b) Explain Double and Triple buffering.
>
> : Mick
>
> suffecient!.. What would be more valuable for your "questionairre", would be
I'm afraid Drizzzt, err Drizzt Du'Orden? (my GOD! how do you pronounce that?)
is right. I could have answered that question long before I ever touched
a compiler on the PC. I've been a graphics artist for games, so that's
why I could answer that correctly (well, part B might not be as
accurate.) Anyways, that test question is supposed to weed out
programmers right? Shouldn't I as just an artist have been unable to
answer it?
-RB
Mickwest
> Anyways, that test question is supposed to weed out
>programmers right? Shouldn't I as just an artist have been unable to
>answer it?
Why should you be unable to answer it?
The question is not meant to "weed out programmers", it is meant to weed
out people who don't really understand the vertical blank periods and it's
usage.
It's just one question, and just refers to some information that I expect
a games programmer to know. There is no reason for that information to be
something that is EXCLUSIVE to games programmers.
Mick.
a...@kuhub.cc.ukans.edu
will not settle for bs from an interviewer. The interview is a 2-way
street. The company wants a good employee; the applicant wants a
pleasant work place. The interviewer better impress on the prospective
applicant about the company too! :-) So, just be cool when answering
questions and don't hesitate to speak your mind. Your questions (!) if
well-phrased and timely will impress a lot of interviewers.
Anh
Val Kartchner
Drizzt Do'Urden <jtr...@herbie.unl.edu> wrote:
>That seems pretty silly to me. How long would it take someone to learn that?
>Just you sitting there telling them in 2 minutes would probably be somewhat
But understanding H-retrace and V-Retrace is important to games programming.
If someone doesn't already understand this, then they probably haven't
learned other important concepts. Not that they couldn't learn quickly.
But (I'm presuming) one question does not a failure make. The other
questions are probably testing other required basic knowledge.
>[....] I am sure even a non-computer
>person can tell you that once they have heard it one time.
Given what the average non-computer person knows about TV's, VCR's, and
interconnecting them (even given the appropriate manuals), you should
consider withdrawing this presumption.
--
|================= #include <stddisclaimer.h> ================/// KB7VBF/P11 =|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\/// University |
|=== "I think, therefore I AMiga" -- v...@cs.weber.edu ====\///= Ogden UT USA =|
Frank Pitt
>
>col...@alexia.lis.uiuc.edu (Scott Coleman) wrote:
>Here's a sample question:
>
>7) a) Briefly describe how the beam moves on a TV screen (ie how the
>picture is built up).
"Quickly"
>Explain how this relates to displaying graphics.
"It lets you see them"
>Explain what
>the Vertical Blank (or Vertical Retrace) and Horizontal Blank are, and
>what related interrupts could be used for.
"Related interrupts ?, most TV's don't have interrupts y'know."
"Or are you talking about the wife ? "
> b) Explain Double and Triple buffering.
"That's the addition of extra buffers at the end of the track,
to prepare it for a possible runaway train"
"Oh, and why are you talking in capitals ?"
:-)
Frankie
John Tessin
: I've worked at companies that do and do not require testing, and the companies
: that require testing are more pleasant places, because most of the phonies are
: weeded out.
This makes sense. In the companies that don't require testing, the Peter
Principle moves the phonies to management positions where they can make
life miserable. It all makes sense to me now. It's full of stars. :)
Ron Hunsinger
wrote:
> For all those people out there striving to become good programmers: When
> you laugh at an algorithm, you are nearly there.
Beautiful words.
I think of myself as a programmer. I love programming. This is not to say
that I have no outside interests, or that I spend all my time programming.
But it's what I keep coming back to. I do it for fun, and I am always
astonished that people actually pay me to do it. I've made my living at it
for 30 years, but I'd find time to do it even if it didn't pay.
I think that's the key to success at programming, or at anything else.
Find something you truly enjoy doing, and make yourself as good at it as
you can. Get good enough at anything, and you'll be a success.
But just as with anything else, it takes practice to get good. You don't
get good at track without running. You don't get good at guitar without
playing. You don't get good at poetry without writing. And you don't get
good at programming without programming.
I hear some "programmers" who talk about their jobs as if they were mules
pulling a cart. They don't enjoy their work; it's just something they do
between paychecks, or between deadlines. They measure their own progress
in terms of units shipped or deadlines met or lines of code written, as if
they were baggers at the supermarket. It depresses me when I hear it. If
they don't truly enjoy their job, why do they do it? A paycheck is nice,
but there has to be more to a job than that. Any job will produce a
paycheck. Why don't they pick one that makes them laugh as well?
And they won't write a line of code or crack a textbook unless they're
being paid for it. This I truly do not understand. Even if all they care
about is that paycheck, don't they understand that the paycheck will be
bigger if they get better, and the best way to get better is through study
and practice? (Getting better will also increase their enjoyment of the
work.)
So they ask me: "Why are you reading the code for the OS? The OS is the
vendor's responsibility." (Answer: I like to read, as well as to write.
You can learn a lot reading other peoples' code.)
Or, "Why are you studying Language Theory? We don't write compilers here."
(Answer: (a) I don't expect to spend my whole career never having written
a compiler, and (b) Compilers aren't just for programming languages. Any
time you write a parameter-driven program, you are compiling the
parameters.)
Or, "Why are you studying all those fancy-dancy data structures and
algorithms? Linear search gets the job done." (Answer: Sometimes the
plain-and-simple method just doesn't cut it.)
Or, "Why bother with complexity theory? I've been programming for years,
and I never had to learn any math. (Answer: It saves a whole lot of time
to be able to look at some code and see where the bottlenecks are, without
having to run a profiler. It saves even more time if you know even before
you write it that it won't be fast enough, so you can skip ahead to coding
the algorithm that will be fast enough. It's essential to know ahead of
time what will happen to performance when you scale up from sample data to
the real data, which is often orders of magnitude larger.)
And always, the real answer is: Because it's fun! (But they shake their
heads when I say that, or try to teach me the error of my ways.)
Then later, they come to me and ask: "How do I do this?" or "How do I do
this faster/in less memory?" or "Why is this taking so long?". And I tell
them. And they say "Where did you learn all this stuff?" And I shake my
head again, because I've already told them where I learn all that stuff.
But I'll say it again, because it bears repeating. I learn by doing. I
learn by reading code that I don't have to read. I learn by writing code
that I don't have to write. I learn by studying subjects that I don't need
to know. Most of all, I learn by having fun.
(For those who keep worrying about deadlines, let me emphasize that the
time I spend having fun is never wasted. No matter how useless the
knowledge seems to be when I learn it, it always comes in handy somewhere
down the road, and more than once has helped me meet a deadline that
wouldn't have been met otherwise.)
So that's why it was so nice for me to see your words, because they echo
my feelings:
The way to become a good programmer is to have fun programming.
-Ron Hunsinger
Ron Hunsinger
> I've seen enough of them so
> that I can spot the BS at 50 paces, other clues are sentences containing
> buzzwords that don't quite mix, these will increase exponentially while
^^^^^^^^^^^^^
> you are still playing dumb.
You mean like using "exponentially" for something that isn't exponential?
-Ron Hunsinger
Ron Hunsinger
Group) wrote:
> although I suppose it would be a good trivia question to
> ask a potential employee as to which instruction uses the longest mnemonic.
> Or a better question would be: What non-math instruction takes the longest
> amount of time on the Pentium (2000+ clocks)?
I haven't looked at a manual for any Intel processor past the 8086, but I
might be able to guess this one.
Would there be a RESET instruction?
-Ron Hunsinger
Terje Mathisen
No, there's no single RESET opcode, but you can make the BIOS do a lot
of work for you, by making it switch to protected mode and back.
The longest-running instructions should be those with a REP prefix.
On my 40MB P5-60, a REP LODSB of all ram can take a _lot_ of cycles. :-)
A REP INSB from a very slow (bus-based) port can take as many cycles
as you want.
--
-Terje Mathisen (include std disclaimer) <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
NewOrder Demo Group
Ron Hunsinger <hns...@sirius.com> wrote:
>NewOrder Demo Group, while naked bungee jumping, wrote:
>> What non-math instruction takes the longest amount of time on the
>> Pentium (2000+ clocks)?
>
>I haven't looked at a manual for any Intel processor past the 8086, but I
>might be able to guess this one.
>
>Would there be a RESET instruction?
Nope. There is an instruction RSM (Resume from System Management Mode) that
takes the second longest time for a non-math instruction (83 clocks).
>-Ron Hunsinger
--TCA of NewOrder
newo...@carina.unm.edu
jason dorie
>
>Back to recruiting games programmers. Before hitting on the "Amusing
>Algorithms" idea, I had devised a test of 20 questions and problems to
>give to prospective programmers. This test has worked very well, I have
>got two excellent programmers and discarded scores of others who did not
>quite reach the mark.
I find this to be a fairly on-topic discussion, myself. The company I work for was spawned
by a few employees of another, and all of them emphatically laugh when telling the story of
one of the potential programmers that made it by the "aptitude test":
Apparently, this fellow was doing a really basic gui of sorts, part of which required him
to test if the pointer was within a given screen rectangle. Supposedly (I can't honestly
imagine anyone being this lost, but...) he used a case statement which checked every valid
screen coordinate within the rectangle by using a pair of nested FOR loops, and when a coord
matched, he set a flag, and continued looping. After the FOR loops, he tested the flag to see
if the pointer was in the rect. I howled.
Jason.
---
0x2b | ^0x2b - Shakespeare
a == b; ! - Wayne & Garth
Program Life;
var
Dead : Boolean;
Eat, Sleep, Work : Procedure; External;
Begin
Repeat
Eat;
Work;
Sleep;
Until Dead;
End.
John Tessin
: *sigh* I guess you had to be there...
Unfortunately, many of who went to school, were. Isn't tradgedy just so
hilariously funny.
Pete Rowley
hns...@sirius.com "Ron Hunsinger" writes:
> I think of myself as a programmer. I love programming. This is not to say
> that I have no outside interests, or that I spend all my time programming.
[SNIP]
> So that's why it was so nice for me to see your words, because they echo
> my feelings:
>
> The way to become a good programmer is to have fun programming.
I totally agree. However, your emphasis on *enjoyment* and *fun*
says alot more to me than - able to laugh at an algorithm. The
former shows you are deeply interested in computing matters, while
the latter may indicate greesy hair and bad breath ;)
--
________________________
| | ()()_________________________
| Pete Rowley | |______ ____ _ ___ _ _ | GIG: 11/4/95
| Edinburgh | | _ \ | || || __ | / _/| |/ / The Venue, Edin.
| pe...@adder.demon.co.uk | | |_| || || |||__||| |_ | < supp. Freaker,
|________________________| |____/ |_||_||_||_| \__\|_|\_\ Pierced
Pete Rowley
I don't follow. What's the problem with that? (Apart from the fact
that it isn't a *buzz* word anyway)