Slashdot Mirror

> The term "hacker" goes back to the university computer scene of a decade or two earlier.

Yes but it meant subverting security measures even back then. Like I said: retcon.

More fuel for the Gates quote debate:

http://imranontech.com/2007/02...

So such measures could only identify rather extremely poor performers....

This is precisely what I have been saying: all objective developer performance metrics are only unambiguous in extreme outlier cases. However, such objective metrics *do* exist. Recall that my point of contention with your original post was your assertion that all developer performance metrics are entirely subjective.

Triviality is subjective. In my experience, people who are not programmers tend to greatly underestimate the complexity of certain programming and other technical tasks.

I concur with your experience with non-programmers, but that's a different subject. However, one can set an objective bar for triviality with something like the Fizzbuzz test. If a developer can't solve something like this on their own within several hours in the programming language in which they were hired to develop, then... well, it's fairly self-evident.

But the ability to write code that compiles and describe algorithms to solve trivial problems is only sufficient to reject a hypothesis; it is not sufficient to imply that the person is a good or average programmer.

Correct, and this goes back to the typical misapplication of metrics to developer performance that we both agree happens in the overwhelming preponderance of cases. As you have pointed out with numerous examples, most metrics are ambiguous in common cases and do not provide a good discriminator function between good/bad performance (and typically yield perverse incentives for developers).

The cases where objective metrics would be unambiguous are those cases where it is blatantly apparent that the developer is substandard/excellent.

In the end, though, the problem of identifying inferior developers is important. It would be nice to have some objective metrics that flag a developer for further, human-based review. The alternative to this is the "torches and pitchforks" approach to culling "inferior" developers on the team: terminations solely due to complaints from other developers (which can rapidly degenerate into a witch hunt/Reign of Terror).

I think an analogous example of what I am suggesting is the use of BMI as a metric in US armed forces recruitment. Any applicant with a BMI over a certain threshold is automatically rejected as obese. However, BMI is a flawed metric and can misclassify an outlier, highly muscular, fit person with low body fat as "obese". In this case, a human review is conducted (photographic evidence is sufficient proof) and the BMI rule is waived. Hm... technically, they could even patch this example with a separate objective test of body fat percentage, but I'm sure you get the general idea.

In the wake of the case of the inferior developer that I cited in my previous post, we established rules about forcing people to commit within a certain interval so that *some* progress could be verified/reviewed. If a developer did not meet that objective metric of "committed work-in-progress code to the version control server at least once per week for cursory human code review" (for whatever reason), then they were chided and became subject to a more in-depth human review of their progress (yes, this part is definitely subjective). This helped a lot, because not only did it prevent a repeat case of the inferior developer debacle, it also allowed the team to help decent developers with their progress by pointing out pitfalls or helping devs "get unstuck".

I guess one might term this to be the use of potentially-ambiguous objective metrics prompting subjective review.

Hacking: Using your capabilities to gain access and explore an unknown programmable system.

Actually, for old-timers (and many still at MIT), hacking can imply getting access and exploring just about any kind of system, even gaining physical access and exploring. (Hence, the "hacks" at MIT which have involve placing objects in inaccessible places, etc., which comes from a culture of "hacking" (i.e., exploring) the rooftops, basement tunnels, and other parts of MIT campus.)

But "hacking" in the early days did seem to be associated with certain types of electronic systems, notably telephones and the MIT model railroad club.

In any case, it should be noted that a negative connotation could apparently be attached to the word even in its earliest usages. One of the earliest known citation of the word in print (from the MIT newspaper) from the early 1960s actually refers to disruptive hacking of phone systems:

http://imranontech.com/2008/04/01/the-origin-of-hacker/

why do you say that?

It [640K] was ten times what we had before. But to my surprise, we ran out of that address base for applications within — oh five or six years people were complaining.

I have to say in 1981 making those decisions I felt like I was providing enough freedom for ten years, that is the move from 64k to 640k felt like something that would last a great deal of time.

