Someone straight out of college with a "real" CS degree will likely know about about algorithms, data structures, compiler theory and so on. Some of those skills are not terribly useful for many entry level programming jobs but some are critical. I'm unlikely to hire an entry-level programmer who doesn't know basic data structures, for example.
For those whose experience is "real world", they might be able to tell you a lot about unit testing or source control but stare at you blankly if you ask them about red-black trees. That might be OK depending upon what their work requires them to do.
If you're prone to categorize, most CS/programming skills could be loosely grouped into three areas.
- CS knowledge (e.g., compiler theory)
- Real world knowledge (source control)
- Overlap knowledge (basic data structures)
What would you put in each group and why?
Cheers,
Ovid
New address of my CGI Course.
Somone who knows all the theory can pick up CVS, xUnit, Test::Builder whatever without much trouble. It doesn't work the other way around.
Joel Spolsky talks about this stuff in his graduates from Java-only schools. Basically, when he interviews them and throws them a question that require recursion (or pointers), if they struggle, he can't tell if it's because they're smart but recursion wasn't an impportant part of their education or if they're someone who'll never grok recursion.
lambda-the-ultimate has lots of discussion and links to even more discussion about this article.
stare at you blankly if you ask them about red-black trees. That might be OK depending upon what their work requires them to do.but you have no real way of knowing what their work requires of them and when a CS grad would have said "aha this would be much faster with a red-black tree" and make what seemed impossible, possible.
I worked somewhere that use Delphi/Object Pascal (very similar to Java). It has no hash data structure in it's standard library but it had associative arrays. They are implemented as arrays of (key, value) pairs. Which is fine for a short list but very bad for a long one. Most of the coders there had never heard of hashes and didn't even know what they were missing.
Joel Spolsky talks about this stuff in his graduates from Java-only schools.
Wow, one-langauge CS departments? I find it appalling that such a program can be accredited. I only _minored_ in CS, and I had courses in some eight different languages. Granted, my Data Structures and Algorithm Analysis course was not as difficult as Spolsky describes, but I certainly was exposed to pointers and recursion in my various other courses.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings." — Pratico & Van Pelt, BBHG, p68
However, I think it's possible to go the other way. I think the main barrier is time: the materials are generally free over the internet, and there are numerous resources where one can discuss theoretical points of CS (including perlmonks).
The other point I'd add is that a lot of the knowledge in the field I currently work in revolves around knowing the business (securities brokerage industry in my case, but even less complex industries have important sets of knowledge a good programmer should understand). Knowing this kind of information classes as "real world knowledge" in this case.
I disagree somewhat with the assertion that it's not possible to work from experience to theory.
When did I say that? That's been my knowledge path and I'd hardly deny it. I certainly hope I didn't imply it.
Cheers,
Ovid
New address of my CGI Course.
Everyone has an opinion, but no one has answered the question.
Unfortunately, I'm not qualified, but I'll give it a shot...
- CS knowledge
- Language Evolution
- OO concepts and theories
- compiler theory
- Use-Case scenarios
- Application Development Cycle
- Real world knowledge
- source control
- compilation environments and OS quirks, i.e.: Unix vs. Windows
- Project needs evaluation (vs. Use-Case scenarios)
- Deadline estimation
- Application Development Cycle
- Overlap knowledge
- Basic data types
- OO concepts and implementation
- Code reuse (libraries, modules, etc)
As I said, I'm not really qualified. I've had some real-world experience and no book lernin' other than taking the initiative to read the K&R book and a few books with animals on the cover.
I put "Application Development Cycle" in two places on purpose. It seems to me that what's written in some computer books doesn't work in real life. So, the Application Development Cycle has to be adapted from what people learn in school.
My opinions are mostly based on people I've met. I've met a few book-lernt people who wanted to stick to a development cycle... they took as long to draw up their snazzy diagrams as it would have taken to do a significant part of the application.
-- -- GhodMode
A technology specialist will have a compiler, debugging tools a decent editor etc. Obviously there is a pecking order. A C compiler counts whereas the VB macro compiler built into Word doesn't. Compilers for C# and Java count if they are the professional versions. They will use these tools to write and compile source code into executable code. The machine itself will be bigger and probably have the server versions of software installed. Open source software is installed from the compiled code.
The middle ground is owned by people who assemble pieces of pre-built technology and generally work with systems created by others. A Java SDK, web server (Apache or IIS), personal database (MySQL, Access etc.) may be installed. Open source software is installed from the binary distributions.
The non-technologists in the IT department will principally use project planning and resource allocation software along with Powerpoint or similar so that they can manage projects and communicate the plans and status to the business contacts. Excel will be running on an almost permanent basis. Open source software is an interesting concept that is well progressed along the Gartner hype-curve.
Compilers for C# and Java count if they are the professional versions.
Could you expand on that? Working with VS Enterprise Architect at work and using the Standard Edition at home I notice no difference in my ability to write code in C#. I certainly don't qualify a compiler as professional or not. That is counter intuitive to me.
Other than a few rad features not being present or compiler optimisations being crippled there is not baby/professional version of the language merely the IDE. So the IDE for the standard version cost me 80quid. At the time the Enterprise Architect version would have cost 1600quid. There are one or two code generation templates and integration tools missing - but nothing that stops me being a programmer.
Well - in my opinion :).
The machine itself will be bigger and probably have the server versions of software installed.Is there a server version of C or Perl? How about Python or Ruby? Ok, I know what you mean but thats an overly simplified metric to use. It also only really applies to windows desktops that I can see.
As to your middle ground, I understand your point but I don't agree with how you have put it. Surely, at some point, you will always be assembling areas of prebuilt software. Thats the whole point. Because you install the binary of some application rather than compiling yourself doesn't make you any less worthwhile or technologically (ad/in)ept than your colleague.
I am not familiar with the latest MS tools but I can relate from experience that Borland ship a free version of their JBuilder tools in edition to the paid for professional and enterprise versions. Anyone could download the free version to evaluate it but it wouldn't necessarily mean that they were a developer.
The comment about server versions of software was more to do with having Oracle server installed on your machine (or on your development server) for development rather than Access.
Is there a server version of C or Perl? How about Python or Ruby?
There aren't necessarily 'server' versions of these languages but you can differentiate between someone who installs Perl in order to get a third party app running and someone who codes using the language and understands it.
I used to help the test team install the command line version of the MS Visual C compiler in order to support an automated test tool. They didn't code in C but were technically expert at automated testing. I also set up a Perl environment in order for colleagues to test a Wiki solution that was based on Perl. They didn't do a scrap of coding but were able to do a technical evaluation of the product.
Not me!
The only software I have installed on my personal computer is standard issue for the department. It's a basic Windows XP install including PuTTY.
I do have admin priveledges on the development machine I work on; but I also hate being a sysadmin, because I'd rather be a developer. I code in vi because I know it will always be around no matter which version of unix I'm using.
So, I have nothing special installed. My machine is nothing special but it doesn't need to be; I could get by with a vt100 plus a decent web-browser. I know how to use the standard issue tools well enough not to need anything else. When I need a tool to solve some niggling little task, I generally just code a little perl script to do it. If I can't do it in perl for some reason, I'll code it in C. instead, or, if the problem will take more than an hour or two to solve, bite the bullet and download something.
I think I don't fit your metric very well. :-) I'm definately a developer, but my machine is very, very boring. :-)
I hardly ever see a reason to compile open source projects myself, as I generally do not edit its source code.
And "professional versions" of compilers etc. I tend to see as bloat/vanity. Like an expensive sportscar. Do they compile better code? Er..., no. Ditto with "server versions" of software.
soft skills
meaning things like:
- communicational skills
- organizational skills
- stamina
- appropriate dressing
Ok, if it comes down to dress code, you can live without it....
cheers
237
But I think that of all skills I need at work today I learned
- more than 25% before I went to school
- less than 25% at school and university
- 25% at my spare time, when I was at school and university
- 25% at work
regards
237
Ok, Ok, Ok maybe american schools and universities are just better than those I went to!
Well, some are better than others, obviously, and that's true in every country, but in general you shouldn't be able to get a four-year degree in any subject without taking at least one communications course, most likely public speaking or somesuch, and if after taking a three-credit course in speaking you don't have the communication skills to order a meal in a restaurant, something is very wrong.
Now, vocational schools obviously are another thing. Those types of schools often don't require you to take anything substantial outside your major field, so if your major is CS you won't have to take any communications, literature, history, biology, or art. A degree from that type of school is a different thing. It has value as a certification that you received a certain amount of training in the field in question, but that's all. A four-year degree from a traditional liberal-arts school implies more than that.
And don't forget the ever-important skill of filling the annual self-appraisals and other HR emitted bullsh!t. You know, your salary doesn't depend on your development skills, but your stylistical talent, shamelessness and rectal alpinism skills. Mostly things you were supposed to learn in school, but tried to escape from by specializing in something computer related.
Jenda
| XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented. |
1. communicational skills
I had 14 years of formal English language training before I even reached university. I worked on group projects, learned brainstorming techniques, and was forced to deal with general group dynamics long before I hit university. So was everyone educated in my country -- unfortunately, the workforce doesn't just consist of people with the same background and education as the native citizens here. This re-introduces a communications barrier where none existed before. Short of training in every concievable language, there's little that can be done about it, however. It's not the fault of the education system.
2. organizational skills These were formally taught to anyone who wants to take a class in them at my university; they were informally taught by forcing students to organize their time in order to meet workload demands.
3. stamina You've got to be kidding. One of my friends was working up to 80 hour work weeks for Corell during his co-op work terms. He considered it a break from the stresses of school; doing a double major in CS/Applied Math with sufficient grades for grad school had him averaging 4 hours of sleep at night.
4. appropriate dressing This is an interview question, not a cultural absolute, and it's taught in the interview skills handout that you learn in a decent co-op university. Some places have a strict dress code where programmers wear a suit every day; other places, they wear t-shirts and jeans. Wearing the wrong attire in either environment is a cultural faux-pas.
A decent education teaches you all of those things.
http://www.theregister.co.uk/2006/01/11/grads_say_courses_no_good/
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
This seems to be the New Hot Thing : school, college, university should teach you a job.
That's mere utilitarism at best, stupidity most probably. You go to university to get a culture and learn thinking. Hey, if you want to learn a job at school, be a mechanic, a plumber, or even a lawyer ! By the way, all three pay much better than computer programming or whatever job you won't learn at school anyway.
These people (and naturally these are broad generalisations) tend to deal with real world problems rather than complex, but still lower level algorithms. They've been asked to do things like "build a system that keeps track of our company's inventory" (and all the many considerations this involes) rather than "optimise algorithm x".
So I think their skillset is much more than source control and testing (which I'd put in the 'overlap' category - I don't think either CS or Real World people will get far without those). Obviously, it depends on what kinds of systems you're building, and what work environment you're in as to which is the most useful.
sorry, to say it, but you missed probably the point. All your categories include the word "knowledge".
As for me, what really counts, is the ability a) to use knowledge and more important b) to acquire knowledge as necessary.
Another point of my critics is, that in general the so called practioneers use ideas thet were purely academical 20 years before. Personally, I can remember times when "object-orientation" was something purely academical which some real-world agnostic adepts of CLOS and Smalltalt used for brain damaged activities.
- New graduate.
Will use the tools, procedures and methods prevailing within the shop they join.
This includes all the classical tools of development; editors, IDEs, build tools, source control, test tools, design tools, documentation tools, etc.
They may have acquired an editor preference, and if they see another developer using that editor, or some other "non-standard" editor, they may be bold enough to enquire if they can use their preference.
They would be somewhat out of their depth, and generally won't be asked, to set up an new project from scratch, or to specify a complete project or major sub component on their own.
- 3 to 5 years after graduation.
They will have acquired a list of grouses that exist with the existing tool sets.
They may have looked around and possibly tried, either at home or in some small corner of their work, a few alternatives to the prevailing setup.
Will have probably been responsible for setting a new (sub)project from scratch, though they will have a tendency to stick fairly closely to what they know works, which in turn will tend to be what prevails locally.
Will probably have done the data gathering, and possibly drafted specifications for substantial sub components.
- 5 to 10 years experience (not necessarily graduates).
Will probably have been exposed, through changes of employment or personal experimentation, a reasonably wide range of alternatives for most tools, and will have acquired an, (often strong), opinion on which ones are best.
Will have setup new projects from scratch, including going to bat to get changes to the status quo authorised and accepted.
Will have performed the data gathering and produced several draft specifications.
Will have produced and championed a few full specifications.
Will generally be comfortable to perform all roles from designer, to analyst, to coder, to maintenance, to tester, for projects within their experience. Some will have acquired enough variety of experience to allow them to see the common elements and will be have the confidence to be able to apply them to new projects outside their specific experience.
Will probably have acquired some level of Project Leadership skills
- 10 to 15 years experience (not necessarily graduates).
Will either have made the transition to Project Leader/Manager roles; or if they really prefer the coding side of life to the management side, they will have become generalists capable of handling most aspects of the job, but will have probably specialised into one particular area: analysis & design, project leadership; testing & deployment; pre- or post sales support. A few that really only enjoy the coding side will have become highly proficient and productive coders, though these often strike out on their own by this stage.
- 15+ years experience (not necessarily graduates).
Will usually have acquired a wide range of experience across project types, development methodologies, languages and tool sets.
Will have
- experienced the highs and lows of project success;
- been subject to both good and bad management regimes;
- been subject to, and seen the effects of untimely and uninformed non-developer, management decisions;
- be extremely wary and skeptical about the latest, greatest, super-hypebolic development paradigm/language/toolset magic bullets;
- have acquired a distinct feel for what works and what doesn't;
- will have a desire to be in control of how things are done;
- will have formed some strong opinions about most areas of the job;
- will have developed a desire to not just be a part of a project, nor even just be in control of a given project, but to look at the ways and means of improving the entire project development process.
They will have a hankering to start a project to look at the entire project management and development process itself. Not just run this project or that project well, but to look at ways of making the entire project development cycle better, from the way the project is run; to the way the tools that are used are chosen, work and interact; to the way the project owner/commissioner and the deveopment team cooperate; to the way project team is setup, it's member are recruited, managed, and evolved.
Of course, if he ever gets his opus completed and attempts to present it to others, and one of those others happened to be himself, he'd be just as skeptical of this magic bullet as all the others :)
In the end, the biggest difference between the person with knowledge acquired through education, and the guy with the same or similar knowledge acquired or backed by experience, is that the latter will generally be quicker to select between alternatives and have less compunction to stick exactly to the "rules".
They will know better when to apply a particular algorithm or when to eschew "best practice" in favour of the expedient fix, especially when deadlines loom or crises occur.
They will tend to make decisions based upon their own experience rather than needing to consult higher authority for everything.
They will generally be capable of seeing their individual problems in the light of the bigger picture and will choose to react accordingly.
They will have a better feel for which of life's daily annoyances to go to bat over, and which to allow to pass with comment. They will also usually be better at choosing the right time and place to go to bat. They will generally be prepared to absorb their immediate problems and defer their innings, if those problems are acknowledged with regrets that no immediate fix is available/possible.
Like I said, wide bands and very broad brush strokes. Some acquire experience more readily than others; learn to recognise and apply knowledge more quickly; and some never do.
I'd put 'problem definition skills' as one of the most important portions of your overlap category. It takes real-world experience to see the relevant issues to be solved -- especially business-related 'relevant' -- but mapping those issues into an elegant computer-friendly solution takes a knowledge of what's available. For a light but pointed exposé of the dangers of limited real-world experience, see The 'f' in framework. The writer's most important point is that customers care only about solutions that solve their problems, not about elegance in programming and programmability. This is truly where the rubber (CS knowledge) must meet the road (the real world).
I've worked in many environments, including both those where I was peon and those where I was godlike, and my most important learning experiences were those in which my position was transformed by my own efforts into the opposite of those just mentioned. Having gone both ways, I'll have to leave you with my most important real-world
Don Wilde
"There's more than one level to any answer."
I disagree with your breakdown in general.
CS is not about programming. CS is about math.
Confusing the two is far too common in our field.
Source control is a programming issue. Data structures and algorithms are a programming issue. A programmer should know many algorithms and many datastructures, and should be perfectly at home working with new versions of either. A good programmer needs to understand sufficient CS to "read the label" on a library or algorithm but doesnt need the skills to be able to "write the label".
I like the cooking/chemistry metaphor. If you are looking for someone to bake a cake you want someone who has had lots of experience in a kitchen cooking cakes, not someone who has never cooked a cake but who can synthesize vanilla from raw materials.
I also like astronomy metaphor. Computer science has as much to do with programming as astronomy does to the manfucture of telescopes.
I agree that a theoretical background is no replacement for experience and vice-versa. All too often, hiring managers want people with CS degrees, but have little care about the type of experience these candidates have in the real world. Often enough, people with real-world experience and little or no theory background (like me) are pulled into development because of short-term needs (and/or short-sighted management).
The latter was my experience. I have managed to do pretty decent work despite my lack of theoretical knowledge, and I have put a couple of green CS grads to shame. They've also taught me a few things. I think the real problem comes when your team lacks either theoretical or experiential skills, or when the two skillsets are too proud to listen to and learn from each other.
Unfortunately for me, theory is a little harder to learn independently. I don't believe that's due to the nature of CS theory, but due to a lack of good, accessible, beginner and intermediate CS theoretical materials. I'm always open to learning about key design patterns, standard data structures, etc. -- but it's hard to find that stuff if you don't know exactly what to look for.
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
Don Wilde
"There's more than one level to any answer."
I have managed to do pretty decent work despite my lack of theoretical knowledge, and I have put a couple of green CS grads to shame.
That reminds me of the time a CS intern came to work for the summer at a company I was at. He was very, very bright, knew several programming languages and was pretty handy at server administration. When the intern left, he told his father (friends with our boss) that he walked into our company convinced that he knew everything there was to know about programming and was just in college to get the degree. He left us absolutely amazed at what we could do and he was eager to intern with us the next summer. Only one person in our department had a CS degree. The rest of us taught ourselves.
Cheers,
Ovid
New address of my CGI Course.
He left us absolutely amazed at what we could do and he was eager to intern with us the next summer.
Something about working with -- or even just talking with -- truly excellent programmers does wonders for one's humility. I can still remember a few questions I've asked right here on PerlMonks which got answers that truly humbled me.
I think one of the best experiences a novice/intermediate programmer can have is to be humbled by those much better than them. I know it's helped me have a more open mind and pay much more attention to my own design and code. I'll have to remember to ask about those kinds of experiences when next I'm asked to hire developers. ;)
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
That reminds me of the time a CS intern came to work for the summer at a company I was at. He was very, very bright, knew several programming languages and was pretty handy at server administration. When the intern left, he told his father (friends with our boss) that he walked into our company convinced that he knew everything there was to know about programming and was just in college to get the degree
I too have had similar experiences. I've also seen the reverse where somebody without "academic" experience has been amazed by how a little type theory / some big O notation / knowledge of a problem being NP-complete, etc. has made solving a problem much simpler.
What matters is the knowledge. Where you get it? Feh - personally I don't care :-)
What pisses me off (and I know this is not anywhere close to what Ovid is saying - but since I'm in a mildly ranty mood) is the sheer bigotry of some people, whether from the academic or the industrial side, to what the "opposition" is saying.
I'm a CS guy who was completely forgotten red-black trees after about 5 years in the real world.
At least you had red-black trees. When I went to school, we didn't have any red, and we were lucky to get black. (Seriously, though I could guess it had something to do with binary trees the name 'red-black' wasn't made up until a couple of years before my Data Structures class, so the name probably didn't make it into the book we used, though I don't have the book anymore so I can't check).
If I try to store data terribly efficiently in some data structure, I'm probably be doing a premature optimization, something theoretical CS people also hate. ;-)
I mean, sure, I've got a mathematics background. In theory, I could look for some group theory to find me a nice hashing algorithm for a given problem. In practice, a sufficiently good hashing algorithm that's been coded and tested probably already exists; and it's almost certainly a waste of time to retread that ground unless I'm doing research in optimizing hash algorithms.
In general, there are three classes of CS problems - unsolved problems, on-going research, and solved problems. In general, businesses dislike betting their infrastrcture on unsolved problems and on-going research, so 99% of programmers will be dealing with solved problems. The correct solution to a solved problem is usually to download the code that solves it (if it exists), or code up the most reliable algorithm that's known to solve the problem (if no code exists yet).
Theoretical CS benefits many, many people: but that means that only a few really smart people actually need to do it. The rest of us just reap the benefits. I'm not smart enough to to PhD level cryptography, for example -- but I can certainly run the code that does, once my friends work out the algebra that underlies the algorithms.
So, in general, unless you're going to design a compiler, compiler theory isn't useful, except as an example of how to solve a complex problem. Multi-variate calculus isn't all that useful for doing the day-in/day-out work of making a billing system run. It's very useful if you happen to be working on a non-linear optimization research problem; but few of us non-PhDs are.
In general, real world knowledge is mostly what programmers need; the CS experts build tools for the rest of the world to use, and we need a lot less toolmakers than we do builders.
I guess my point is that I spent a lot of time learning the framework so that I could learn CS theory, but almost none of it applies to any job I've ever done. That's only for the Real Smart Kids (TM).
--
Ytrew
One major area of real-world knowledge I'd add is knowledge of the problem area. My background is engineering (both my degrees are in mechanical engineering), so my perspective is a bit biased.
My experience has been that many people with degrees which are variously lumped into "CS" are poorly prepared for work in engineering and scientific computation, which is predominantly numerical computation. Much of the programming in this area also requires familiarity with the ODE and PDE in general, which are taught in from which many students will run screaming.
emc
" When in doubt, use brute force." — Ken ThompsonMuch of the programming in this area also requires familiarity with the ODE and PDE in general, which are taught in classes from which many students will run screaming.Also known as students of WTF :)
What would you put in each group and why?
I hate groups, but that may be because I'm always hard to categorize. The greater mistake I think you're making, though, is that your categories are off. This has been mentioned a few times already. The definition of CS differs much depending on who's defining it. Some CS education is highly focussed on the mathematics side, some has a tendency towards system design, there are even institutions that would call your CGI course a typical example of CS.
Also, the distinction between "CS" and "Real world" doesn't exist in the real world. Whether it exists in CS again depends on the specific definition of CS that you're using. It's like the distinction between "theory" and "practice", of which fortunately more and more people say it's a useless distinction most of the time. If theory and practice are two different things, then mistakes (or assumptions, which are mistakes that you admit beforehand) have been made.
But if you do want to use categories, then always keep in mind that the people who are strictly in one category are the least useful for productivity. :)
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
This has kind of been touched on above, but bears expanding on.
A high-leverage real-world skill that I've seen lacking in fresh grads is the ability to make sure you're solving the right problem. This implies developing the ability to listen carefully and ask tactful questions, to spot gaps or inconsistencies in requirements and probe those gaps, and to resist prematurely charging ahead mentally on a design any further than you need to to probe the requirements.
I've seen quite a few fresh grads sink weeks into solving the wrong problem. I see this less often with experienced folks, which mean either that they've learned or that they've been culled from the development gene pool.
-
but stare at you blankly if you ask them about red-black trees.
I've been programming computers in one fashion or another since 1972. If you asked me what a red-black tree I would certainly give you my best impression of a deer in the headlights on a moonless night.
On the other hand, I've probably written the algorithm a bunch of times without any idea what in the world it is called.
I would honestly say that 95% of my programming skills
were learned through the school of hard knocks. Some of
that I'll confess was by stealing
copying other folks' code and tearing it apart to see
what made it tick.
My sum and total college experience was had first ehen I was at sea in the US Navy when they sent college profs out to us and suit cased the courses in. English Lit and math were what they brought to us. Then after I got out I took two more semesters of calculus and three semesters of computer science. That's it folks. The rest I learned by doing.
Perl I leanrned via a combination of "just doing it", reading many books and articles in trade journals (including nifty stuff from merlyn) and fine tuning at the hands of the Monastery.
I say all that to say this: folks who can walk the walk can't always talk the talk. They still know what they are talking about, but they just don't speak your language. I've interviewed many "bright kids" over the years that could talk the talk and sounded really good but were absolutely lost when shown a real piece of code that wasn't out of a college text book.
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg