Comment by zeteo | Hacker News Reader

Comment by zeteo | Hacker News Reader

These discussions are worse than useless. People with made-up numbers confront people with unreliable anecdotes. Productivity means, very simply, an average of X widgets per hour. Does such a measure even exist for developers? The discussion can apply to such varied situations as:

- how fast can a developer add new features to a system they built themselves

- how fast can they add features to a system designed by somebody else

- how fast do they fix simple bugs

- how fast do they find horribly complicated bugs

- how fast can they architect a reliable, multithreaded backend

- how fast can they work with program management to design a good UI

etc. etc. etc.

These are often conflicting requirements. People who develop a very elaborate personal coding style will be fast on single projects, but slow to work with other people's code. Those who are methodical and question all assumptions will find hard bugs much sooner, but waste time on simple bugs. Those who can construct elaborate systems in their head often have trouble tweaking hundreds of little CSS details for a single ticket. So I would venture that, for any pair of moderately experienced developers, it's almost always possible to find a pair of tasks such that one of them is twice (or even ten times) as fast as the other. Let's not even bring up how much the incentive structure can vary, even among people in the same department.

The example that the article brings is terribly vague and uninstructive. Is that guy, for his whole life, going to be a "1/10 developer"? We never get an idea why he was slow in the first place. Was he lazy? incompetent? concentrating on his studies instead? not motivated by the incentive structure? risk averse because breaking the system carried harsher personal consequences than developing it excruciatingly slowly? The author doesn't even figure out the roots of the problem in the one case he's familiar with, and purports to give advice to everyone else based on it...

> So I would venture that, for any pair of moderately experienced developers, it's almost always possible to find a pair of tasks such that one of them is twice (or even ten times) as fast as the other.

I completely disagree. The FizzBuzz syndrome is very real: when I do developer screenings, the majority of candidates simply can't program even tiny problems. There's no way they're faster than anybody on my team at any development-related task. And yet, they all have long resumes and a lot of experience. All those people are working someplace. And I've watched these 1/10 developers at work: they copy/paste lots of code, program through trial and error, and spend most of their time in the debugger. Eventually, stuff gets done, but excruciatingly slowly.

Once you reach a certain level of competence, then I think what you're saying is true. But there's a huge number of developers who don't reach that level.

On the other hand, I agree with you about this article. Some sort of insight on where this dev spent his time might have been interesting. Whenever I read things this vague, articles based on vague impressions rather than any hard metrics, I'm left wondering which side was actually incompetent here. Maybe this was one of the 1/10 CTOs, completely incapable of effectively communicating with people who don't fit his favored personality type. And if the feature the dev was working on was replaced with something else that only took 30 minutes to implement, maybe the original design was simply unworkable.

The fizzbuzz syndrome is real alright. But someone failing fizzbuzz is not an indicator that they will always be incapable of development. It just means they are very junior and require training. Frighteningly for the West, Indian and Chinese companies appear to grok this and actually develop their employees. US and UK companies throw their hands up in empty self-satisfaction that their work is so intellectually difficult that people up to the challenge are impossible to find. The reality is probably that the corporate business model is flawed meaning they cannot afford the seniority of guy they need.

The problem is that these people are supposed to be programmers, i.e. people who have been trained already. Yes, it is real that companies do not want to train people - and that is a problem in itself. But if someone tells me "I am a professional programmer" and I give him FizzBuzz and he cannot solve it it is no training problem. It is a problem with hiring: How could such a person ever hold a position as a programmer (without "trainee"/"apprentice" behind their job title)?

I worked with a developer for a year and a half, who has 11 years of experience, who cannot code fizz buzz and cannot accomplish basic tasks. I have to hold his hand through even the smallest changes or bug fixes. These people exist.

He just got a new job at a large company with a significant pay-raise. The industry is filled with people who are, to put it bluntly, incompetent.

edit: that last line is a little harsh. I don't mean "filled" as in entirely or even mostly. I am just trying to say they aren't uncommon.

How senior would you need to be to write fizz-buzz? Will someone ever gork that if they didn't after Teach Yourself Xlang in 24 Hours?

I doubt is a matter of seniority, its a matter of criteria, the way I see it is, FizzBuzz is useful only to weed out perhaps the lower 5% of the developers population and perhaps the lower 20% of the general literate population?

As an anecdote, I asked my wife, who's not a developer, she is an executive at a large beverage company, to solve FizzBuzz and to explain to me how she would do it and she did it successfully. She didn't use the word "for" or "while", but she explained that she figured there must be something that allows you to iterate over the same algorithm several times (paraphrasing).

Personally, I think FizzBuzz are useless unless you use them as part of a submission form before candidates send in their resumes, sort of like a slightly harder captcha. There is no place for a FizzBuzz once the company is already engaging with the company, if they are not able to solve it they will be earlier signs that they lack common sense and criteria.

> FizzBuzz is useful only to weed out perhaps the lower 5% of the developers population

Problem is, that 5% represents way more than 5% of the pool of job applicants, since it's those folks that continuously get rejected from jobs and keep applying. Any company hiring developers needs a decent FizzBuzz filter to sort out this riff-raff.

> There is no place for a FizzBuzz once the company is already engaging

In a technical and sharp company, yeah. In a company where the resumes go through HR and nontechnical managers, such that the first point of any technical evaluation is in the interview itself, then yeah that interviewer is going to need a FizzBuzz. And this is distressingly common in companies who hire some software developers but whose primary domain is not technology, like medicine or shipping or education.

Fizzbuzz is an analytical problem, not really a programming problem. A kid with no knowledge of a particular programming language could create an algorithm for it with a little guidance.

"Are there any patterns in this that we could use to make this shorter?" , "You're printing 'fizz' more than once. Is that necessary?", etc.

By the time you're evaluating someone with FizzBuzz, they're trying to convince you they have training and have developed from "very junior" (to wit untrained). FizzBuzz is the kind of test which should be a pass/fail final exam question for a 6-week Beginning Programming course, not something any degreed entry-level candidate would have trouble with.

Can they be trained? sure. But when applying for jobs, they're expected to already have training up to basic competency for the position. A restaurant shouldn't have to teach a prospective cook how to make a grilled cheese sandwich, an auto repair shop shouldn't have to teach a prospective mechanic how to change a tire, and a software house shouldn't have to teach a prospective programmer how to write FizzBuzz.

If such training is in fact needed, then the higher education "industry" is broken to the point that businesses should just get kids straight out of high school and take 'em from there.

Tangent:

The FizzBuzz question should really be "write me 3 versions of FizzBuzz, explain why they're different, and under what conditions would you use each over the others."

The fact that the FizzBuzz issue is a matter of whether the candidate can write it at all - and that so many interviewers don't view a "nope" answer as a full-stop red flag - indicates a baffling state of industry affairs.

Reply on news.ycombinator.com