Programming Languages

Perfect example

Recovered from the Wayback Machine.

Here’s a perfect example of how the computer field is broken:

In a post at Coding Horror, based on earlier posts at Imran on Tech and Raganwald, the author parrots what the others state, that programmers can’t program. With lots of exclamation points.

Why make such a breathtakingly grandiose claim? Because of what happens in interviews. It would seem that the originator of this newest fooflah created a series a tests given during the interview process and found:

After a fair bit of trial and error I’ve discovered that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call “FizzBuzz Questions” named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

Jeff Atwood of Coding Horror also goes on to quote others who run into the same problems: interviewees can’t seem to do even the simplest coding tasks during interviews. These gentlemen completely ignore the environment and focus on the grossest of generalities:

Programmers can’t program.

Here’s a clue for you: I don’t do well in programming tasks during interviews, and I’ve love someone to come into my comments and tell me I can’t program based on this event. No, I’ve only faked it while working for Nike, Intel, Boeing, John Hancock, Lawrence Livermore, and through 14 or so books–not to mention 6 years of online tech weblogging.

In fact, you’ll find a lot of people who don’t necessarily do well when it comes to programming tasks or other complex testing during job interviews. Why? Because the part of your brain that manages complex problem solving tasks is the first that’s more or less scrambled in high stress situations. The more stress, the more scrambled. The more stressed we are, the more our natural defensive mechanisms take over, and the less energy focused into higher cognitive processes.

Why do you think that NASA, the military, and other organizations training people for high risks jobs spend so much time in simulation? Because they want the tasks to be so ingrained that in a stress situation, the people’s responses are almost automatic.

If you add the potential for embarrassment on to the strong desire to do well, the need to get the job, toss in a panel of arrogant twats sitting around a table looking directly at you while you do your little tests, and you have the makings of an environment that almost guarantees the elimination of many fine candidates.

Who does well in these kinds of testing situations? Good testers, the supremely self-confident and equally, typically arrogant, and the people who don’t care: none of which is necessarily the best candidate.

The whole purpose of tests such as these are not to determine if a person has programming capability–how can one stupid test determine this? What these tests do, though, is add to the self-consequence of the person doing the interview.

“I can do this, but all these people can’t. Therefore, I’m so much better.”

It’s also a lazy interview technique, which shows that HR associated with the company doesn’t give a crap about the IT department.

Some justify such tests with, “We need people who can do well in stress situations.” Bilge water.

The stress one goes through when one is an outsider faced with a bank of insiders, is completely different than the stress an individual goes through when they’re part of a team trying to fix a problem or roll out a product. Comparing the two is ludicrous, and nothing more than a demonstration of completely two-dimensional thinking: one form of stress is completely the same as another. My god, no wonder we’ve had few tech innovations lately if this is demonstrative of leadership in IT.

Having candidates bring in samples of code and having the interviewer and interview team review such, and question why decisions were or weren’t made is an excellent way of getting insight into the person’s problem solving skills, without the trained dog and pony show. Asking a person what approach they would use in a situation is superior to doing a random memory test on keywords. Providing applications and having the person provide their own critique is an amazingly effective way of getting insight, not only into their problem solving skills, but also into their personality. If they point out errors but do so in a thoughtful manner, it’s a heck better than doing so in as scathing a manner as possible.

Looking at past applications or effort is another effective approach. New programmers with no job experience can provide pointers to open source applications; experienced people who have worked in an NDA situation can provide pointers for discussions and work online: heck, Google the person’s name–that will tell the interviewer much more about the person than a silly programming test.

That primitive techniques such as the abysmally stupid “FizzBuzz” approach are used shows that companies are still missing out on good people because they have idiots doing most of the interviews.

And making the leap between how people do on interviews into such grand claims that programmers can’t program demonstrates that idiocy travels up the food chain.

You know what’s especially humorous? All the people who solve the test questions in the comments. What possible reason would a person have to do such a thing? It’s completely irrelevant to the environment in which these so-called tests are given. This no more shows that these people can program, then it shows that the other people can’t.

The lack of logic in this whole thread is amazing.

What’s less funny, though, is the slavish adherence to Joel Spolky’s elitist crap. Joel runs a smallish computer company with limited products: what the hell makes him the definitive answer on these topics? Perhaps the people should spend less time making pronouncements, and more time developing independent thinking skills.

Many of the comments in the Coding Horror post do mention these concerns, and provide other effective approaches to interview. If the people who create these tests will actually read these responses, some good will have come from the discussion.

I have found, though, that people who write these kinds of tests aren’t always willing to considering other options. The other approaches just aren’t ‘clever’.


Known universe

I’m not sure why I’m getting 404 log entries for pages that WordPress serves. The material that mentions this online this seems confused. If anyone has any suggestions, I have ears enough.

I think I have all my redirects, other than managing a 401 document, which Phil suggested. That’s what’s causing the conflict between WordPress’ htaccess that ate the world and authenticated subdirectories.

