it's another one of the side effects of the fact that neither companies nor employees have any loyalty to each other these days. Why train someone if they can just take their knowledge somewhere else? Why should an employee have any loyalty to a company when so many are run by folks who see their employees as just another 'resource' to be slotted? One ot the things that I see that is really tragic is that companies put no value on institutional knowledge. I recently was eventually passwd over at a company that I used to work for because I was considered "too expensive", even though I had over 10 years worth of institutional knowledge of processes, procedures, and environments (I built a lot of the infrastructure). I was quite clear with them that they were going to have to pay some kind of premium for that knowledge if they wanted me back. The delta I was asking for wasn't really all that much, but to me the principle was important enough to push for it. They choked on it anyway, and I simply wasn't willing to accept their lowball offers. In the long run, I guess that's a good thing because I left the place for a reason, but it was disappointing to see that even with the huge turnover they have had in the past year, they just couldn't see any value in that kind of institutional knowledge.
You are quite correct, and in this issue both sides have legitimate reasons for not expecting the other side to act well. Employers have damaged the ability of employees to be loyal by utterly taking advantage of them: things like Google's "everything you make belongs to us" intellectual property ideas, or Dell's/IBM's/Sony's "you made patentable improvements worth millions... here's a watch." (Or in this economy the "you're lucky to have a job, work more [harder, unpaid overtime, etc] or you won't".) // On the other hand, Employees have damaged the ability of companies to be loyal to them by not joining in on the drive for success [i.e. they don't view the company's success as their own success]. (IMO, this is a problem of leadership: a good leader will draw those under him into the vision/goal.) Another thing that strains things on the employer side is that the employees don't always want to be in their "slot" -- another symptom of viewing people as cogs/components.
One of the things that I see that is really tragic is that companies put no value on institutional knowledge. I recently was eventually passed over at a company that I used to work for because I was considered "too expensive", even though I had over 10 years worth of institutional knowledge of processes, procedures, and environments (I built a lot of the infrastructure).
*nod* -- This is true; but then again, it seems like there's a lot of companies that don't value "non-standard"* knowledge. (In a recent job interview I was kinda talked down to because "they wanted someone with more knowledge/experience in Objects" [as in OOP] -- despite that most of the languages on my resume had OOP -- when what they [apparently] meant was that they wanted someone more experienced with the .NET framework and C#'s method of OOP.) The following is another example of this attitude:
PieterCasparzen: C is very sufficient for low-level programming and it's so ubiquitous that it's the only sensible choice.It assumes that because C is ubiquitous it's the reasonable choice, with the implicit exclusion of all other solutions. This is the same attitude that many CS grads have regarding extensibility [from OOP] -- "if you can't add new values/functionality then it's useless" -- which I was talking with BuckeyeTexan about earlier... and it precludes applying any other set of knowledge to help one address the problem. (One thing that C is notorious for is difficulty of optimization, particularly due to aliasing issues, IIRC -- these issues are not present in LISP or Ada [not sure about FORTH, just starting it] -- so by forcing C, a company/client is excluding whole realms of "non-standard" knowledge or solutions.)
It’s true that many employers want their programmers to work heads down in their cubicals. It’s equally true that many employees use employers to gain training and certs and then move on for higher salaries. It’s a cycle that feeds itself.
When I interview and hire programmers, I place a premium on loyalty and knowledge (demonstrable skill, not just experience or education.) If I see loyalty in someone who might be lacking in knowledge, I will often hire him over someone who has more knowledge because I can instill knowledge in a loyal programmer. I can teach him how to problem solve and write efficient code.
While the reverse takes more time and effort, it is possible to elicit loyalty from a knowledgeable programmer. It takes more than money and promotions. There is only so much money in the budget to hand out. Likewise, the company hierarchy allows only so many titles before there become too many chiefs and not enough indians.
The key to eliciting loyalty, speaking from my experience only, is to show it. Loyalty includes respect. Include your programmers in the decision making process. Seek their opinions, value their advice, acknowledge their contributions and successes, explain your reasoning to them when you must make an unpopular decision, let them know up front about project contraints that you cannot change, fight for them on important technology decisions even if you know you can’t win, respect their personal time, invite them to share ideas and concerns with you, listen to and consider their ideas and concerns. I could write much more, but it all comes down to loyalty and respect. If they feel appreciated and respected, they will return it.
I’m only 43, but in my 22 years in IT, the most important thing I’ve learned is that there is always something to be learned from your superiors, peers, and subordinates. As an ignorant n00b, I spent a lot of time on the floor of my co-workers’ offices asking questions and soaking up their experiences. It has served me well.