Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by exussum0 (8885) on 2009.03.05 10:10 (#67703)

    * Communication skills (there's a reason I listed this one first) * Automated testing * Source control * Working in teams on new code * Working in teams on existing code * Multiple language paradigms * Complexity management * Usability * More that hasn't occurred to me in this brief write-up ...

    Computer science is as much about computers as astronomy about telescopes, right?

    Everything you wrote up here is explainable within a couple of days. Most of it requires lots of practice. Being disagreeable while being agreeable is a skill you learn elsewhere, just like manners.

    Most colleges teach using the pop language today, which to the fairness of the 3 schools I attended (looking at the course requirements), made up 6 credits out of 128, 8 credits out of 128 and lastly, 0 out of 64 credits required.

    It sounds like most of your point is not knowing their terminology. In the non-scholarly world, most of what we build or interact with is fairly common stuff. A forum has posts and replies. A letter has a thread of correspondence. It out lay it out on a table, you have multiple threads.

    When you talk about the theoretical complexity and classification, you have to use new terms. Describing them every time gets old, fast. The barrier to entry is knowledge. In your BS degree, you learn about the book. In your MS, you learn to read and enjoy the book. In your PhD, you learn to write the book.

    We've all done the business concepts to death. The next progressions are a) stagnate and branch out into other goals, like making lots of money or other fields like biology and applying it there or b) LEARN MORE.'

    I'll reiterate the list and demonstrate how silly these things are in comparison to real problems.

    * Communication skills (there's a reason I listed this one first)

    This is a tech writing and/or language of your choice Thing. We mostly learn this anyhow.

    * Automated testing

    There are 4 or 5 types of tests. These can be described within minutes. A day of practice, and you're done. This isn't a science problem, but a process problem that's being solved. You write stuff, you test it. You ensure you always make sure it works, even after changes to the target.

    * Source control

    File goes in, file comes out. Changes are tracked and copies are made.

    * Working in teams (snip)

    This isn't a computer science agenda. This is a life lesson.

    * Multiple language paradigms

    Turing complete. Any mess can be made in any language. Any masterpiece as well.

    * Complexity management

    Alogirthms teaches big-o notation and fundamentals. Anything much more beyond that usually requires a masters.

    * Usability

    UI usability? That's environmental psych. I don't usually rant like this, but c'mmon - a request to dumbing ourselves down?

    • Everything you wrote up here is explainable within a couple of days.

      I'd love to hire super geniuses like the ones you've taught, but unfortunately the rest of the world isn't nearly that capable. Some ten years in, and I'm still figuring out the nuances of automated testing.

      • Nuances are nuances. You do understand the principle points of it, eh? You're a bright fellow. Just like we all can do division, but the larger the numbers, the easier it is to screw up, and it takes time when someone does something screwy.
        • I can explain the principal points of functional programming to my five year old nephew in a few minutes, but even Abelson and Sussman spent more time on it at MIT.