Caveat: I am currently enrolled in a certain IT education system known for its ads featuring two teen actresses, one of which is associated with the so-called "jologs" and "bakya" crowd, with the other being too sugary-sweet and having a gratingly high-pitched voice. The opinions presented herein are my own and not my school's— besides, I honestly dislike the place, and am there on a mere formality (I need a damned diploma).
I've been in the trenches of the local development scene, working for this company for more than a year before finally quitting to concentrate on my studies, if one can call half paying attention at class concentrating. (By the way, they're looking for skilled C#/.NET and VB.NET/.NET developers, so go give 'em a call if you're looking for a job.) Although I can't say that what I've seen is representative of the local scene, I'd like to point out some things I've noticed during my brief stint as a paid working stiff, and I'd like to point out some things I've been noticing in my school as well.
First and foremost, there is a dearth of real talent in the local scene, and my current school's curriculum (at least in the branch I'm enrolled in) does not rectify things. By talent, I mean programmers who have enough skill to step away from the level of language syntax and be able to decompose and analyze problems. I've had experience enough of cow-orkers who didn't understand the first thing about loops, or about basic structural programming methods (i.e. moving common logic to functions, etc.) and whose code was liberally sprinkled with cut-and-paste programming— code snippets which could have better served by a common function or method, and have been maintenance nightmares. And my current classes don't give me the confidence in the next generation. The next batch of programmers will probably be trained to think only at the level of the language and not of the problem, and will be trained in cut-and-paste programming as well. To give you a good idea on why I see it that way, I'd like to give a brief walk-through of a small yet significant portion of the IT curriculum in my school.
Students are introduced to programming via several 3-unit courses, each with a lecture and hands-on lab component. However, I would like to stress this very important fact: students are taught about programming in C, but not ANSI C— Turbo C. That fact might not be a really big deal, but look at it this way: everything is taught in terms of a relatively low-level language (compared to languages such as Java, Python, Ruby, and even C#), and in ancient dialect of C to boot. And we aren't taught in terms of analyzing problems and deriving solutions. As an added bonus, we're taught flowcharting in the first lecture course, and maybe that should be a good thing. However, I've seen that it doesn't help. I've never seen a flowchart in my year working as a programmer, and I'd be willing to bet that most professionals don't even touch them. I believe in what Fred Brooks said in The Mythical Man-Month, "Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won't usually need your flow charts; they'll be obvious." Students should be taught about data structures and how to manipulate them, and C is not the best language to teach them that.
Although I'm willing to generalize this to other schools and educational institutions, I'm also willing to concede that not all schools are like this (it is a generalization, after all). However, these are probably exceptions to the rule.
The dearth is also exacerbated by the early influx of students into IT- and computer-related courses (similar to the recent influx into nursing courses) in the late 1990s up to somewhat recently. Most of these students have signed up for these courses because "the money is there," and although I don't begrudge them the opportunity, it has severely impacted the quality of education to the point of creating IT schools managed and treated as fastfood franchises
Second, programming work is hard, and projects are often put on unreasonable or crazy timetables, all for the bottom line. I do understand the need to budget and monitor "the bottom line", but throwing more monkeys into the works just won't do, as I've seen. What's worse is that, as is often the case, certain management-types think they know better and end up costing the project. Also, I've heard about projects where a more technically-superior solution was scrapped all for business politics, because certain clients or business partners were involved, even if it meant that in the long run it would have been a big win for the client both in terms of the project itself and the client's own bottom-line.
I've been in cases where several of us had to be pulled out of some projects because we had to support another project (being manned by, in my honest opinion, severely underqualified programmers). In those cases, it was a nightmare to simply be there— the code was of the aforementioned cut-and-paste quality, and was severely unmaintainable. In one case, I took the time to refactor some code into a method, taught the programmer how the method should be used, and how the code works and essentially told the programmer that it was a black box: if the programmer didn't understand it, it was ok, because he/she could just use it without having to understand it completely, just that it worked. Guess what? The programmer went on doing more cut-and-paste programming when I left
If the first can be solved, there is hope that the second will not happen or won't be as bad. I have hopes. But I still doubt it will happen in a batch or two of graduates. It's been said that there are too many graduates with too few jobs to put them in. As I see it, more importantly, there are too few qualified graduates. I've seen a lot of companies look for qualified programmers, and it's my opinion that the graduates are not yet up to snuff to what the industry really needs.
- As a point of full-disclosure, I am in fact enrolled in such a school.
- Understandably, it might have been a question of ego— my own ego vs. that programmer's ego. However, I wasn't the only guy who saw how bad it was. Even our technical manager for the project was appalled at the condition of the code, and was also telling the programmer to change the code. Oh well.
Previously: Keep Newbies Away From C