Is Eric Burke qualified to teach CS
by Daniel H. Steinberg
Eric Burke's recent weblog Simplicity and "Getting It" is so right in many ways. He makes great points about the training of programmers and refers to one of the books on my "must read more than once list", Andy Hunt and Dave Thomas' The Pragmatic Programmer. For related interviews by Andy and Dave, check out Bill Venners' ten part series at artima.com. One of the most important points Eric makes is this.
What troubles me is the observation that we have legions of programmers who don't seem to "get it" when it comes to writing maintainable code. They are happy to produce reams of code that seems to solve the immediate problem at hand, and are perfectly content to move on to the next problem, leaving all of this horrible code behind.
Compare that with Bob Cringely's article Refactoring, refactoring.. Cringely doesn't worry about maintainable code. He only cares about working code. He writes:
The key problem, as I wrote last week, is that refactoring means monkeying with working code. If the program isn?t working, you don?t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.
Ken Auer brought a group together a year ago to talk about software apprenticeship. If creating software is a craft, then we need to find better ways to get meaningful interaction between experienced practicioners (masters) and those entering the field (apprentices). If I could spend a year pairing with ((fill in the name of a software professional you really respect)) would you value that as much as an academic degree? What is a BS, MS, or PhD meant to convey?
Can we be certain that the people teaching at the college level are qualified to train new programmers? I argued at the summit that there was value in academic training. Others argued that too often those teaching programming had never developed or maintained code. They'd never written code for a client and weren't experimenting with new languages. Check out chromatic's article on Programming Annoyances. He continues to learn new languages so he can apply the best tool to the job at hand.
I've ended many of my talks to professionals these past couple of years with a challenge for audience members to adopt local colleges and universities. The professors can't keep up -- spend some time giving a talk or two on some new technique or technology you are using. Then this year a university position came open nearby. I encouraged a couple of friends to apply for the position. I even applied for the position. There are many reasons not to hire me -- but the reason I and my friends were not considered was that we didn't have a PhD in CS. The job listing explicitly said that that was ok. I think there are many with a PhD in CS who would be fabulous teachers but I think you unwisely limit so many talented people from the pool when you draw this line.
I read a posting like Eric's and think, "boy, I could learn a lot from him." I spend time with Uncle Bob Martin and think, "he is one of the best teachers I've ever had." I go to lectures by James Duncan Davidson, Jason Hunter, and countless others and come away so much richer. This little school would only consider hiring them if they had a PhD in CS. Not being able to learn from this rich pool of talented people, in my opinion, is hurting the next generation of programmers.
Who should train programmers and how?
Universities vs. practical training
I'll try keep this brief.
I think this post doesn't what I see lots of people do: confuse the essence of what university training is about.
University - historically at least - has been about the theory *behind* things, not the practical doing of them... It'd be nice if they also taught the practical side, and to an extent they do, but historically, that's not their main role.
So computer science tends to teach things like particular algorithm areas, the inner workings of specific protocols and the theory behind their workings, the theory of language design, etc.
Apprenticeships - valuable as they are - are quite a different thing altogether and have very little to do with the examples of teaching I've given above.
It'd be nice to see more practical stuff added, but this is "aded", in addition to the main role of the university courses (historically speaking, anyway).
In a similar vein we can distinguish computer science and computing; O'Reilly's focus is largely on the latter for example.
Universities vs. practical training
A big "ditto" on that one. Here in Australia the problem arises that effectively all IT jobs - even the lowest entry positions - require a graduate qualification in CS or IT, and the majority of qualifications are still the result of a course which is more 'computer science' than 'computing'. As a result, a great many entrants into the profession are not necessarily competent beyond any native ability they may have.
Computing and teaching are two area of human endeavour that very definitely could benefit from an apprenticeship or internship.
Universities vs. practical training
>University - historically at least - has been about the theory *behind* things, not the practical doing of them...
>It'd be nice if they also taught the practical side, and to an extent they do, but historically, that's not their main role.
I received my degree from a Polytechnic (I'm not sure what the equivalent is in the US) and it was mainly focused on practical programming in an industrial environment. I was fortunate in having lecturers who had worked in the real world, but all of this was 13+ years ago.
There does seem to be a mismatch between accademic and practical computing in general though. Perhaps we need a relationship between the two more like the relationship between engineering or architectural colleges and the practisioners of those arts in the real world. One bridge that would be worth building would be a system of formal accreditation. A widely appreciated and influential society of chartered software engineers would be a good start.
Computing is still a very young field, and I believe formal accreditation schemes, which do seem to be forming although currently around particular products, must gain roader meaning and validity. The sooner this happens the better.
Finaly, those of us who do feel that they have something to contribute to the accademic world can put their money where their mouth is and go out and get a PhD in Computing. I believe that would be a worthwhile and rewarding goal. Gaining a PhD is not a one-way street of teaching from accademia to the student, the whole point of a PhD is that the student contributes to the accademic field in the process.
It omes down to two basic things which the software development companies lack- the ability to take the long view and the ability to distinguish programmers who "get it" from those that don't. In this they are typical of most US corporations. The long view means realizing that you actually pay for spaghetti code down the line, if not this quarter. Hiring H1B programmers who just churn code out at a cut rate means you get spaghetti code, but you get it this quarter. It's amusing that they don't realize that all the bodyshops supplying them with cheap labor has a huge hidden price tag on it. What we need is a long-range study which can quantify of the effects on a company of coders who produce these messes.
Yes, a craft, but also...
To me, programming is craft, science, and art, in different amounts depending on the programmer, the task at hand, and how far along the effort is. These are different aspects of programming, and different ways of understanding it.
It's like something I heard in college, I think in Cognitive Psychology: a college physics professor, a video engineer at Sony, and a TV repair-person all understand how a TV works, but in different ways. And if yours is broken, they'll all approach the problem in different ways, with the repair-person probably having the most applicable knowledge. (of course, change the problem at hand to "I want to build an HDTV that works in space" and the skill-set relevance will be much different)
Apprenticing and oversight will nurture the craft of programming, but there's still benefit in a purely academic approach to teach the science of computer science. Put more practically, college doesn't teach you how to check your code into cvs or how to keep it maintainable, but the school of hard knocks usually doesn't teach you the underlying math of programming (eg, efficient sorts), classic structures like hashtables and linked lists, formal concepts of scoping, etc.
A pure academic may lack the craft to write maintainable code, but so can someone who just slashes it out day after day. The untouched-by-reality programming teacher from your summit should do lunch with some raised-on-VB train-wrecks I've met, guys who get lost after 5,000 lines of code because they're in too much of a hurry (or are just too cool) to design or plan ahead.
There's a "getting it" involved with writing code in a way that someone else can maintain it, that it won't blow up when implicit assumptions go away, etc. There's a very different kind when you first "get" object-oriented programming, pointers, patterns, hashtables, thinking in LISP, etc.
Knowledge vs. skills vs. ?
Sorry in advance for the long post, but this one strikes a cord with me.
In training programmers at various levels of experience and with various levels of acedemic training, I've slowly come to believe that we often simplify this issue.
I've come to the conclusion that to be good at programming (or anything else) you need: aptitude, interest, knowledge, and skills.
If someone has no interest, we won't have to deal them. We've all seen plenty of people with no aptitude (or talent) for programming, they normally are gone before too long.
Acedemia teaches knowledge but is normally light on skills. Most skills seem to be learned "on the job".
If you have all of these things, the road to becoming a great programmer seems to require something else. I call this "mastery". Your level of mastery is what allows you to recognize the right skill (language, etc.) for the job. Mastery is what tells you which algorithm to use. (Yeah, Quicksort is better in general. But I need to add an item once in a while to a sorted list, insertion sort.)
Apprenticeship seems to be a good way to develop skills and the fastest way to mastery. I believe that the only other way to mastery is by doing a lot of stuff and failing often enough.
CS isn't necessarily programming
I think that a common (and unfortunate) misconception by those outside the academic community is that obtaining a CS degree prepares you to be a programmer. I remember being stunned when one of my professors informed the class that the purpose of the CS curriculum was to prepare you for advanced study in Computer Science, not to be a programmer.
The CS degree is but the first step - it gives you the foundation you need in order to proceed in a variety of directions and where you go from there is up to you. If you want to be a Computer Scientist, you build on that foundation with advanced study in a masters or doctoral program. If you want to be a programmer you build on it with real world experience - and that's where the apprenticeship/mentoring could be invaluable.
I believe that a great deal of bad code out there comes from this industry's voracious need for developers and the willingness of employers to call anyone with a basic familiarity with a programming language a "programmer." You need several things to be a truly excellent developer: the solid technical foundation provided by a degree; the confidence you get from successful real world experience; and the drive/curiosity that means you'll continue your education/training by reading/studying/experimenting on your own time.
So, I'd have to say that the many technically excellent developers out there probably aren't qualified to teach Computer Science as it's understood by the academic community. But there is great value in passing on the knowledge these developers possess if we can somehow make it clear to both students and employers alike that the degree is just the beginning.
You might consider reading Computing Curricula 1991 - Report of the ACM/IEEE-CS Joint Curriculum Task Force (http://www.computer.org/education/cc1991/eab1.htm#6).
Section 4, Undergraduate Program Goals/Graduate Profiles, states "Third, different undergraduate programs place different levels of emphasis upon the objectives of preparing students for entry into the computing profession, preparing students for graduate study in the discipline of computing, and preparing students for the more general challenges of professional and personal life. Students enrolled in any undergraduate program in computing should be aware of that programs particular emphasis with regard to these three objectives."
Also section 6.2 The Role of Programming, states "The term programming is understood to denote the entire collection of activities that surround the description, development, and effective implementation of algorithmic solutions to well-specified problems. ... On the other hand, programming is not to be construed so broadly as to subsume all of the activities involved in software methodology and engineering. The latter is a much broader notion and includes, for example, the development of specifications and the maintenance of software."
The author ignored the social factor in the software engineering totally, Which I consider a key factor for producing the quality of the maintainable code. Just ask software engineers in the field a question: How do you do a code review for the code written by your technical managers or team leads, or senior manager's favored team members? Could you criticize their code openly?
Not. For the office harmony and job-keeping sake, most people just do a quick run-down without raising an eye brow.
To produce a maintainable code, we need qualified management team to promote and cultivate a friendly social environment for the peer cooperationa and reviewing. There is no bad soldiers, there is a few bad generals.
H1B body shops
Exactly! And then the developers who do "get it" spend hours, days, or weeks fixing the problems that the H1B programmers created. To management, though, we look less efficient, since we're spending time fixing existing code, rather than spewing out reams of spaghetti code.
I can only imagine that offshore outsourcing results in even worse code.
Mostly a matter of passion
I tend to think that software is primarily an art and secondarily a science. Like an atrtist, what matters most for a software developer is passion. Looking at somebody's code, it's not too hard to tell what the driving force behind the code is, whether it's the passion and the creative urge or the paycheck.
H1B body shops
Its just the money.
50% of sw development
is pretty banal.
U guys are just pissed
cause its cutting into your salary, and
thus the attack on h1b developers.
Reading about Globalization, tom friedman,milton freedman, eco101 fundamentals should fix u'r brains.
Theres no real reason for a simple
access/VB database developer making >$80k,
when for $20k you may get the same work done
For complex sw(say computer vision algorithms etc
) there still is no place like the us.
But for run of the mill sw, there isnt any difference.
You had it pretty good. It was berlin wall that kept you insulated. After the fall the whole
world changed its attitude towards capitalism.
You've started to see competition in <20 yrs after the wall. You will see more competition in every field, from all over the world in the coming years.
New equilibriums will be reached. For run of
the mill sw american salaries will come down. So
learn to live with it white man.
The blacks,brown,and yellows(BBY) of the world are now in the process of fixing their economies. Their kids are hungrier and will work harder than average white kid. The greatest disappointment
for a BBY kid is not getting accepted in a good school, whereas for a white kid it is not being
popular in school. Weather you live in burkina faso,us,india,china,singapore,etc you are competing in the global free markets. Face the competion and make u'r self relevant or cover your
head under sand and be BITCHY about everything and
wither away into irrelevance.
H1B body shops
In a word - nonsense. I have seen an awful lot of code generated offshore at body shops, and onshore by h1b visa body shops, and it is almost all utter junk.
I have also met individuals with h1b visas who were very competent, and whose code was damn fine.
The reason is the difference between the best and the worst.
According to Tom DeMarco, there is roughly an order of magnitude difference between the best and the worst companies, and between the best and the worst developers within a company. Further, it does multiply - the best developers are an order of magnitude more efficient than the worst ones.
So, what I am seeing is the simple consequence of that - the body shops tend to produce inferior code, but the best they have can be good. Further, if they get into a good environment, they can be exceptional.
My solution? Abolish the H1B visa, and offer standard work visas with citizenship to those who want to join our country. Allow companies to offshore work as they see fit, and note that those who pick the best, wherever it is, will see dramatic benefits.
I suspect that we are still creating some, but by no mean all, of the best programmers in the world. If we cease to do that, then the best in the world will be somewhere else, and we get to hire them.
As far as the BBY comment - the best programmer I have met yet was a black (I would give exact ancestry if I knew it) chap from Hong Kong. Very competent, and he did end up emigrating IIRC. He came here, because this was the best place to turn an already good mind and talent into an exceptional one.
I am not claiming that _only_ american schools make great programmers. I do claim that _some_ of the schools here are among the best in the world, as are some of the companies. To keep that true, we must attract those stellar people, and get them to come and stay.
Academia needs to catch up
I heard a lecture by Freeman Dyson in which he stated that "I accomplished so much because I did not waste the time getting a PhD."
Given that he is one of the brightest folk I know, I suspect that he should at least be listened to.
In my opinion, academia rarely values anything but a PhD. To many academics I have met, this is the bare minimum needed to have something interesting to say. I find this laughable, as they often teach work done by people without PhDs, at least in CS.
Not all schools have this attitude. At Harvey Mudd College, all undergrad classes are taught by PhD holding professors, not graduate students. This means that undergrads help with research, do independent work, and otherwise interact directly with the professors. This helps the professors realize that even an undergrad might have a useful thought in their head.
Further, the profs often do not realize that the majority of their students are not going to be researchers like themselves, and thus that they need to prepare the majority of those students for a life different than their own.
Look at the supply - a typical university professor has several grad students, and thus produces a supply of roughly a dozen undergrads each a year, and perhaps one replacement PhD in that time. That same professor is going to be in academia for decades, so where do these people go? Unless we suddenly adopt a 1-1 student to faculty ratio, they go into industry.
So, I submit that the best way to solve this lingering problem is greater communication. Find a way to bring working professionals into the classrooms as domain experts. Oftentimes, they have neither the time nor the desire to teach a full semester course, but they may be willing to do a one hour or one week special topic.
This will also help the professors get more contact with the industry figures. That may keep them focussed on where the majority of their students are going, and what they may need when they get there.