Inspiring our undergraduate students' asperations

Some Defining Experiences Summer 1965. I think I contributed to the Y2K problem. After my junior y e a r in a BSEE program, my first "real" summer job (camp counselor did not count) landed me in a local branch office of a large (very large) computer company. I was an intern attached to a sales team, learning to special ize in customer appl icat ions while the sa lesmen specia l ized in mainframe configuration and pricing. My prior computing experience c o n s i s t e d of one 3-week Fortran project in my numer ica l -methods course. When I re turned from a mandatory 2-week crash course in the assembler language of the era, the salesmen unburdened themselves of a pesky intern by parking me at a large state agency, suggesting to the data processing manager that I was there to help him. I assume they didn ' t tell him I was just an intern; he put me straight to work designing and coding a module of the agency 's new payroll software. I knew just enough about software development to be real ly dangerous to someone 's business. For all I know, my code is still running there, with 2-digi t year f ields, in emulat ion mode, computing incorrect overtime payments. Fall 1975. In my first semester as a green assistant professor, I was ass igned to teach a sophomore assembler course. To one non-degree student in the course, I suggested that perhaps a vendor -sponsored short course might serve her needs better than a curriculum-based one. This was not possible: the employer would reimburse tuition only if the course carried academic credit. The student earned a "mercy C." Shor t ly thereafter, m y s tern-faced department chairman showed me a blistering letter from this student's supervisor. No employee of his would ever enroll in another of our courses. I had focused too much on designing assemble r programs, a lgor i thms, number representations, and so on, and had thus failed to cover the entire Sys tem/360 instruct ion set. Trembling, 1 explained that I had fo l lowed the adver t i sed course outline. The chairman grinned and r ipped up the letter. "Don ' t worry, Mike; you did the right thing. We are educators , not trainers. The employers don ' t get it." Summer 1988. A friend managed the division that educated software developers who were using his company 's compiler and CASE tool products. The company decided to change his divis ion tit le from "Educat ion" to "Training." (They changed little else, just the name.) The division's business picked up. A survey revealed that their customers perce ived " t ra ining" to be useful, while "educat ion" was "academic" and therefore useless. Spring 1998. A technica l manager from a large (very large) sof tware company vis i ted m y depar tment . He was recrui t ing graduating seniors himself because he did not trust Human Resources to find him the best people. For 45 minutes, he treated me to a withering critique of our program. We focused too much attention on "engineering" (his word) and not enough on how to make software " rea l ly fast." He was unlikely to hire any of our graduates; he was not looking for "engineers"; he needed a few "bril l iant hackers." My stories span 34 years; our technologies have changed immensely in that time. The 1965 mainframe cost millions, had punched-card input and a 32K core memory, crashed several t imes a day, and lived in an isolated air-conditioned room, cared for by lab-coated technicians. My current PowerBook regularly runs MacOS, Windows, and X GUIs and applications at 200MHz clock speed. It fits in my briefcase with room to spare, and cost (in constant currency) roughly the same as the tuition for that 1975 s tudent ' s one G W course. Computers are no longer isol~/ted batch processors; they so pervade our lives that much of society is in panic over the predictions of disaster next