Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sdcc3.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxlm!akgua!sdcsvax!sdcc3!brian From: brian@sdcc3.UUCP (Brian Kantor) Newsgroups: net.college Subject: Re: Where have all the hackers gone? (long comment) Message-ID: <2591@sdcc3.UUCP> Date: Thu, 27-Dec-84 01:15:43 EST Article-I.D.: sdcc3.2591 Posted: Thu Dec 27 01:15:43 1984 Date-Received: Fri, 28-Dec-84 05:03:22 EST References: <3138@utah-cs.UUCP> <521@sdcsvax.UUCP> <557@uwmacc.UUCP> <115@sdcc13.UUCP> Distribution: net.college Organization: UCSD wombat breeding society Lines: 71 > >>I'm an undergraduate at UC San Diego, and I have seen this exile here also. > >>The "fittest students" are the ones with the best grades, not the ones that > >>are the best programmers. > > As an employer, the first thing I would avoid is hackers. > A good student can be taught, while a hacker has to be > negotiated with. Give me a student over a hacker anyday. I've been in a position of hiring recent graduates for programming jobs, and in general I found that neither the ``ultimate hacker'' nor the ``top student'' made the best programmer/analyst. Why not? The hackers just didn't have long enough attention spans, and didn't seem to want to spend enough time to get the problem clearly defined - the jumped into the solution without a clear feeling for what the real problem was. Most commonly, they solved what the customer had SAID the problem was, rather than what it really was. (You experienced people know that the customer is rarely right in defining his problem.) So their solution was a good one, but for the wrong problem. The top students had two major problems: too many of them wanted to make it big, moving into management instead of programming. Seems they had their eye on the president's office rather than their terminal. In a team, they tended to try to run things, rather than get things done. The other problem that many of the top students had was a severe lack of imagination. They had a lot of trouble applying book learning to real problems. It seemed as though they had just never had to worry about making a program conform to the real world. I noticed this especially when they had to work for me on a machine that had a bizzare programming language (sort of a cross between Basic and PL/I). Many never were able to adapt to the techniques that machine required (A Microdata REALITY, in case you were curious). Who, then, made the best for our purposes? Our most successful programmers were people who had done something else for a living. One managed a nationwide chain of Karate Parlors before going back to school and learning programming, another had trained as a physicist, one an air force pilot until he lost a hand in VietNam. What made these people different from the others is not that they were older or more experienced - because some were and some weren't. What made them different is that they had come to view the computer as A TOOL USED TO SOLVE REAL PROBLEMS. They understood that it was the real-world problem that had to be solved, not a nifty algorithm, nor a textbook exercise. But how do you teach people this? Since very few professors of computer science do anything real-world with their skills, they really can't pass on true-life experience to their students. Industry professionals could, but it seems that many problems might require too much detailed background knowledge to serve well as examples. Also, people in industry rarely have time to spare. I feel that a good curriculum in computer science should include some sort of class in problem solving - something that teaches people to look for the REAL problem, and solve it. Yes, it will weed out a bunch of people; and yes, it will be hard to teach. But if we truely intend a computer science education to fit its graduates to do more than sit in a college or university office and dream about theories, we have to equip the students in it with skills and techniques that will enable them to shape their skills to suit the needs of their employment. Be clear that this is NOT rote knowledge - it is a learning skill. Being the best buggy-whip programmer in the world isn't worth a tinker's dam when its time to build spaceships, if that is all you know how to do. Brian Kantor UC San Diego decvax\ brian@ucsd.arpa akgua >--- sdcsvax --- brian ucbvax/ Kantor@Nosc Ticking away the moments that make up a dull day Fritter and waste the hours in an offhand way...