I disagree. You're concerned about polluting the marketplace when, in fact, the marketplace is already polluted. There are already poor Rails programmers who work for $15/hour -- prob not in the US, but certainly elsewhere. It's not just programming, either. Every industry has the full gamut of high-performing people, and low-performing people.
Managers will continue to have to get better at what they do -- hiring good talent. If you need to hire enterprise sales people, and you picked up a high school kids because they sold clothes at Banana Republic senior year, you deserve what you get. So why would anyone fill an enterprise Rails engineer role with someone just because they took a high school Rails course?
If anything, a basic understanding of what programming is will help elevate the awareness of how complex it is to those managers. Programming is so much more than a craft.
Every programmer knows that feeling of being asked a tech support question. These things obviously have nothing to do with what programmers are great at. More importantly, being good at tech support says nothing about programming. But to most people, it's just "computer stuff."
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
I disagree that programming is "more than a craft". No, I think the craft analogy for programming is quite appropriate. In fact, I am of the opinion that much of the absolute and utter failure of so-called software engineering to deliver meaningful improvements in programmer productivity has been due to its repeated failed attempts to apply engineering discipline to what is essentially a craft problem. After all, we don't have "wood engineering" for carpenters and cabinetmakers. We don't have "fabric engineering" for tailors and dressmakers. Engineering principles are designed to solve known problems in a reliable and repeatable manner. We understand that cabinetmakers and dressmakers don't deal with the same problems (or necessarily even the same sort of problem) day in and day out. That's why we don't apply engineering principles to those positions. So why do we insist on applying engineering principles to programming?
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
Those are bad analogies. Like it or not, antivirus software is significantly more closely related to programming than, say, house painting is to design. Better analogies would have been, "Surgeons aren't asked questions about dermatology. Divorce lawyers aren't asked questions about tax law." Except, that's not true, is it? People do ask surgeons questions about their skin lesions, because, "Hey, a doctor's a doctor, right?" People do ask divorce lawyers tax law questions because "Hey, law is law, right?" And people will continue to ask programmers about anti-virus software because, hey, computers are computers, right?
Comments
I disagree. You're concerned about polluting the marketplace when, in fact, the marketplace is already polluted. There are already poor Rails programmers who work for $15/hour -- prob not in the US, but certainly elsewhere. It's not just programming, either. Every industry has the full gamut of high-performing people, and low-performing people.
Managers will continue to have to get better at what they do -- hiring good talent. If you need to hire enterprise sales people, and you picked up a high school kids because they sold clothes at Banana Republic senior year, you deserve what you get. So why would anyone fill an enterprise Rails engineer role with someone just because they took a high school Rails course?
If anything, a basic understanding of what programming is will help elevate the awareness of how complex it is to those managers. Programming is so much more than a craft.
Every programmer knows that feeling of being asked a tech support question. These things obviously have nothing to do with what programmers are great at. More importantly, being good at tech support says nothing about programming. But to most people, it's just "computer stuff."
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
I disagree that programming is "more than a craft". No, I think the craft analogy for programming is quite appropriate. In fact, I am of the opinion that much of the absolute and utter failure of so-called software engineering to deliver meaningful improvements in programmer productivity has been due to its repeated failed attempts to apply engineering discipline to what is essentially a craft problem. After all, we don't have "wood engineering" for carpenters and cabinetmakers. We don't have "fabric engineering" for tailors and dressmakers. Engineering principles are designed to solve known problems in a reliable and repeatable manner. We understand that cabinetmakers and dressmakers don't deal with the same problems (or necessarily even the same sort of problem) day in and day out. That's why we don't apply engineering principles to those positions. So why do we insist on applying engineering principles to programming?
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
Those are bad analogies. Like it or not, antivirus software is significantly more closely related to programming than, say, house painting is to design. Better analogies would have been, "Surgeons aren't asked questions about dermatology. Divorce lawyers aren't asked questions about tax law." Except, that's not true, is it? People do ask surgeons questions about their skin lesions, because, "Hey, a doctor's a doctor, right?" People do ask divorce lawyers tax law questions because "Hey, law is law, right?" And people will continue to ask programmers about anti-virus software because, hey, computers are computers, right?