Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

(OT) Real World Skills Versus CS Skills

by Ovid (Cardinal)
on Jan 23, 2006 at 20:01 UTC ( [id://525040]=perlmeditation: print w/replies, xml ) Need Help??

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.

  1. CS knowledge (e.g., compiler theory)
  2. Real world knowledge (source control)
  3. Overlap knowledge (basic data structures)

What would you put in each group and why?

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: (OT) Real World Skills Versus CS Skills
by GhodMode (Pilgrim) on Jan 24, 2006 at 09:06 UTC

    Everyone has an opinion, but no one has answered the question.

    Unfortunately, I'm not qualified, but I'll give it a shot...

    1. CS knowledge
      • Language Evolution
      • OO concepts and theories
      • compiler theory
      • Use-Case scenarios
      • Application Development Cycle
    2. 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
    3. 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
    
Re: (OT) Real World Skills Versus CS Skills
by fergal (Chaplain) on Jan 23, 2006 at 20:49 UTC
    Update: moved my comment to the top and off-site links to the bottom.

    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.

    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. 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.

      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. OTOH, purely functional programming per se was rather missing, but then, this was only a minor program, and one supposes that a major program would include it.


      "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
Re: (OT) Real World Skills Versus CS Skills
by BrowserUk (Patriarch) on Jan 24, 2006 at 12:41 UTC
    I think your categories are wrong. This is how I would categorise (using very broad brushstrokes):
    1. 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.

    2. 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. </l>

    3. 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

    4. 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.

    5. 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 without 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 commonalities and apply knowledge more quickly; and some never do.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: (OT) Real World Skills Versus CS Skills
by Ben Win Lue (Friar) on Jan 24, 2006 at 10:47 UTC
    I think you miss at least a fourth point:
        soft skills
    meaning things like:
    1. communicational skills
    2. organizational skills
    3. stamina
    4. appropriate dressing
    and so on. Mostly things you don't learn at school nor at work. I think the communication stuff is at least as important for programming/CS as everything you learn at school/university.
    Ok, if it comes down to dress code, you can live without it....

    cheers
    237

      Okay, I'll grant appropriate dressing; that's something your parents were supposed to teach you when you were in gradeschool. The other things you list are all things you should have had in school, and if not your college cheated you out of a proper education. How on earth can you get a B.S. or B.A. without taking at least a couple of communication courses? Where I went to school, they called that stuff "Gen Ed", and you had to take it irrespective of what your major was. (Indeed, a public speaking class was even strongly recommended at my high school; it ought to have been required, but I guess you can only expect so much from public schools in the way of requiring things, since they have to find ways to let the kids through who don't want to learn anything.) Organizational skills, unless you mean something different from what I take the phrase to mean, are something you should pick up (if you don't already have them) from various classes in varioius subjects. You *did* have to organize group projects in classes like philosophy and literature, right? Right? Surely you at least had to organize your own time and put together coherent research papers out of nothing more than a vague topic. As for stamina, how better to learn that than through the peculiar blend of sleep deprivation, memorization, and critical thinking that is college?

      update: What college doesn't teach you is how to read through somebody else's poorly-written buggy disorganized code that only barely works and grok enough of it to make changes without screwing things up even worse. CS programs really ought to have a class in that. Debugging and refactoring your own code is one thing; debugging and refactoring somebody else's code is another thing altogether.

        Ok, Ok, Ok maybe american schools and universities are just better than those I went to!
        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
        And I am quite sure that here in Germany you can get a CS degree with less communication skills than you need to order a meal in a restaurant. Ok, you have to be a genius...

        regards
        237

      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.

      You learn all those things in school; some of them in public/high school, and some of them in university.

      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.

Re: (OT) Real World Skills Versus CS Skills
by SamCG (Hermit) on Jan 23, 2006 at 22:47 UTC
    I disagree somewhat with the assertion that it's not possible to work from experience to theory. Certainly, it is easier and more common to gain the theoretical through formal schooling and the practical from work experience.

    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.

        I was referring to fergal's comment that someone familiar with theory can learn version control, etc., but "it doesn't work the other way around". Sorry, I should have directed the comment towards him.
Re: (OT) Real World Skills Versus CS Skills
by radiantmatrix (Parson) on Jan 24, 2006 at 15:48 UTC

    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.

    <-radiant.matrix->
    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

      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. ;)

        <-radiant.matrix->
        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.

      hear, hear! I think that there's a real problem in CS (at least, I've sure had one!) with theorists who start by defining their own language and depart from there. If you were not standing on the ground where they created that train station, you will never be able to travel with them. WikiPedia helps a lot; that's the best starting point I know of with its multiple definition links.

      Don Wilde
      "There's more than one level to any answer."
