>> I could do it, if I had "X years of experience in the field"... but that illustrates another problem: companies want workers "cookie-cutter made" for the position and are unwilling to expend time/effort in training. (This is regardless of programming language and even a quality of the "entry-level positions.")
>
> it's another one of the side effects of the fact that neither companies nor employees have any loyalty to each other these days. 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.)
My 2 pennies...
re: Employee/employer, work for hire:
www.copyright.gov/circs/circ09.pdf
If you owned a business and hired me to write a complete sofware package for you, and then I went out and competed against you with well-funded backers, by bringing all the code I wrote to them, that would be the other side of copyright (ouch!).
Of course, if I wrote something on my own time that was NOT competitive with your product, you'd probably rightly feel that I had every right to do so, and I agree.
IMHO, for software developers who are key employees, whose work product value gets into the tens and hundreds of millions, having equity in the firm is the best route for all concerned, as it can much farther than plain salary and bonus on aligning goals and creating a shared risk/reward situation.
re: Narrow experience criteria
I'd take a newbie programmer who had never seen the language I needed them to work in - if I thought they exhibited the qualities of a future excellent programmer - over a person with exactly the right experience who was a dolt. I'd also take an "excellent programmer", (right ethic, not lazy, good insight, etc.) who had worked as a programmer for 40 years in some ancient, irrelevant language over, once again, the dolt whose skills happen to be a "perfect fit" to the job. The person's resume does not write the code, the person does.
re: the sufficiency of C, versus Ada rules !
The "language wars" ended quite a few years ago. Languages are what they are. C is a widely-known language, which makes it easier - and cheaper - to find C programmers than many other languages. There are other popular languages as well, i.e., the markup languages, web-based scripting languages, the legacy business languages, SQL, etc. They are not perfect, but they are widely known. Most of the programming that is done in the world is simple garden-variety business apps, websites, etc., where performance does not need to be measured in clock cycles and for most businesses it's just as important to be able to find programmers who are at least somewhat familiar with the languages they use as it is to have a language feature set that is optimal. I have a list of complaints about languages, including C, as long as your arm, but that's neither here nor there. I just try to avoid problems as best I can and make code bug free and as elegant as possible.
As far as C being "sufficient", there are bazillion unix systems all over the world (including the one I'm looking at) and most of the systems programs running on them are written in C. So, while C may not be the Holy Grail of computing, systems programs have long been successfully written in C. On the other hand, the fly-by-wire system of the Beoing 777 is written in Ada; the decision makers on that project chose Ada, and hey - more power to them.
To each their own. Well, until I write my language. It will be the ultimate language, and everyone will have to write all their programs in it. How do I write /sarc in Ada ?