The problem is that for many things, there is no test which can be performed in a vacuum and in a reasonable amount of time. Take software, for example: While there are things like FizzBuzz which can very quickly identify people who are in no way qualified, it's a lot harder to quantify whether a person is qualified.

If you choose not to perform it in a background, then you're looking at software this person has written in the past. There is the problem of possible plagiarism, but I imagine anyone who's contributed to open source has a leg up here. But what if they've only worked on heavily proprietary software? Then check their references.

What if they never did either? What do we do about those people who have taught themselves to program, but are looking for their first programming job? Are we essentially demanding that in order to get a job, you have to first learn to program, and then hack on open source for a few years until you have enough of a portfolio to get hired? Even then, if they only ever submitted patches (instead of starting a project of their own), would you trust them to lead a project? If they only ever started their own small projects, with very few other contributors who almost never did anything useful, would you trust them to work on any sort of team project?

The other option is to have the certification still be "in a vacuum", so to speak -- that is, we apply a standard test of some sort, without looking at the person's history beyond the scope of said test -- but for it to not take a reasonable amount of time -- it'd take years of monitoring the person's understanding of a wide range of topics related to the field they're entering, some directly, some much less so. I guess we call that a degree.

That was from IBM, not MS. Look it up, really!

I can find Bill Gates denying he said it. I can find someone saying they don't believe him. I can even find someone saying that the quote is likely apocryphal.

It doesn't seem like anybody is actually reliably attributed to this quote. So, either it's a meme that's stuck, or Bill Gates is lying, or it's mis-attributed and nobody knows who said it.

Anybody got something more definitive?

In many cases it's a team of individuals

We always have a team of individuals interviewing. But it helps that I wrote the book on the current hiring process. ;-)

(Ok, so it was a single document that acted as guidelines. But that's beside the point. :-P)

I have yet to see our team strongly divided on a candidate. Once we worked together to nail down a good interview process, we managed to separate the wheat from the chaff pretty quickly. To the point where there was no question over whether or not the person was competent or not. Either you can demonstrate an ability to handle coding and a very general sense of the technologies we use, or you can't.

Of particular interest is the Fizz Buzz test I throw at candidates. I don't care how long it takes them to get it right or if they have to ask questions. I try to make the candidate as comfortable as possible, then go through the problem with them. We sketch it out on a whiteboard and talk it out like a real design session. From that session, I can clearly see how the candidate works through problems. I can even reliably separate out what is nerves and what is a lack of capability.

It helps that Fizz Buzz has a few gotchas built-in that most people trip over. Tripping over those gotchas is not a bad thing. In fact, it reveals how the candidate attempts to create logically efficient code. I've seen a few different solutions, but I've never failed any given solution.

What doesn't sit well with me may surprise you. I don't like it when candidates attempt to obfuscate the code. Many will write in a pseudo-code that deliberately obscures the logic. This is often in an attempt to hide a lack of knowledge. Others have trouble correcting bugs. If I point out a bug (e.g. "You're off by one in your loop."), they'll go and screw up some other part of the program and STILL not fix the problem. Of course, the good candidates tend to spot the problem themselves as we step through the logic. I don't have to explicitly point it out. Finally, an unwillingness to try really tees me off. I'll happily answer all the questions they want. I'll even write large chunks of code for them. But when they manage absolutely nothing on their own, they're as good as useless. (You'd be amazed how many people survive by conning others into doing their work for them.)

No one of these points will disqualify a candidate. But given enough opportunity, the signs start adding up. Before you know it, you've got a pretty clear picture of basic competency.

Oh, and one other thing I hate: Don't lie to me. Don't tell me you've got strong experience in something when all you've done is stand near someone who used the technology. The truth will come out pretty quickly and will get you knocked off the roster post-haste. If a candidate comes up short but shows promise, I'll often recommend them for a more junior position. But not if they lie.

Getting back to my original point, if I felt really strongly about a particular candidate that no one else liked, I probably have enough credibility stored up to convince at least a trial period. But I've thankfully never been in that situation. It's usually clear if we should dump them or hire them. The worst I've ever seen was a candidate where there was a concern over the strength of a candidate's communication skills. We still hired him. :-)