No, I believe learning a skill is an investment, which is why I take my time (sometimes years) and study for a long time before I even put pen to paper.
My latest learning exercise was postgresql. I've done a proper engineering evaluation on it which has taken a whole year, but i tell you, i know it inside out now. I am confident i can handle any edge case or problem. Can your 10 week old developers even handle a simple edge case failure efficiently? That's where the skills are important or there is a roadblock every 30 minutes in this industry.
I agree, to become an expert takes time (some say 10,000 hours). We don't claim to train people to be experts. Our students do not graduate knowing the solution to every edge case. They graduate with a strong foundation and confidence. They spend a lot of time learning how to learn - how to grow as a developer. The journey doesn't end with the end of the program. For many of our graduates, the end of the program is just the beginning (one graduate just wrote about this today: http://www.mercedescoyle.com/last-day-of-hackbright-first-da...). Our goal is to provide them with the skills they need to start a career in software development. So far, the majority of our graduates from the first batch (8 out of 8 seeking employment) have already started their new careers in software development.
In my case, a simplified view: reading the documentation, building a list of scenarios based on proposed functions and associated risks, testing each one and documenting it in a concise manor. Then building something serious, testing it, breaking it predictably and unpredictably and reworking conclusions from above. Also doing research on best practices, bad practices, performance reducing functions and hints/tips, integration paths etc.
When I reliably can answer most stackoverflow questions on the subject, I am then confident that I know what I'm doing and then will sell my skills.
I think it would be insane for someone with little or no experience in the field to devote years to a specific skill (say, complete mastery of Postgres), before working on problems in the real world.
Even in areas where failure has high costs (say, medicine, or war), you don't go off and try to master a specific skill before doing anything -- you master some basic skills, practice using those (in increasingly realistic environments), then learn more advanced skills. For one thing, you don't even know beforehand where you may have particular strength, and you also don't know what opportunities will arise.
Even a junior developer with basic knowledge can make meaningful (and thus compensated) contributions during the learning process. I'd rather spend 10 weeks or 6 months or whatever building some skills, then get a job and learn while being paid, vs. spending my whole life in isolation trying to become a zen master and write the one perfect line of code.
For "deep" areas such as mathematics, medicine, and theoretical computer science one needs an extensive theoretical background before being able to advance the field. A depth-first approach may be the only way of learning a useful subset. This may also apply to something like "database theory in general".
However for "product skills" (such as learning a specific database package or API) there's something to be said for a breadth-first approach. Especially nowadays, where today's hot skill can be neigh useless tomorrow. If you spend years only perfecting some skill you may be too late to profit from it! Also as the field is moving so fast, by the time you learned the PostgresSQL manual from beginning to end, there has been a new major release that invalidates many of the best practices that you spent so much time learning...
You don't even need to be able to "advance the field" to contribute meaningfully.
Take medicine. It's possible to teach someone some specific skills quite quickly (I probably have 200 hours of first aid training, essentially much of EMT-B plus lots of specific training in trauma, specifically dealing with massive hemorrhage from traumatic amputations, dealing with GSW, tension pneumothorax, etc., and various diving related issues, and some extremely basic radiology knowledge to assist technicians and rads in debugging a PACS.) With that level of training, or even 4 hours of really basic first aid training, you know enough to help. I won't be writing any dissertations on the best way to deal with a specific kind of trauma, but I can do a pretty good job of stopping bleeding in most cases. You're not going to have a top-flight trauma surgeon in every car. The 200-hour tech isn't going to be operating on his own (ideally), but can be a part of the solution. For some fields, like datacenter operations, experience is worth more than formal training, too.
Plus, there actually are a surprising number of cases where a relative newcomer to a field actually does end up advancing the theoretical limits. Maybe it's due to not knowing and accepting the limits of the field at the time, or maybe it's because that moderately passable junior programmer also happens to be a world-class expert in some other domain which just happens to be similar to the problem at hand, but it's not all that uncommon.
I'd still prefer any pending neurosurgery on me be done by someone with a good amount of experience, credentialing, and expertise, but it's a rare Django app which requires that level of caution :)
Yes, fairly simple skills. I would concur with my grandparent that it is impossible to master a complex skill set in just a short amount of time. That's not to say that it is useless. On the contrary: it gives your graduates a basis companies can work with to turn them into productive programmers for the company. Especially because your students will have a solid background in some other field (?). That can make them valuable employees if they are able to take the hurdle of working as a underpaid entry-level programmer for a while.
