http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Oh, *that's* fizzbuzz? Hmm, OK.

Also... that's really kinda scary. o_O Let's hope plumbers are better... 
uh... hmm, OK, maybe not. Well let's hope to **** that medical 
professionals are better! O_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

  As I have commented previously somewhere, I have heard about this here
as well. What's worse, at least in the past companies actually hired people
for programming positions just on the basis that those people *claimed* to
be competent programmers even though they hadn't ever written a single line
of code.

  Why do people apply to programming jobs even though they have no experience
whatsoever? My guess is that their rationale goes like: "I need a job badly.
Programming is really easy; heck, even kids can do it, so how hard can it be?
I'll ensure the job first, and learn the programming part later. It'll
probably take just a week or two."

  On a side note, interviewers should, on the other hand, be careful with
what they consider "trivial" assignments. Sometimes a problem might sound
quite easy and trivial, when in fact it isn't.

  As an example, the basic principle between binary searching (searching an
element in a sorted array in O(log n) time) sounds quite trivial. However,
it's surprisingly difficult to implement correctly.

  Take 100 experienced, competent programmers and give them the task of
implementing binary search on paper in the programming language they are
most fluent with, and perhaps 5 of them will give you a correct
implementation. (The rest will fail in some cases mostly due to off-by-one
errors.) A correct implementation requires surprising amounts of attention
to detail, and a quick&dirty naive implementation will most probably be
incorrect. And this for a piece of program that requires maybe 10 lines of
code at most.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   As I have commented previously somewhere, I have heard about this here
> as well. What's worse, at least in the past companies actually hired people
> for programming positions just on the basis that those people *claimed* to
> be competent programmers even though they hadn't ever written a single line
> of code.

I don't think this is unique to programming. From what I've seen, most 
managers get hired based on their ability to spout impressive-sounding 
BS rather than their ability to actually manage a department.

>   Why do people apply to programming jobs even though they have no experience
> whatsoever? My guess is that their rationale goes like: "I need a job badly.
> Programming is really easy; heck, even kids can do it, so how hard can it be?
> I'll ensure the job first, and learn the programming part later. It'll
> probably take just a week or two."

I would imagine that quite a few of then know damned-well that they 
can't program, and expect to be able to just con somebody into hiring 
them. I imagine this is the same for every profession.

The difference is that if, say, you claim to be a brick layer, and they 
ask you to build a small wall, and it looks like a piece by Picasso, 
then you don't need to be an expert builder to tell that this person is 
lying out of their arse. On the other hand, a broken program doesn't 
look "obviously" different to a working program. An expert can tell 
immediately, but to the casual observer, it's not so clear. So it's 
harder to tell whether somebody can program.

In a similar vein, there's probably a greater opportunity for 
self-delusion. If you try to build a wall and it's rubbish, you start to 
realise that building a wall is far more complicated than you expected. 
But if your program doesn't compile... it there just some small thing 
you need to fix? Or is it because your code is gibberish?

I'm sure I must have told you the tale of the MSc student who begged me 
to "fix me Java, yah?" He claimed it was nearly working, but it just 
needed a few small tweaks. So I sat down and read his "Java". What he 
had written was a bunch of Java language keywords, lots of curly 
brackets, nice indentation, but... IT WAS NONESENSE! It wasn't Java. It 
was gibberish that bore a superficial resemblance to Java. Lots of 
hopeful-sounding variable names, but not even approaching being 
syntaxually correct.

To this day, I'm genuinely not sure whether the guy was just writing 
gibberish and hoping to bluff his way through (or get somebody to do it 
for him), or whether he actually believed his code was nearly correct...

Finally, if you sculpt a work of art, everybody looks at that and goes 
"oh, that's great, it must have been really hard to make that". It's not 
nearly so obvious that programming is hard. (Especially when vendors 
keep trying to sell whizzy tools that make it all "easy" for "anybody to 
do".)

>   On a side note, interviewers should, on the other hand, be careful with
> what they consider "trivial" assignments. Sometimes a problem might sound
> quite easy and trivial, when in fact it isn't.

If the interviewer asks you to solve the Travelling Salesman Problem so 
that it can find a route between 500 cities in just a few seconds, you 
probably don't want to work for them. ;-)

>   As an example, the basic principle between binary searching (searching an
> element in a sorted array in O(log n) time) sounds quite trivial. However,
> it's surprisingly difficult to implement correctly.
> 
>   Take 100 experienced, competent programmers and give them the task of
> implementing binary search on paper in the programming language they are
> most fluent with, and perhaps 5 of them will give you a correct
> implementation. (The rest will fail in some cases mostly due to off-by-one
> errors.) A correct implementation requires surprising amounts of attention
> to detail, and a quick&dirty naive implementation will most probably be
> incorrect. And this for a piece of program that requires maybe 10 lines of
> code at most.

Hmm, OK. This doesn't sound especially hard. So let me see if I can 
implement it, and then everybody can laugh at how badly I got it wrong...

   find :: (Ord y) => (x -> y) -> y -> IArray x -> (Int,Int) -> Maybe x
   find field target array (base,size)
     | size <  0 = error "invalid subrange size"
     | size == 0 = Nothing
     | size == 1 = if field (array ! base) == target then Just (array ! 
base) else Nothing
     | otherwise = find field target array (base, size `div` 2) 
`mappend` find field target array (base + size `div` 2, size `div` 2)

Now I suppose I better go run that and see if it actually works.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

>   find :: (Ord y) => (x -> y) -> y -> IArray x -> (Int,Int) -> Maybe x
>   find field target array (base,size)
>     | size <  0 = error "invalid subrange size"
>     | size == 0 = Nothing
>     | size == 1 = if field (array ! base) == target then Just (array ! 
> base) else Nothing
>     | otherwise = find field target array (base, size `div` 2) `mappend` 
> find field target array (base + size `div` 2, size `div` 2)
> 
> Now I suppose I better go run that and see if it actually works.

Well, the final line is wrong for a start. (Due to rounding, if the 
array size isn't even, one element gets elided from the search.)

   | otherwise =
     let size2 = size `div` 2
     in  find field target array (base, size2) `mappend` find field 
target array (base + size2, size - size2)

That should work better. The division of a range into two subranges is 
still unequal, but at least all elements are included now...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

I few clicks away from this, I got to here:

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

I don't know about you, but *I* have always wondered why some people 
find programming hard. It is a "well known" fact that there seem to be 
two types of students: those who "get" programming, and find 
introductory courses ridiculously easy, and those do "don't get" 
programming, and find even the simplest exercises insummountably difficult.

I haven't finished reading this paper yet, but it throws some 
interesting ideas out there. One particular paragraph leaps out at me:


capabilities of computers could have a massive negative impact on their 
success at programming. Many of their subjects tried to use meaningful 
names for their variables, apparently hoping that the machine would be 
able to read and understand those names and so perceive their intentions."

Oh I have *so* seen this! People who seem to think that if they write 
their code with obvious-enough names and syntax that's near-enough to 
being correct, the computer will "just know" what they mean. They fail 
to grasp that the syntax must be EXACTLY CORRECT, even if it seems silly 
or unnecessary.

I guess it's because they're used to talking to humans. If you say 
something to a human with somewhat incorrect grammer (or even 
horrifyingly broken grammer), they can usually still figure out what you 
mean.

Computers are far, far more stupid than humans. But decades of advances 
in computing technology have brought us to the point where computers 
*look clever*, even though they aren't. I suspect this might be why some 
people have trouble learning to *use* a computer too.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
>
> Oh, *that's* fizzbuzz? Hmm, OK.
>
> Also... that's really kinda scary. o_O Let's hope plumbers are better...
> uh... hmm, OK, maybe not. Well let's hope to **** that medical
> professionals are better! O_O

the real problem is that many people who should really be plumbers or medicals
are into programming careers.  well, plumbing may still have its uses... :)

Post a reply to this message

>> Also... that's really kinda scary. o_O Let's hope plumbers are better...
>> uh... hmm, OK, maybe not. Well let's hope to **** that medical
>> professionals are better! O_O
> 
> the real problem is that many people who should really be plumbers or medicals
> are into programming careers.  well, plumbing may still have its uses... :)

Well, hey, at least getting programming wrong doesn't kill people...

...oh, wait:

http://en.wikipedia.org/wiki/Therac-25

Hmm. Oh dears.

Well, at least if a plumber or medical person does their job wrong, you 
can get compensation? :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis wrote:

> the real problem is that many people who should really be plumbers or medicals
> are into programming careers.  well, plumbing may still have its uses... :)

One could argue that The Real Problem(tm) is that IDE vendors keep 
claiming to have made programming "easy" now. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> be competent programmers even though they hadn't ever written a single line
> of code.

I usually ask them to print out the prime numbers less than 100 or something.

>   On a side note, interviewers should, on the other hand, be careful with
> what they consider "trivial" assignments. 

Yeah. I had one that was something like "print the lowest N values from a 
binary tree, in C". When's the last time I did recursion in C? And doing it 
over the phone? Bleh.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> nemesis wrote:
>
> > the real problem is that many people who should really be plumbers or medicals
> > are into programming careers.  well, plumbing may still have its uses... :)
>
> One could argue that The Real Problem(tm) is that IDE vendors keep
> claiming to have made programming "easy" now. ;-)

still waiting for the magical "Make Solution" button... ;)

Post a reply to this message