Ian Bicking: the old part of his blog

Training for Failure

I'm still not sure what I think about Joel Spolsky's JavaSchools post.

On one level, he just seems to be saying that he wants schools to be harder to weed more people out. Sure, I think it's justifiable that you have to have a certain kind of intelligence to be a good programmer, and that it's good to identify people who will be most successful based on that. (Similarly, if you aren't getting enough majors, making sure people succede isn't the answer, rather finding the right people and attracting them to CS is the answer.)

He's also arguing against vocational education (as Java has become a vocational skill), though that doesn't seem to be what people are picking up on. It makes sense that vocational education is part of the issue, because in vocational education it is expected everyone passes. You sign up, you pay your money, they graduate you, period. Unless you simply don't try, you will graduate, probably with any degree you want.

There's always been schools like this, but they've become much much more common. Honestly I think we -- the programming community -- really should call out some of these schools as frauds. It makes me sad when I see an ad where somebody says how successful they are making computer games with their degree from DeVry. It's such obvious bullshit to me, which makes it more pathetic that kids are conned into this sort of thing. But that's an aside. The point is that the same thing is happening to more reputable universities, and what Joel is talking about is this trend. You pay your money, they make sure you get through school, and as long as you try you should get a B or better.

But I'm not excited about the model that Joel wants -- one where you present these fairly small, quite mathematical, and fairly difficult concepts, and use that to eliminate students. It can work, sure, because those are useful and important skills that represent a useful talent; but they don't represent all the important skills and talents.

I think it would be much more interesting if there was more of an emphasis on the size of the problems, not just a sampling of challenging techniques. Pointers and recursions are useful concepts for algorithms, but as a programmer writing algorithms is not central to what I do, nor is it completely clear without experience why you use those concepts. I'd rather have someone good at designing and understanding the larger systems of software, than someone who was just good at algorithms.

We need to give students large projects, not just exercises and algorithms. Large projects aren't about pointers -- in fact, in a language with pointers it is unlikely that a new programmer will ever get far enough to encounter any of the truly interesting problems. And recursion is useful and important, but it's not a prerequisite for anything.

These projects need to be large enough that the students will fail, regardless of their talent; hard enough that they'll fail in small ways (forced to throw away bad code and ideas), and ultimately in larger ways (likely creating a big, confusing, buggy system they can't maintain). All learning is best done through failure. Instead of Joel's model where failure is a way of weeding people out, failure should be seen as a requirement for learning. I learned way more in the programming I did outside of my schoolwork in college, because those tasks were ambitious and naive and prone to failure. Any passionate and talented programmer should be able to point to a pile of failed projects. If they haven't stopped learning -- and it's not okay to stop learning -- then that pile should be growing.

But is this really good for employers? Maybe not. If schools don't produce passionless programmers who are afraid their inadequacies will be exposed, then who will work in the enterprise environments, who will write the accounting software, who will submit to using their B&D languages and their top-down methodologies?

Sorry, I've become snarky. But enterprise software aside, fear of inadequacy is a big problem. It's what makes people defensive and territorial and hard to work with. It makes people unwilling to learn new things, unable to guide themselves independently, unable to recognize their utility in the context of a team. Recognizing and becoming comfortable with one's own inadequacy -- for we are all inadequate -- is important. Humility is very freeing. I think schools should teach more of that.

How can you interpret literature if you haven't written an angsty poem? How can you work in science if you haven't royally messed up an experiment, if you've never drawn the wrong conclusion? How can you practice mathematics if you haven't been convinced of a proof that later turned out to be wrong? How can you be a philosopher without believing firmly in something you later come to detest -- and moreso, having tried ernestly to convince others of that ill-considered idea? How can you be a musician without writing a sappy or derivative song? Even cello players should be forced to write at least one love song.

So maybe that's what I'd ask of a prospective employee. Tell me about some of the things you failed at.

Created 03 Jan '06

Comments:

The Java schools that Joel Spoelsky writes about are simply trying to maintain their existence by keeping student numbers up as the overall market for programmers increases. They are teaching what a former colleague used to call "programming with a trowel". Of course it's getting harder to sort the wheat from the chaff, there are just that many more people out there claiming to be programmers. Ask the BDFL what he thinks of the skill levels of the typical Bay area Java coder.

That's not to say that someone like Bruce Eckel couldn't produce good Java, simply that there aren't that many good Java programmers around. But then the overall programming standard seems to have gone down as the programmer base has increased, so Java is probably just the populist end of this trend.

I think the most interesting part of your post is the bit about fear of inadequacy. If students don't learn from problems that make them aware of the possibility of failure then they will probably not get as much out of their attempts. However it's then very important to have a supportive learning environment that will highlight their successes and reference the failures simply as aspects of further learning than as inadequacies in their approach.

