You're kinda right. I started programming on BBC Micros when I was 9, and there's really no way around the fact that the only way you can know as much as I do

You're kinda right. I started programming on BBC Micros when I was 9, and there's really no way around the fact that the only way you can know as much as I do about programming at my age is by having that kind of experience. However, software is an industry. We need more people, and we can't travel back in time to teach the 10-year-olds of 2004 how to code. It's perverse, but part of the reason for the shitty nature of most software projects is the imbalance between demand for good software and supply of people capable of providing it. This is what leads to over-work, death-marches, time pressure and the attempt to prevent programmers getting involved in "distractions" like talking to customers, figuring out what the software should really be doing and so on. Currently, the best way for employers to maximise the amount of software they produce is to get their best coders to focus on writing code, stripping away any other aspect of the job. Management, analysis, design, testing, all of these get shifted on to non-technical (read: easier/cheaper to hire) people who then fuck it up because they don't know anything about how software works, or at least how the software we need right now should work. Sure, it can be a good thing for developers that demand for their services is so much higher than the supply, but the long-term effects really aren't good. I'd rather work in a world where the obsessive programming-before-they-could-legally-drink people get to be lead developers, but the rest of the team can also program decently. And that means training the latecomers properly. (I appreciate that some of this may seem condescending to the latecomers - in all honesty, I think many people have the potential to be excellent developers given time and encouragement, but I'm trying to stick within the premise of the parent comment).