[adevine]

While this is true, I have found that a developer who can do the following to be very rare:

1. Take a set of requirements, and first identify those reqs for any underspecified elements, or elements where the underlying tech would limit the functionality.

2. Implement the reqs according to the now agreed upon spec

3. Provide adequate documentation and tests for the new implementation.

4. Perhaps most importantly, and rarely, implement the reqs in a manner where the code is not brittle (some small req change doesn't require a huge overhaul) and where other developers can quickly get into and understand the code.

That is, even if you don't need a rock star programmer, if your code base is going to live on for more than the life of the person originally writing it you are going to find that people who can fulfill this role are quite rare.

[coliveira]

All of these things could be easily overcome with better training. The way I see it, the software industry in the US invests close to nothing in training and expects to receive "talented" developers by just selecting a small proportion from a large pool of candidates. This is a lazy and irresponsible way to create a workforce. The time and effort they spend in interviewing could be very well spent on teaching best practices to new employees, so they would be much more productive, instead of just expecting that they somehow "grok" these concepts from the get go.

[ZanyProgrammer]

I think the implication is that you're supposed to learn all of that on your own. That's at the very minimum-you're supposed to eat, breathe, and shit hacker culture and programming in your spare time.

[zeroxfe]

> All of these things could be easily overcome with better training.

I think 1, 2, and 4, requires lots of real world experience in addition to training.

> The time and effort they spend in interviewing could be very well spent on teaching best practices to new employees

Assuming that just teaching best practices is all that is required, which I strongly disagree with, a lot of companies (especially startups) don't have the time or the resources to burn on extensive training. The marketplace is fiercely competitive, and they typically need people on the ground right away.

> the software industry in the US invests closing to nothing in training

Many large tech organizations (Google, Microsoft, etc.) invest a huge amount in training. The time it takes for a new hire at Google to get productive is usually about 6 months to a year. All still, they have a high hiring bar that focuses on very strong fundamentals. (They also work very closely with universities and colleges on direction, curriculum, and funding.)

[coliveira]

Your arguments clearly contradict each other:

"The marketplace is fiercely competitive, and they typically need people on the ground right away."

" The time it takes for a new hire at Google to get productive is usually about 6 months to a year."

It cannot be both ways as you please. Either these companies are investing in training or not. If they are, then things like requirements gathering, creating specs, and providing tests should not be something difficult to do. This is a very important part of the job, but is not a part that requires super-intelligence.

Everything points to the fact that these companies do not invest in training and are just trying to select a small number of people out of a large pool.

[zeroxfe]

> Your arguments clearly contradict each other

They don't. It's kinda disingenuous to pick phrases out of context to make a point.

But let me clarify anyway:

- smaller companies typically cannot afford to train, they need people on the ground right away.

- larger companies typically do train. Almost every large company I've worked with has dedicated training groups, programs, and staff.

- experience is more valuable than training, which almost all companies filter for

[coliveira]

These phrases came directly from the context of your arguments, so they are not out of context.

You first point proves what I'm saying. Your second point is doubtful, because large companies are the ones that spend the most time in useless interviewing. The training you're eluding to is tool training, which is essential in a place like Google where the programer has to spend most of his time working on closed technology.

Also, saying that companies filter for experience is not correct. Interviews at most tech companies (especially the large ones) is done to eliminate large numbers of people based on the solution of narrow-minded programming questions. These questions rarely correlate with experience, in fact most people that are just out of college can do so well or better in these questions than an experienced engineer.

[no_wave]

I don't think this is difficult, but I agree that it is rare. There is very little pressure encouraging people to become one of these programmers. I'm one of them, but it's difficult to actually leverage this into a higher salary unless you got involved with a larger company straight out of college. The interview process doesn't expose this, and unless you write a hit open-source application there isn't any way to prove it.

Instead, employers - even technical people who interview you - play buzzword bingo, indicating that you would have been better off spewing new frameworks into your codebase unnecessarily. The personal incentives for a programmer are completely misaligned with the actual interests of the business.

The approach that would incentivize this behavior would involve giving raises to people who write the sort of code you want to see, but instead raises often come from dazzling strangers who don't know the long-term consequences of your code (ie, getting a higher offer and asking for a raise).

[pm90]

There doesn't seem to be a way for a company to evaluate the "goodness" of your code in a meaningful way. And even if they did, you will NOT get a raise without asking for it. OTOH, there are those, like you mention, who will leverage other job offers to get a raise and such...so the only solution seems to be for those who write the good code to engage in similar tactics, regardless of the disdain they might have for them.

[mianos]

4 4 and 4. With no requirements, if you have an implementation of what is actually needed and it is not brittle you are all good. People who actually know what they are doing and don't write brittle code are more valuable than rock stars. I have seen too much code by rock stars based on the latest coolest frameworks and it has all been thrown out. Same for people who don't actually have enough skill and 'just' get the job done. One change and it all dies, turns to a pile of steaming poo or gets thrown out, only to be developed again using this week's cool new js framework. Less brittle code is smaller, simpler and involves as much deleting as adding.

[sopooneo]

Thank you for posting this, and am reading it very closely. However, I can't quite follow what you're saying with the first point, which is probably my fault. Would you mind putting it in other words?