It's still true that "the person who never made a mistake never made anything", but it's important to encourage what we might call "constructive failure", and for that I don't think you can beat a vocational education. In fact there's a lot to be said for the old apprenticeship schemes: you were acknowledged to be learning for five years and you had that length of time to become competent - not a master, but someone who had the capacity to turn into a master.

It's good to see Fog Creek are supporting an internship program, and I hope that Google's experience with the summer of code was good enough for them to think about running something equally useful next year.

# Steve Holden

Well, part of the problem here is obviously Java. Most really good programmers choose their language for the language itself -- and they wind up with things like Scheme, Ruby, or Python. People who are in programming just for the money learn Java, Visual Basic, or C#. Paul Graham's Python Paradox is that as Python grows in popularity, the quality of Python programmers may decline as people use it out of job requirement, not desire to program in Python. (http://www.paulgraham.com/pypar.html)

Regarding apprenticeship -- the problem here is that a lot of experienced programmers aren't good. Having 10 years of experience writing bad software is just that -- reinforcement of bad skills. The truly good programmers don't always (but not never) have the aptitude for guiding a creative skill. Joel himself comes to mind.

# Ken Kinder

It's ironic that even as the video-game generation is coming of age, the ranks of U.S. computer programmers who create those games — plus more practical software — are thinning out.

But what if you could make programming into a video game?

That's the basic idea behind Alice, a software program developed at Carnegie Mellon University to ease students into programming painlessly. Instead of meticulously typing in lines of commands, the users of Alice 2.0 users move animated characters around the screen to tell a story — kind of like playing "The Sims."

Now Electronic Arts Inc., the company that produces "The Sims," has struck a groundbreaking deal with CMU to make Alice 3.0 even cooler — in an effort to reverse the brain drain and particularly to get more girls interested in computer science. Story continues below ↓ advertisement

"Getting the chance to use the characters and animations from 'The Sims' is like teaching at an art school and having Disney give you Mickey Mouse," CMU computer science professor Randy Pausch, director of the Alice Project, said in Friday's announcement of the collaboration.

Pausch told MSNBC.com that Electronic Arts will underwrite development of the new, improved Alice over the next 18 to 24 months and give CMU free use of the 3-D models and animation data for "Sims" characters. "We're going from low-end amateur to state of the art," he said. "These are the characters and animations from the best-selling PC game in history."

Used at scores of schools Not that Alice 2.0 is all that shabby. The object-oriented, Java-based programming environment is already being used at more than 60 colleges and universities as well as an estimated 100 high schools and middle schools to teach introductory computer courses. Two textbooks have been written based on Alice 2.0, and Pausch said "there'll be a dozen" once Version 3.0 comes out.

ALICE ON THE WEB

System Message: WARNING/2 (<string>, line 18)

Block quote ends without a blank line; unexpected unindent.

The Alice software and supporting materials are freely available over the Web: • Alice home page • Download the software • Teaching materials • Another Alice textbook • Alice community

System Message: ERROR/3 (<string>, line 24)

Unexpected indentation.
Image: Alice logo

System Message: WARNING/2 (<string>, line 25)

Block quote ends without a blank line; unexpected unindent.

Alice.org Alice was created to get around the frustrations that keeps many students from getting beyond the intro classes — and in the longer run, reverse a trend that has seen a 50 percent drop-off in the number of computer science majors over the past five years. Statistics also show a widening gap between male and female interest in computer science.

