Programming is one of the few fields left where measures of productivity, utility, and value have not yet been fully usurped by the more arbitrary measures of popularity and seniority. You can judge a programmer by the quality and quantity of the product he/she produces, so you don't need to do it by arbitrary social rank.
In other professions where an individual's marginal product of labor is much more difficult to measure or is averaged together with that of everyone else in the organization, ranking people based on these extraneous social factors becomes necessary, but with programmers it is unnecessary and even harmful because the incentive structure becomes biased toward factors other than programming productivity.
1. Anyone can write code. 14 years old? No school? Fine. Doesn't matter. If it's good, people will voluntarily use it. Absolutely anyone can write code, and if it's good, people will use and pay for it.
2. No manager can make me read your code as a requirement of my job unless you've proven (by certification) yourself to be at a level where less than 5% of professional programmers currently are.
This would work for me.
If you're concerned about filtering out people who write ugly, hard-to-maintain code, how about more portfolio-based hiring? Want a programming job? Show me an impressive piece of source code you've written, and explain what design patterns you employed and how it is an elegant and maintainable solution to the problem it was written to solve.
I don't see anything wrong with companies that want to have bad code. They'll probably suffer for it, but that's not your or my problem.
What I'd like is a world where as few people as possible deal with bad code, and no one is stuck with no other options, because bad code tends to beget more bad code, and because it's wasting time that could be spent writing a bunch of new good code.
The evil of bad code isn't that unskillful code exists. The problem is that there are plenty of managers out there who don't know any better and will insist that people use it, and who never learned the processes that lead to good code (most important: keep program size small.)
Also, my experience is that over 90% of corporate code is absolutely terrible-- unusably, mind-stoppingly awful. Rolling the dice doesn't have the best odds.
Which is kind of funny because those are the businesses who rely most heavily on vetting done through colleges and universities. They have, on paper, the very best programers available. I guess that goes to show how poorly credentialing actually works in the real world.
I think the pain of what we do in the software industry, from the low respect to the bad code, goes back to the fact that our work is extremely difficult to measure, although the importance of quality could not be higher. Corporations have traditionally responded with a 3-4 year bug-fixing evaluative spell, but that's now leading to adverse selection because people like us (as you noted) won't stand for it.
You mean if you were hired by Facebook in '04 you'd have refused to read their source code?
To answer more directly, I'm not good at picking startups (0 for 2) and I doubt I would have foreseen Facebook's success. I didn't, although maybe if I knew the company better I'd have been more of a believer. My general answer is: No, I wouldn't take a startup job where the bulk of my time would be spent reading other peoples' code, unless the code quality were extremely high.
Professional accreditation and training may well be wasted on social web app coders, but I sure wouldn't want to fly in an airplane that was controlled by a weekend hacking project written by someone who just learned their first programming language the day before...
Bullshit. It is precisely because programming is not straitjacketed in such medieval rigidities that it can create so much value these days. Forcing today's youngsters, who may be like Gates, Zuckerberg or the Collison brothers, into an X-years long "apprenticeship" program before anyone takes their code seriously is a spectacularly bad idea.