Re: (OT) Real World Skills Versus CS Skills
by Mutant (Priest) on Jan 24, 2006 at 10:50 UTC
    I think people with better "real world" knowledge (and that's not necessarily actual work experience, there are plenty of degrees around nowadays that don't take a classical CS approach), can potentially be better at higher level design and requirements gathering / analysis.

    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.
Re: (OT) Real World Skills Versus CS Skills
by samizdat (Vicar) on Jan 24, 2006 at 14:47 UTC
    With the caveat that I'm not a CS graduate...

    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 asset goal: humility.

    Don Wilde
    "There's more than one level to any answer."
Re: (OT) Real World Skills Versus CS Skills
by swampyankee (Parson) on Jan 24, 2006 at 19:14 UTC

    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 classes from which many students will run screaming.

    emc

    " When in doubt, use brute force." — Ken Thompson
      Much 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 :)
Re: (OT) Real World Skills Versus CS Skills
by dws (Chancellor) on Jan 26, 2006 at 02:14 UTC

    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 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 may mean that they've learned, or it may mean that they've been culled from the development gene pool after solving the wrong problem one too many times.

Re: (OT) Real World Skills Versus CS Skills
by inman (Curate) on Jan 24, 2006 at 09:35 UTC
    How about categorising your IT department headcount based on the software that the person has installed (and used) on their personal computer?

    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 think that you have made my point for me. Your company has employed you as a developer and made a significant investment in terms of buying software licences and equipping you with the tools to do your job. My hypothesis is that the presence of such a compiler on your machine places you at the more technical end of the scale.

        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.

      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.

      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. :-)

      Thank you for classifying me into the middle ground.

      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.

Re: (OT) Real World Skills Versus CS Skills
by g0n (Priest) on Jan 24, 2006 at 10:49 UTC

      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.

Re: (OT) Real World Skills Versus CS Skills
by dokkeldepper (Friar) on Jan 24, 2006 at 11:51 UTC
    Hi,

    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.

Re: (OT) Real World Skills Versus CS Skills
by Anonymous Monk on Jan 24, 2006 at 19:04 UTC
    What about the guy who answers "red-black trees? Isn't that yet another theoretical CS datastructure that I'll never actually code myself, because tonnes of people have written a more efficient version already?".

    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

Re: (OT) Real World Skills Versus CS Skills
by Anonymous Monk on Jan 24, 2006 at 17:42 UTC
    I'm a CS guy who was completely forgotten red-black trees after about 5 years in the real world. I've also forgotten how to do flux integrals. I could pick both up if required. This is an example, IMHO, about why technical questions on interviews can be misleading. If they can honestly explain they'd have to look something up, that's *totally* fine. You want people that can learn quickly and do good work (including work that involves making up *new* things), not just folks that are walking textbooks. Red-black trees? I probably forgot that a week after the datastructures final.
      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).

        I heard of them as "2-3 trees" before I heard the red-black name.

        ---
        alter ego of demerphq
Re: (OT) Real World Skills Versus CS Skills
by blue_cowdawg (Monsignor) on Jan 27, 2006 at 15:12 UTC
        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 was 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 L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Re: (OT) Real World Skills Versus CS Skills
by Juerd (Abbot) on Jan 25, 2006 at 18:21 UTC

    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. This means that "CS" shouldn't be part of any other definition, for that definition will then also be highly ambiguous.

    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. In theory, practice equals theory. In practice, we agree with that, because it's usually impossible to tell what's theory and what's practice.

    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' }

Re: (OT) Real World Skills Versus CS Skills
by Anonymous Monk on Jan 24, 2006 at 14:49 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://525040]
Approved by Old_Gray_Bear
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2024-03-19 07:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found