I have too many categories, and need to merge these, and also provide redirects when I do. That’s the number one reason NOT to use categories in permalinks. Oh well, life needs challenges.

What I also need to do is create 410 gone entries in my .htaccess file for the permanently removed resources. Until finished, and until I recover from my merge, people will have to suffer through my 404 page.

Social Media

To those who say it doesn’t matter

Anne Zelensky attended the recent Adobe Engage. She writes of her experience, being one of the few women present:

There were slights throughout the day: a mention of “granny mode” for a beginner’s big fonts mode of some Adobe software, a comment from some developer along the lines of “our users aren’t technically astute, they’re mature mothers,” and an example of a cell phone graphic for girls that was pink with cutesy animals. Stereotypes of females attended in greater numbers than actual females, if you don’t include the Adobe women who were there. No wonder these stereotypes prevail. If you work in an environment with actual women you might learn that some are technically oriented and some less so, some like pink and some do not, some are airbrushed and perfect like a Victoria’s Secret model… but most are not. I am not airbrushed and perfect, as anyone who has met me online or in person knows. But I am real in a way that those Victoria’s Secret models and clueless LASIK-free grannies and imagined versions of mature mothers are not.

I didn’t speak up yesterday with my complaints except on the ad hoc Twitter back channel because I do want to work within this space of blogging and technology and influence. I don’t want to fight against it and be labeled shrill or out of touch or difficult. That’s why I so appreciate James’ speaking out. James is not going to get labeled shrill–only women are called shrill. And it’s fine within tech blogging for men to speak for or against diversity.

Being one who is labeled shrill or out of touch or difficult, Amen.


Distance learning

Eric Langhorst is a history teacher in Liberty, Missouri. He’s been specializing in ways of using the internet in order to aid in the teaching of history, and has posted conference notes about his research for the MidWest Education Technology conference here in St. Louis.

It’s a nice presentation, but it does demonstrate the growing importance of global broadband coverage. Our community is looking at wide-area wireless for the county, and all the public library system now provides free wireless, as does the downtown St. Louis area.

Lee at Black River News mentions the new Missouri Virtual School program, which lets kids take classes over the internet. This would be particularly valuable for rural areas, especially within school systems struggling with funding. It’s unfortunate that there’s no plan for providing the internet coverage into those areas more likely to benefit from such.


Browser testing

Roger Johansson details his browser testing strategy and it is far more extensive than mine–at least for CSS and markup, though I go much further when it comes to JavaScript.

  • I start with, and use extensively, Firefox on the Mac. The main reason why is the extensions, specifically Firebug. I think that Joe Hewitt’s Firebug is the third single-most important component of today’s new web development–following on Mozilla’s innovative architecture, which enables such extensions, and REST.
  • I then test with IE7 on Windows XP. Why? Because if anything I do is going to break, it will break with IE. I no longer have an IE6 box, but I do use Total Validator to take screenshots in IE6 and Konquerer if I’m working on issues of design.
  • Next, I test with Opera on the Mac, which helps me discover those things that Firefox allows that aren’t necessarily standard. I find Opera to be the most standards compliant browser.
  • Then I go to Safari and the most current WebKit, both still on the Mac.
  • I need to test with Camino and Flock more. However, my logs tell me I have people using IE, Firefox, Safari, some Opera, rarely Konquerer, and older versions of IE, on Windows and the Mac. These are my target audiences.
  • I tested the book with OmniWeb, but I don’t have it any longer as it’s a ‘cost’ browser and the cost isn’t justified.
  • I test with Netscape and Opera on Windows XP, last. I used to test for IE6, and I did for the book. However, I don’t have access to a IE6 machine, now, so am dependent on IE6 users to tell me if something breaks.
  • I provide a mobile stylesheet, which Ralph at There is no Cat, was kind enough to test for me. I also use Opera’s mobile feature to test.

One thing I talked about in the upcoming Adding Ajax book is understanding your audience before making a choice of target test browsers. If we use progressive enhancement as a development approach, which means creating the functionality without the use of scripting and then gradually adding script effects, then we always have a natural fall back if a script effect doesn’t work with one browser or another: just disable the effect for the browsers that choke. Those few who are still using IE 5.5 on the Mac (why?), or IE 3.2 (WHY!), at least get a decent shot at a workable page, if not a terribly interactive or visually appealing page.

Then there’s my feeds. If all else fails, I provide full content feeds.

Roger’s mention of semantic markup is spot on, also. I haven’t been pursuing this as diligently as I should, and plan to go over my design one more time and look for better uses of markup—after the book has gone to production, of course.

My biggest design problem? Fonts. I can never find a font that seems to look good everywhere, and that scales as well as I’d like for each resolution. That’s mainly because I haven’t taken the time with fonts as I should. Another thing to explore as soon as the book is finished.

Oh, and this site is using a conditional IE stylesheet.