personal comments edit

Technically Reginald Braithwaite started it, but freaking Atwood blogged it and now almost every blog in my RSS reader is talking about it, so I’m going to throw in my two cents in and then I’ll shut up.

The controversy: Lots of people who claim to be programmers actually can’t program.

What kills me is that this surprises anyone. It’s sort of like blogging that “lots of people who see the sky claim it is blue.” There are a lot of incompetent people, folks, but no one will admit they’re the incompentent one. Did you ever notice that everyone else on the road is a bad driver except you?

The point Atwood was making is that it’s kind of sad that people who come out of school with these great qualifications or have these amazing resumes or whatever can’t actually do what they claim. If you give them a simple problem to solve, they can’t do it. (That’s the “FizzBuzz” thing: 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.”)

Hanselman has a pretty good response

  • that some features are inherent in the person (“When you’re putting together a basketball team, you have to remember that you can’t teach height.”). I sort of buy that and sort of don’t. There have been successful shorter basketball players. From personal experience, I know that I got shafted out of having a career in 3D animation and modeling because art houses believe you can teach an artist computer science but you can’t teach a computer scientist art (even though I had a portfolio, I also had a CS degree and not an art degree, so no one would touch me; times may have changed since then).

Phil Haack brings up an interesting corollary

  • that it’s fascinating how many people solved Atwood’s puzzle in the comments (utterly missing the point) and got it wrong because they didn’t read the requirements thoroughly. That’s just as bad as not being able to program.

But the best response I’ve seen, and the one I agree with most, is a tiny blurb from Mike Gunderloy on today’s Daily Grind:

…about 90% of the “essential .NET knowledge” and “write this code at an interview” questions I’ve seen (not specifically on Scott’s weblog, but around in general) are beyond me, despite a successful programming career that spans a couple of decades now. There are other skills besides tucking stuff away in your head. Dogged determination, a few basic techniques, brute force, and good skills at looking things up can go a long way in this industry - not that those are the most common skills in this industry (or any other) either.

So there are really two issues here: What can you do and what do you know?

From a “what can you do” standpoint, I think programming at the interview is a must. If I’m interviewing someone for an ASP.NET job, I like to see that the person can create a page that takes some information in and echoes it back. It doesn’t have to be anything special, just something to indicate you know your way around. (Bonus points if you can do it without the visual designer.) I try not to have people “code on a whiteboard” because, frankly, I’m an Intellisense addict myself and rely on that and the compiler to tell me when I’ve accidentally used the “Count” property instead of the “Length” property or what-have-you. If you can pseudocode it, I’m good.

The “what do you know” question is more tricky. I find that the facts in your head are generally the things that are relevant to projects you’re working on at the time and some remnants from past projects. For example, I’m not a COM guy. I got my CS degree on Solaris and my first couple of jobs were in LAMP land, so, no, I really can’t tell you about the ins and outs of why COM needs this or the limitations of COM’s foo. I’ve never needed to know, and frankly, if it came down to it, I’d go look it up, so there’s really no point in having it memorized.

I can’t tell you how many times I’ve been neck deep in some complex situation in ASP.NET and thought, “Hey, this would be a great interview question!” No, it wouldn’t. It wouldn’t be good because it’s only really pertinent to the odd edge case situation I’m in, and it doubly wouldn’t be good because I’ve been working with that exact thing for the last 80 working hours. If I were to ask myself that same question in a year, would I remember the answer? Probably not.

This reminds me of the best teacher I had in college, the guy who taught the computer algorithms class. Lots of kids didn’t like him because of his teaching style. At the beginning of the class, he’d give a brief intro of what you’d be seeing. Then he’d put up a slide that described an algorithm - sorting, searching, whatever - and you’d copy the slide down. He’d ask for questions when everyone was done, and swap slides. Rinse and repeat. Tests were entirely over the slides and the book, and the test was open-book, open-notes.

Right now you’re asking what the point was, aren’t you?

The point is this: There is no time in your programming career where you’ll be working without access to reference material. You need to be familiar with the concepts and aware of what’s going on, but there’s no point in memorizing things you’ll be able to easily look up when you need them.


That’s probably the most brilliant thing any professor ever presented to me in my entire college career. (That, along with my vector calculus professor admitting that we’d only really need to know vector calculus “out of curiosity” - that most of us would never use it again.)

So in my mind, the answer to questions like “What is the maximum amount of memory any single process on Windows can address?” is “Google.” It’s trivia. When something like that becomes relevant to what I’m working on, I’ll go look it up and that’s the point at which it will be fresh in my head. Somehow I don’t feel like not having that information at-the-ready makes me less of a good developer.

What I’m more interested in, as far as “what you know,” are conceptual things. Do you understand the various concepts of object orientation? Can you compare and contrast strong typing vs. weak typing? Can you talk to me about garbage collection and why it’s important (or not important)? Which languages have you worked with and what were some benefits and drawbacks of each? When you get to applying for a specific position (e.g., an ASP.NET developer), can you answer some simple things like what the events are in the page lifecycle? Difference between a handler and a module? Things that you’ll be using every day. I might not ask you to code a handler or a module, but you should at least know what they are.

Of course, if you can’t at least pseudocode an answer to the FizzBuzz problem or, given a decent IDE, actually write an application that does it, don’t bother applying.

web comments edit

I use Google Talk and like it as a reasonable chat client, but the primary use I have for it is the mail notification for Gmail.

To get to your Gmail inbox from Google Talk, you right-click the icon in the Windows task bar and a little menu pops up and lets you choose “Inbox.” The problem I’m having is that it doesn’t always quite work. You not only get the Google Talk menu, but also the standard task bar menu:

Google Talk focus

If you left-click the task bar first, then right-click the Google Talk icon, everything works. If you dive in and right-click the Google Talk icon directly, this weird focus thing happens. What gives?

General Ramblings comments edit

Man, the last week or so my site’s been acting up because the server I’m hosted on has had disk trouble, service trouble, and any other trouble you can conceive. First the disk went bad, then they fixed that but not all the services (PHP) were running… then they got PHP running but MySQL wasn’t running…

The last two days the MySQL service has been down but PHP has been up, which is why the blog was accessible through RSS (it’s static XML right now) and the main page was sort of wonky and empty looking.

The interesting thing is that the hosting company had said they were going to move everyone off that server to a new server… but rather than just doing that, they futzed around for a while trying to revive this old server. I ended up having to specifically say, “Hey, what happened to the migration? Maybe an expedited move to the new server for MySQL users is in order?”

I hate to be the squeaky wheel, but dammit anyway.

I did learn something, though. I realized that uptime metrics described in percentages are sort of meaningless. Maybe other people realized this long ago, but if you think about it, you could be down for a whole day and still have a 99.7% uptime. You’d have to be down for four days to break the 99% barrier. That’s four whole days - 96 hours.

I’m no longer interested in percentage uptime. I’m interested in hours of downtime. You want to impress me? Skip that “99.9% uptime” baloney and shoot for less than one hour of downtime per year. (And, yeah, I know the people giving out “five nines of uptime” garbage really mean an hour of downtime or whatever, but part of useful metrics is describing the metric in easily intelligible units. Don’t make me have to calculate that crap. “Oh, we’re only down for 0.042 days per year.” Give me a freaking break.”)

On the plus side, I get a good, personable response from the support people at the hosting company and they’re totally understanding and nice and easy to work with. From that standpoint, I can’t complain, and honestly, the service does make all the difference. Let’s just hope we don’t have another burp like this.