With Alice, students start out with a natural-language, drag-and-drop interface that puts colorful 3-D characters through their computer-generated paces. Instead of typing lines of Java code like this: public static void moveTo(Thing t, Map m, int tx, int ty ) { ... you just move your mouse or type in commands like "rotate one left quarter turn." The idea is that Alice can lay a fun foundation for future computer courses.

"The new version that we're now beginning on will gradually morph into a more traditional Java programming environment," Pausch said. "So we're talking about the training wheels gradually dropping off."

Alice emphasizes a storytelling approach to building a program, rather than a shoot-'em-up approach. "We found that when we targeted Alice as a storytelling vehicle, girls were three times as likely to be engaged and motivated to write computer software, as opposed to just moving 3-D characters around," Pausch explained.

How the deal was done That user-friendliness is what appealed to Electronic Arts, Pausch said. He and his colleagues at CMU have been working with Electronic Arts for years, and the company has agreed to hire 10 students from CMU's computer science program annually. A couple of years ago, Pausch spent a months-long sabbatical at Electronic Arts, and the executives there were particularly intrigued to hear of Alice's success with middle-school girls.

"EA comes to this with the goal of doing well by doing good," Bing Gordon, the company's chief creative officer, said in Friday's announcement. "Inspiring next-generation game-makers is a primary objective. Alice has already proven to be a powerful tool to engage all kids — most particularly girls. Our hope is to contribute in a way that further accelerates its success."

The terms of the deal call for EA to contribute its intellectual property for free use in the Alice program, which is distributed freely by CMU. "The way this license works is, if somebody picks up the open-source Alice and the 'Sims' data, they can't do anything with that that isn't noncommercial educational use," Pausch explained.

That means Electronic Arts won't be offering a souped-up commercial version of the program — and Pausch acknowledged the deal also means neither he nor CMU will profit from Alice 3.0. "Put the handcuffs on me," he said jokingly.

"We all want kids, particularly middle-school girls, to have a better path toward computer science," Pausch said, "so it really is this pure play in terms of, for lack of a better word, nobility." http://www.projectslist.biz/freelance/Java/

# Petro

There are a couple levels at play in Joel's essay. By programming exclusively in Java, he asserts that it is extremely hard for a hiring manager to quickly assess a potential hire's skills. This is not something exclusive to external assessment; it's a problem for the nascent programmer to assess himself. Schools can capitalize on this by keeping poorer programmers in their program, and these poorer programmers cannot tell that they are poor at it. This is unfair to the student during the process, and unfair to the hiring manager later. Is this because the failures are minimized?

To take an analogy of cooking, with only limited ingredients and extremely helpful tools (imagine a pan that won't burn anything), how can you identify the great cooks, the good cooks, and the mediocre cooks? In school it's more important whether I can improve my skills. For the hiring manager it's often more about which level of skill I possess - or at least where I max out. But unless it can be usefully measured, how will any of us know?

I agree Joel's essay oversimplifies in the implication that algorithms and pointers are necessarily the hard part, and that competence in the hard parts can predict the overall competence. I think they're strong markers, and much more easily measured than some idea of code quality, but they're still not ideal or fully representative markers.

# Michael Urman

I took a total of 6 computer science credits en route to my B.A. in Anthropology and, forgive my immodesty, I think I do really well as a programmer.

Heck, the three best programmers I've had the pleasure of working with are college dropouts. And the worst developer I currently work with has an M.S. in Comp Sci from Stanford (that would be pretty awkward if she read this).

I think it's unfortunate that Joel puts such emphasis on a CS degree, never mind its curriculum.

# Joe Grossberg

I also think part of the irony of Joel's article is that Frogcreek developers little more than massively overglorified CRUD software, of which any punk kid could probably churn out faster than Joel himself. :) But that's my opinion as a Python programmer who avoids C like the plague.

# Ken Kinder

I was going to say "hey, good CRUD software is still good software." (And I havn't used FogBugz, but it sounds like it works well.) But then I thought, why would you ever be handling pointers in a CRUD application like what FogBugz? Of course, that's not really his point either -- it's not that pointers are the skill Joel cares about, it's that pointers represent some skill he cares about, presumably one that indicates an unteachable talent. You might then ask if that unteachable talent is the most important unteachable talent for the kind of applications Fog Creek develops. I guess I'm just arguing it is not, since their software is not algorithmically complex (like most software), and pointers don't indicate a talent that is particularly closely associated with software design at the CRUD-level. And really CRUD apps are apps that use very high level constructs (a database) to get you closer to what (IMHO) are more interesting problems -- they aren't really easier applications, except insofar as you don't make life unnecessarily harder for yourself.

# Ian Bicking

Actually, I think that FogCreek is trying to lure great developers to their shop by providing a killer environment (as codified in Joel's Test). Having worked in noisy, un-appreciative environments, I think even 10 points on Joel's Test would be a great offer.

Their products really don't feel like the hottest and sexiest projects to work on. But what I've heard about them is that most of FogCreek's users really love FogCreek's products.

(It's funny though now that Joel is also a Paul Graham fanboy and Paul keeps touting how no self respecting hacker would ever work on Windows. I wouldn't object working on Windows, but it would be a little minus nevertheless.)

# Jarno Virtanen

Tell me about some of the things you failed at.

Ok, my résumé just grew ten-fold.

MWM

# Matthew Marshall

I'd summarize Joel's message as: 'shortcuts' == 'mirages'.

# Chris

>It makes me sad when I see an ad where somebody says how successful they are making computer games with their degree from DeVry. It's such obvious bullshit to me, which makes it more pathetic that kids are conned into this sort of thing.

Actually some very sharp people come out of technical schools like DeVry. Some focused people want to get straight to the relevant stuff rather than spend 2 years on general ed fluff. Which isn't to say gen ed can't be useful, but truthfully, you won't even remember 90% of it after you graduate.

Sure, there will be washouts, but the same thing goes for most colleges. The point is that having a degree from a technical school is not an indicator of a sub-par technical education.

# auser