Joel Spolsky, Snake-Oil Salesman
If there is a lecturer in TCD’s CS department that doesn’t know of the problems and issues Joel just raised in his Capstone Projects post, they’re a rare bird indeed. But what Joel hasn’t mentioned — and what those lecturers can tell you because they’ve been debating it for decades, writing papers on it, holding conferences and have published peer-reviewed journals on the topic, as opposed to Joel’s one blog post — are that there are very specific and very good reasons why CS and CEng undergraduate courses don’t get to cover all the industry tools Joel uses.
To give a brief and inexhaustive list:
- Undergraduate courses in CS and CEng are not there to teach industrial tools, but basic principles, ususally ab initio to students just out of secondary school (high school for the US equivalent courses). This has implications:
- Everyone must work solo. You can learn to work in teams later (and certainly there are team projects all through the four years of the CS and CEng courses in TCD) but until you have a grasp of the fundamentals, team projects are worse than useless as they mask the student’s problems with the basics.
- No student is expected to graduate and be able the next day to walk into an industrial role without supervision or training, and no student has ever been expected to do that in Engineering since the first undergraduate course started in TCD in 1841. That’s why we have mentoring, why we have CPD processes, why we have Chartered Engineer (or Professional Engineer) titles granted by postgraduate programmes, it’s why there’s an entire structure there that’s been built up over hundreds of years of experience. Experience that we have paid for with lives in many cases.
- Everyone needs to work on the “interesting 10%” and leave the boilerplate code for later. If we had ten years for an undergrad degree, you can be very sure it’d be covered in detail, but we don’t. And four years only sounds like a long time because you’ve never taught such a course before, and are missing details like the coverage of the entire field of Computer Science being necessary in that four years.
- Undergraduate courses lose their technical currency in something like five years on average (obviously different sectors age at different rates – web programming has a very fast cycle, embedded systems a very slow one). If we started students off on the latest fad language in year one, they’d graduate with an obsolete skill in year four. So instead we’re better serving students by choosing languages which allow the lessons to be taught clearly, or which are at least well-established and unlikly to vanish into obsolesence before they can graduate. That’s why moving basic courses to Erlang or Haskell is probably a poor idea.
- There is no such thing as the agreed best practise in industrial work. Some favour Agile methods, some regard them as toxic. What works in one sector of the industry will leave your business uncompetitive in another. What is a minor issue in one application will actually kill people in other applications. And different industry sectors have different governing legislation. So if Industry, that much-vaunted crucible where only the best practices survive the trial of the invisible hand of the free market, cannot come up with a single code of practice, what exactly would Joel have the universities teach?
- There is a duty of care to the students. There are many evangelicalists out there who promote one form of Agile methodology over another, who promote unit testing, who promote pair programming, who promote Scrum, and so forth. These methodolgies are without doubt all very interesting – but they’re also unproven. If I’d started teaching students in 2005 with whatever the Agile Methodology De Jour was, by the time they graduated in 2009, that methodology had a fairly low probability of being unaltered, let alone the dominant industry methodology. That’s four years of a student’s life, committed to a methodology based solely on the hype its originators could muster together. That’s not just poor teaching and an invitation for justified lawsuits, it’s downright unethical and wrong.
Normally in an article (or blog post in this case) like Joel’s, the last few paragraphs are where traditionally the author is meant to show a solution to an elucidated problem. Joel has highlighted a perceived lack of experience with current industrial tools and practices amongst college students (a faulty perception, but nonetheless). He’s pointed out a root cause (poor time management) which is fair enough – it’s not the sole cause, it’s not even a primary one in most professional evaluations, but it’s a valid contributing factor. So now’s the time for the solution, yes?
But here is where Joel merely says “have the students use my product to track their usage of an unproven methodology”. No indications as to how we would approach the problem of explaining the relevant industrial methods, or how we’d select the specific one we’d teach, or why we should select it, or where it’s best applied and where it’s best avoided, what it’s strengths and weaknesses are, and so forth — just pure old-fashioned, ladies-and-gentlemen-this-product-cures-all-that-ails-ya, snake oil salesmanship.
Our students may indeed have poor time management skills on long timescales (a failing which comp.risks and The Daily WTF and IT Project Failures have been pointing out in industrial programmers for many years now, which to me indicates that industry does not necessarily have much to teach here). At least when Limoncelli wrote Time Management for Systems Administrators he was putting forward a set of skills that had proven to work for him in the field, and he was trying to pass on lessons learnt the hard way. I might not use the book as a college textbook (though I do use it myself personally), but I can at least respect his intent there. But Joels solution isn’t to teach better skills; it’s to sell his software tool to those students. Let’s throw ethics out the window for a moment and say we do just that. Now what? I can sell you the best chisel in all creation Joel, but I can’t make you into Michaelangelo by doing so – I can just take some of your money and give you a tool you don’t know how to use in return.
Frankly, when I teach the CS7004 students how to use VCS and ticket tracking, it won’t be using FogBugz or any other proprietary system, it’ll be using systems they can explore without having to pay fees for, like Mercurial and Trac. And if afterwards they need to go learn Git or Jira, they’ll know the fundamentals and it’ll take them less than a few hours to make the transition. That is what university courses are for, to teach the fundamentals so that the students can pick up specific skills far more rapidly and evaluate tools according to their proposed use. Not to act as a captive and uncynical market for proprietary software tools.
And even after that, in the final paragraph, he admits himself that it won’t work – that you still require a manager to come in and do time management even in industry. That Scrum won’t teach you time management. That the only difference between college students and industrial programmers is that the latter have time management enforced upon them by a manager – in which case, were that the truth (and it’s not a universal truth, and I’ve witnessed that first-hand), then there would be no problem with college students whatsoever.
Gah. Well, perhaps it’s time I should exercise some time management techniques that I should have used years ago — and simply stop reading Joel.
@Charlie: “‘Struth! We spoken, sir! Spolsky irritates like a glass shard in my shoe.”
Were you just trying to channel Poe or something ?? I know Poe, and you, Sir, are no Poe. 🙂
Err this is meant for the commenter below: There’s nothing wrong with using Perl for web apps, take a look at Catalyst – http://www.catalystframework.org/.
From a different article from Joel’s website – http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
//But what about the CS mission of CS departments? They’re not vocational schools! It shouldn’t be their job to train people to work in industry. That’s for community colleges and government retraining programs for displaced workers, they will tell you. They’re supposed to be giving students the fundamental tools to live their lives, not preparing them for their first weeks on the job. Right?
Still. CS is proofs (recursion), algorithms (recursion), languages (lambda calculus), operating systems (pointers), compilers (lambda calculus) — and so the bottom line is that a JavaSchool that won’t teach C and won’t teach Scheme is not really teaching computer science, either. As useless as the concept of function currying may be to the real world, it’s obviously a prereq for CS grad school. I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs. Oh wait. Never mind. Maybe I do understand.
Actually if you go back and research the discussion that took place in academia during the Great Java Shift, you’ll notice that the biggest concern was whether Java was simple enough to use as a teaching language.
//
One core problem is that people major in Computer Science but then start a career in Software Engineering, which is a different discipline.
While I agree with the jist of the post, I’m unsure why you choose to label Erlang and Haskell (implicitly) as likely to “vanish into obsolesence”. I would have expected almost the opposite conclusion, given your line of argument!
A common argument against using these languages in a CS education is that they will put students off because they don’t look good on your resume. This has now changed a bit, but may still hold some truth.
The thing that makes both languages good candidates for teaching is that they expose some ideas very clearly for educational purposes. Erlang shines for message-passing concurrency, and is quickly learned. I first came across it at KTH. After 4 lectures, we completed a lab where we wrote a control loop for a phone switch. This was in 1992, and Erlang was likely used by less than 100 people world-wide, but I was elated! It was a superb illustration of the concepts.
During the core concurrency class, we studied Concurrent Euclid (now dead), Occam (dead) and Ada (indestructible, but not much alive). This was fine. The same course picked up Erlang later, and I’ve seen from student reviews that this was much appreciated. The same seems to be true in just about all places where Erlang is used in the curriculum. Seeing as it’s on an exponential growth curve, it doesn’t seem to be vanishing into obsolesence soon.
I haven’t experienced Haskell as a teaching language either as a student or teacher, but I can imagine that it is outstanding for teaching some important concepts in functional programming. Having attended POPL last year, it was obvious that Haskell is THE language of choice for most discerning language theorists, as many of the new language concepts presented at POPL were prototyped in Haskell. It seems like talented undergrads _should_ be exposed to Haskell as early as possible.
One problem with having Haskell in the core curriculum might be that some programmers do not seem capable of learning how to write non-trivial programs in Haskell. It really forces you to think about abstractions in earnest. Having fought lots of people who are convinced that ‘modeling’ means drawing pictures in UML notation, I think there are some extremely important lessons to learn.
Not that you need to use Haskell specifically – the old SICP course using LISP goes a long way… but it really made me curious to learn what languages you /do/ use in your teaching?
I’m not sure they’re likely to vanish into obsolescence Ulf – it’s just that I’m not sure they won’t vanish. Where I’m looking at it from, the contrast is more along the lines of C vs Haskell, rather than of an evaluation of Haskell in isolation. Actually, Haskell is used in a maths course or two from what I remember from talking to people in the maths department a few years back – but for computer engineering, it’s simply not as valuable a skill to know compared to C. From what I’ve heard from those who’ve worked in it, it’s got a large number of things in its favour when considered in isolation.
> At least when Limoncelli wrote Time Management for Systems
> Administrators he was putting forward a set of skills that had
> proven to work for him in the field, and he was trying to pass
> on lessons learnt the hard way.
I made a conscious decision to write what worked for me and people near me rather than write a book about the theory of time management and productivity. Before writing the book I did some research and found that people do not tolerate more than a certain amount of theory in self-help books. A little bit is motivational, too much is a turn-off. On the other hand, research finds that geeks tend to be motivated by knowing how the internals of something work. That’s an argument for including more theory. I had to strike a balance.
I don’t recommend Time Management for System Administrators (TM4SA) as a textbook. It is a self-help book. People will only benefit from a self-help book if they feel they have a problem. The 80% of your class that doesn’t feel they have a problem would hate the professor for making them read it. Oddly enough I had terrible time management skills when I was in college. My low GPA is proof! If only I had TM4SA then! (Go figure out that time paradox!)
On the other hand, I do promote The Practice of System and Network Administration as a text book. It was written with colleges classes in mind (senior undergraduate and masters programs). As proof, each chapter ends with questions, something one generally finds in text books. The questions are designed to help the student review the material with a few “soul searching” questions mixed in here and there. The latter are excellent for term-paper ideas.
I would like to respond to some of the things you said:
> Undergraduate courses in CS and CEng are not there to
> teach industrial tools, but basic principles”
I agree… but don’t go too far. The use of industrial tools, when used, should be as a demonstration of the principles being taught, not to gain some kind of certification that they know how to use the tool. Banning such tools would be going too far. We all know there are students that are “visual learners”, “audio learners” and “kinesthetic” learners. Using the tools in a real environment is where the kinesthetic learners will benefit.
When I took my undergraduate class on software engineering methodology, I felt it was useless because I couldn’t see the point of most of what I was being taught. Most of my programming had been done solo or on a small team. I could not take seriously the problems that were being “fixed” by the software methodologies discussed in our lectures. What would have solved this problem? To put me in an environment where we had a large enough team that things started to break down and we needed GIT, Bugzilla, and Tinderbox.
However, that was in a day when basic tools like source code control, bug tracking, and automated testing were uncommon. Today’s students get more exposure to those things via exposure to Open Source projects than I got in my entire college career.
What about the students that aren’t exposed to how open source projects work? My guess is that that is the majority of college students. The superstars get exposure but not the majority.
Tom
Well, right first off the bat Tom, thanks for writing both those books, I’ve found both to be exceptionally useful and Time Management has a permanent place on my nightstand as a result.
When I mentioned industrial tools there though, I was more thinking along the lines of not teaching VCS usage by training the students to use some specific product like SourceSafe, as opposed to teaching them the whole range of VCS solutions from RCS on forwards, as well as the strengths and weaknesses of each, and how and where to use them. Or, to put it another way, we teach students to program using C and C++, not with Visual Studio.
We can’t really make participation in open source projects mandatory. If we can’t have some sort of control over whether or not patches are accepted or whatever, we can’t really make a student’s grades dependant on patches being accepted; and if we based it off patch submission, we’d probably swamp some poor project somewhere with a batch of suspiciously similar low-end patches to accompany the two or three genius-level ones we get in each class.
What we can do (and do regularly) is to have projects like building entries to the IEEE micromouse or Robot Sumo or Robocup Soccer tournaments; to have a final year project that runs for several months and has to be above a set standard for complexity (it’s not unknown for these projects to be sufficiently advanced to have academic papers published about them, one was about mine); and to have a research group run by undergraduates, for undergraduate projects (the now sadly defunct SCRG, which produced microkernel OS work, compilers, and dozens of other interesting projects all through the 1980s and 1990s in TCD’s CS Department, and which I really think we ought to be restoring today).
For example, the Introduction to Embedded Systems (CS7004) course’s final labs will be building one on the other to get up to a final project where an ARM7TDMI board will be doing target tracking and interception using a USB missile launcher toy equipped with a webcam. That’s going to require ticket tracking, documentation and VCS usage, and it’s all part of a structured run at the final problem. Engineering and CS all have similar team projects, from bridge building, to building electric carts to carry beverages, to building a 68008-based system from a handful of chips and wire, a wirewrap tool and a lot of swearing at 2am in the lab 🙂
I think that this post sucked less than most of his recent production. I agree that the mention to FogBugz is a cheap ad, very like his usual style.
I will keep on reading Joel though, he sometimes have really thought provoking ideas.
[…] Joel Spolsky, Snake-Oil Salesman If there is a lecturer in TCD’s CS department that doesn’t know of the problems and issues Joel just raised […] […]
This is an easy one, Joel is an employer and he is talking about the education and experience he would like his future employees to have and basing it on his own experience. He sees a problem that he would like to have fixed, rather than talk about how impossible it is to fix come up with alternatives.
Joel is also a businessman, he is offering his work to us for free in his blog – we are consuming his product for free and if he makes a mention of his own product then Good For Him. Shame on you, stop being such a something for nothing bunch of people.
Firstly, Joel is being an employer who doesn’t feel he has a duty of care to the career of his employees if he’s recommending that they be trained using his products and his methodology so they can slot into his company more easily. What about the other hundred or so students in whatever course takes his advice whom he does not hire?
Secondly, universities have, as I’ve said repeatedly, a duty of care to the student to not follow advice like Joel’s. They have to act in the best interest of the student, not Joel.
Lastly, Joel’s the one looking for something for nothing here. He’s asking that we cripple the careers of CS students so he doesn’t have to do the kind of on-the-job training every other employer takes as read, and that we’d get them all locked into using his products. And why would we do that? What would we get back in return? Well, nothing. It’s a case of Joel wins, everyone else loses.
Good for him my hat!
Mark, you obviously care a great deal about the students and about the quality of their education.
Watching my brother who is a math professor, I have an idea how much pressure there is and how much caring goes into your craft. I know you probably worry about making certain that your students are as well rounded and as well prepared as possible.
I’m just saying that it might be important to those students for you to weigh employer points of view (no, not just Joel’s) as heavily as you weigh peer points of view when developing the curriculum. (And I’m not saying you don’t I just didn’t see that on your list at the top).
“He’s asking that we cripple the careers of CS students [and] get them all locked into using his products.”
Good grief. No wonder students can’t do anything useful when they graduate. You can’t teach them any real software because they’d be “locked in”.
(Yeah, yeah, I know, that isn’t what you meant. I’m supposed to read you charitably to the same degree that you read Spolsky uncharitably because you’re an academic and he’s a businessman. Sheesh.)
Another core problem is that many universities still don’t have different CS and SE courses, and guidance counselors and industry still believe that CS is the degree required when hiring programmers. This problem is academia’s doing, and they need to fix it.
WTF Mark? Have you not read anything Joel has written about building an environment conducive to development and developers? Drop the strawman BS and admit that Joel was advocating the use of “a bug tracker” and “a VCS” JUST like you are, but offered the services of his company _gratis_ because he has the resources to make such an offer.
Pick up a newspaper or phone an employment agent, ask about programming jobs; ask what qualification is expected. The answer is invariably “Computer Science”. Now pick a student who will enter a CS course at the start of next year, ask what (s)he expects to do with the qualification. The answer is invariably “write software” (or some variant thereof).
The TCD CS course page says “If you can see yourself in a leading team of software developers in computer games, internet software or medical technologies or as a researcher developing innovative technology that will change the way we use computers, then Computer science at Trinity may be for you.” CS departments PERSIST in claiming that they are producing graduates that are competent to enter the workforce, but the very clear response from industry is that CS graduates are NOT competent and require a huge amount of on-the-job training. My company hires EE grads in preference to CS for software development because they are more productive in just about all spheres of the development process, and better equipped to understand and adapt to real-world problems.
Any course that claims that its graduates can become “software developers” needs to include a study of development methodology (note: study, not advocate a particular methodology) and to demonstrate competence in applying at least one methodology (it doesn’t matter which one, what matters is the ability to translate the theory into practice). The methodology needs to include requirements gathering, specification, development, and testing _in some form_. It needs to introduce and apply the concepts of source code management during development and testing. It needs to include real-world considerations like debugging, and how you will structure your interface to get enough detail from a support call to debug the problem. A graduate who is unable to walk into a CMMI level 0 shop, recognise the problems, and know how to go about finding solutions, is NOT adequately trained.
That’s not what he’s talking about Twylite. Perhaps you should read more critically. He’s offering lockin to his product on a badly thought out notion that contradicts large amounts of work into how to teach CS and what to teach on the courses. Nothing more.
As to the TCD CS course blurb, don’t forget that TCD’s CS course produced the people who went on directly from TCD (without industrial experience) to found Havok, Iona and various companies in the medical field. So it’s accurate, if not particularly expansive (but then, what sales brochure ever gets the chance to answer every question? That’s what the open days are for).
As to your specifications for a CS course, you and I will differ there. I’ve worked in enough places, and done enough hiring interviews (and it doesn’t take that many by the way), to know that your specification list is not fit for purpose for a CS course which has to equip graduates to go for positions in not merely your company, but the tens of thousands of others out there.
For example, everyone here has been talking about Agile methodologies, but not every company uses them or feels they are appropriate. If Agile isn’t another string to your bow, but the only string, then your college course hasn’t prepared you sufficiently.
That’s a nice angle CB, but I don’t need you to read layers of meaning into what I’ve written to understand what I’m saying. I just need you to actually read what I’ve written. See the comment above.
Hi Mark,
In a 14 paragraph article, Joel takes the second to last paragraph to suggest a specific methodology (Scrum) and to offer his product (FogBugz) as a tool that can be used for bug tracking and reviews. The other 13 paragraphs are about the problem industry faces in hiring new graduates: they have no practical or conceptual experience with ANY version control, bug tracking, scheduling, etc.
You have chosen to read this as “you need to teach Mercurial and FogBugz because its the stuff I used and sell”. I read it as “you need to teach about this stuff, and if you need an actual tool to work with then I’ll offer my company’s resources”. Yes, he is marketing and yes he stands to gain. No he did NOT say that specifically his suggestions should be used to the exclusion of others.
> As to your specifications for a CS course, you and I will differ there.
I thought it evident that by saying “include a study of development methodology” I was not specifying an entire CS curriculum, so much as indicating some subset of the minimum requirements of a portion of a curriculum that claims to train software developers. If you are not including the aspects I mentioned then you are not providing even skin-deep coverage of the SWEBOK or of software development practice. i.e. you are training scientists not developers, and the course should not be claiming to train developers.
> If Agile isn’t another string to your bow, but the only string, then your college course hasn’t prepared you
Maybe I wasn’t clear (I thought I was) that the concept of “methodology” should be studied along with a number of methodologies as cases; but no specific one advocated. Right now a graduate “software developer” should be able to explain what a software development methodology is, discuss the pros and cons of following a methodology, identify the typical make-up of a methodology, name a couple of common methodologies (e.g. Waterfall, Iterative/Incremental, Agile) and describe the salient features of each, and have the skills & knowledge to select between two methodologies for a given scenario (and defend the selection).
Developers on a Scrum team do not need a manager to come in and “enforce time management” upon them. If that’s the case then you have a very broken Scrum process. The team should be self-directing and self-organizing. The *team* should be managing their time, let members police one another. You have a daily stand-up so it’s very transparent and clear who’s doing what, who needs help, who’s slacking, etc.
Managers need to find their role in Agile as a servant leader. The era of industrial revolution style management, where folks are treated like they’re on an assembly line, just doesn’t work — definitely not with Agile. Managers should focus on helping their teams by removing obstacles to work, coaching, and actually providing leadership. Remember a manager measures, but a leader inspires.
Twylite, in a 14 paragraph article, Joel spent 12 paragraphs building up a problem. One that doesn’t really exist (and he acknowledges as much in his last paragraph). And if you’d actually read what I wrote, you might have noticed I didn’t latch onto the last two paragraphs, but the first 12, because they were wrong (and rather substantially wrong, because smarter people than you, me or Joel have been working on this problem in large numbers for decades now).
We’re in agreement on how CS graduates should be taught methodologies rather than just one. But you seem to think that CS graduates can’t be developers – and you’re wrong. You need to stop thinking of CS graduates as bricklayers and start thinking of them as engineers, and by that I mean that you have to keep in mind the fact that engineers never stop learning and qualifying throughout their professional lives. The undergraduate course is a foundation as a result of that – it is not the finished article, because there’s no such thing with developers. It’s our responsibility to ensure that foundation is solid, not to produce some cubicle farm drone able to code in whatever industry specific methodology fad is in vogue at the time.
You need to tell Joel that Nicholas…
That’s from his final paragraph.
Hi Mark,
> But you seem to think that CS graduates can’t be developers – and you’re wrong. You need to stop thinking of CS graduates as bricklayers and start thinking of them as engineers
CS graduates are NOT engineers. That’s the whole problem. Industry expects them to be engineers. Academia is saying “sure, they’re engineers”. The graduates may be good scientists, they may have extensive competence in computation, but they haven’t the breadth of knowledge _in the field of engineering_ to be engineers (without additional training).
Engineering: “The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.”
Or perhaps the IEEE definition: “Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software”.
The core focus of CS curricula is on theory and the development of theory; the core focus of engineering is on the application of theory in a practical environment.
Contrast the body of knowledge for Civil Engineering (http://www.asce.org/professional/educ/ , your national BOK may be slightly different) against your CS curriculum (looking only at the portions meant to be fulfilled by a bachelor’s degree). Where are the CS modules on risk, project management, and Professional skills (1/3 of the BOK!)? Where is the CS equivalent of materials science, or a study of contemporary issues _in software engineering_ (as opposed to open problems in computer science)?
> The undergraduate course is a foundation as a result of that – it is not the finished article, because there’s no such thing with developers. It’s our responsibility to ensure that foundation is solid, not to produce some cubicle farm drone able to code in whatever industry specific methodology fad is in vogue at the time.
Pick up a textbook on SE (Sommerville’s “Software Engineering” 6th Ed, for example). Does a typical CS undergrad course cover even a quarter of this book? A course that provides a foundation for a software _engineer_ should be covering most of the material in such a textbook (perhaps some only in a forth year of study). A course that trains engineers should be testing for competency in _application_ of this knowledge (application per Bloom’s Taxonomy, as expected in other engineering disciplines). Are you managing to test applied knowledge without concrete cases or tools?
You may be providing an excellent foundation for scientists. Some of those scientists may even pick up engineering principles and become competent developers. But you will still not be training students to be engineers.
Twylite, you’re arguing with an engineer about what an engineer is and isn’t.
And frankly, you’re wrong.
And it’s not like there’s no precedent for where we are now – you’re looking at Civil Engineering as a model because it looks like the best one. Well, there’s a reason for that. It is the oldest branch of the profession. It is in effect, stable. It has had time to build up its procedures and practices, to codify its body of knowledge and thrash out a nearly standard syllabus. Software engineering is an order or two (or three) of magnitude younger (depending on what you accept as the origins of civil engineering). Of course it’s not as polished, and certainly you can find poor schools to point at – but you’re cherry picking when you do.
The simple fact is that a Civil Engineering graduate (and I’ve sunk pints with enough of them to know) is as much a neophyte as an Electrical, Mechanical or Computer Engineering graduate. That’s why whole systems exist to provide Continuous Professional Development, it’s why we have the Chartered Engineer title and its equivalents, it’s why there are mentoring programs, it’s why no fresh graduate walking into a job is put in a position where a mistake can cause large-scale damage right away.
You’re expecting a four-year course to produce graduates with the equivalent of ten years work experience and years more of academic study. It’s unreasonable and uninformed to expect that. We produce graduates with the most flexible and wide-ranging skillset we can in order to give the best foundation to build on that we can. But we cannot teach everything. And that’s not a CS/CEng failing – you talk about Civil Engineering as though it was a single job, but it’s an area of industry with hundreds of subcategories and thousands upon thousands of roles; no Civil Engineering graduate has ever been ready to take on all of those roles, and none ever should, it would be a colossal waste of their time to learn how to do ten thousand things when they’ll only ever going to do a handful. So instead, Civil Engineering teaches the fundamentals well and the graduates, with the help of CPD programs, learn more specific skillsets as they go.
This does raise one interesting question though. In Civil Engineering, the Chartered Engineer title (and its equivalents, European Engineer in the EU and Professional Engineer in the US and others elsewhere) are the end product of CPD programs which include courses and mentoring, all of which are actively supported by the companies in this field. Companies budget for training, they actually strive to be recognised as CPD-qualified by the engineering associations and train people to act as mentors within the company, they very actively promote CPD development not just as an optional extra or a reward for their employees, but as a mandatory, socially expected activity for those employees. A civil engineer who isn’t working towards his Chartered Engineer title raises eyebrows.
So where’s the equivalent level of industry support and pressure in the CS realm? As far as I can see (and have seen) in Ireland, there’s next to no recognition of the C.Eng title – and that ties into the ethos we see expressed time and again by practitioners who argue that no formal training is required in order to be a “good developer”. Technically speaking, you probably could find one or two people out of a few hundred million who could build a bridge without formal training as well, but would you cross bridges built by the other few hundred million untrained bridgebuilders?
And within the companies in the industry in Ireland that I’ve come across — and I’ve yet to encounter anyone who’s worked somewhere with a truly different ethos (as opposed to corporate lip service) — training and CPD is something you might reward the best employees with by giving them an extra day’s holidays to go to a training course, and mentoring consists of micromanagement and little else.
All the workload that in Civil Engineering is spread between universities and industry, in Software/Computer Engineering, employers seem to believe needs to be taken on solely by the universities. Which simply will not work.
Now how we fix *that* is a question I’d like to see answered…
I have to say that I have to disagree with this article and the harshness of it. After finishing reading this article, I went to read Joel’s one and I feel that he has some valid points and none of the criticism in this post are warranted.
I finished a university degree 3-4 years ago and to this day, I have not found anything I learnt from it useful during my career in IT.
Joel’s points (although being strongly on the site of software development) are valid in most cases. Not waiting for the last day to finish a project (guilty myself there), team work (absolutely crucial in the real world), self-managing… all valid, fundamental and not slightly surprising qualities that should be taught before starting your career. Its not as if you need to be an expert at it, but it would be nice to include a few projects like that in university.
Also, the point of Joel’s post was that some universities decided to work on open-source projects as their school projects. I cannot think of a better way to teach people about programming while benefiting the rest of the world.
Not only do you get real world programming experience, you learn about developing with other people, version control, probably testing and new ways of managing projects. All this while your hand is being held by your university professor or teaching assistant so it becomes less intimidating. And the best for last, you improve open source projects that everyone can use to benefit themselves, their communities or their businesses.
Also, about the snake oil comment, totally uncalled for. Joel offered giving his software for free to students in the program mentioned to show his support.
You’re saying all university courses omit team projects, don’t get interim reports on long-term assignments, don’t take part in external projects and so forth – yet I’ve done those myself in here as an undergrad and still see them being done in here today, 16 years later. I know for a fact they’re done in several other universities. I know for a fact that it’s not just in Ireland that we do this. I know for a fact that all this has been hashed out for decades by people who are teaching in this field, formally, in peer-reviewed journals like the IEEE Transactions on Education.
I think perhaps you’re basing your view of university education on a poor personal experience. I’m not saying that it’s invalid – there are bad schools out there, just as there are bad companies and bad developers. I’m just saying it’s not valid to tar every school with the brush of the nadir of the field.
As to Joel, firstly I’m doing legwork to find a coherent point in his post to begin with (and the use of open source projects certainly isn’t it, by the way). Every statement he’s made in there, he negates in the last two paragraphs, and that’s before you notice that – as pointed out by commentators here and on reddit and on hackernews – he’s only recently argued against precisely what he’s now supposedly arguing for in this post. Add to that the point that he while he lauds Greg William’s work, he then dumps all over the students actually doing it because they’re, well, students. Rather than accomplished masters. Which seems wrong-headed from the start.
Then after highlighting what he says he thinks is the problem, he shills his own product as a solution. Yes, I know it appears that he’s offering it “for free” but appearances are deceptive. Every software company who deals with colleges like this will push their products not merely for free, but with extra donations tagged on. They don’t do it because they’re being altruistic. In fact it’s become a major problem in universities because with funding getting tighter, the pressure to make an economically based decision instead of a teaching based one is enormous. The reason they do this is that it’s a long-term marketing ploy, as explained above. Joel’s just doing it on the cheap. And it’s done in every discipline – Intel funds a clean room here and takes the top two students every year. The top two students here are more often than not actual bona-fide geniuses whose net worth to Intel will far outstrip the cost of the donation Intel made. If the deal can be struck constructively, it can be beneficial, but that’s a rare occurance – and Joel’s idea of a donation just plain isn’t beneficial to anyone but Joel. It is snake oil salesmanship. Heck, it’s not even good snake oil salesmanship at that.
Snake oil. I never hear before. Salam
[…] on Computer Science degrees is pretty wide of the mark – for many of the same reasons cited in this counter-argument. Speaking as someone with no formal Computer Science or Programming education, the most difficult […]
I like the picture! I’ve never seen Joel in a top hat before.
[…] this note, I think Mark Dennehy’s post “Joel Spolsky, Snake-Oil Salesman” is a must follow-up read. The discussion that follows in the comments makes some good […]
Mark, he isn’t *selling* his wares in that article. He’s offering to give them away for free.
From the article:
“FogBugz would work great for tracking this: if you’re doing a capstone project and need access to FogBugz, please let us know and we’ll be happy to set you up for free. We can also set you up with beta access to kiln, our hosted version of Mercurial, which includes a code review feature.”
Bryan, as everyone’s said before, it is a sales pitch. Joel’s not giving his stuff away for free here, he’s looking for product placement for free in a market most companies are paying a lot of money to get into. Altruistic, he’s not!
[…] an arbitrary tool or language that the industry is consistant in its opinion. I read this really great response to his article that echos many of my complaints about this […]
Well, except that he *is* giving it away for free. I’ve been using FogBugz hosted for free for over a year now. That doesn’t mean I’m drinking the Joel Kool-Aid. It just means yes, he actually is giving the software away to certain groups of people, students doing capstone projects included.
That isn’t giving it away for free Bryan. It’s just not getting money up front. Like I said above:
Ad-hominem, anyone? This thread to be filled of a lot of these.
[…] Joel Spolsky, Snake-Oil Salesman | Stochastic Geometry […]
[…] salesman image source: Stochastic Geometry This post has been tagged with:Amazon Android Apple at330 Editorial excite 13 Google iPad Mini […]