Slashdot Mirror
Constructing a New College IT Curriculum?
slonkak asks: "For extra credit in my Management & Information Systems we were asked to redevelop the IT curriculum. Interning at a government organization for the past 5 years, I have a good idea of what I'd like to know graduating from college. Here are the two tracks I came up with. Does anyone have any suggestions on how to improve this curriculum? I would like more experience members of the Slashdot community to give their input on what they would like to see new hires have a good understanding of." Yes, this one may sound like Slashdot-Do-My-Homework, but the underlying question is still worthwhile. For you IT Managers out there, what do you expect someone with a college degree to know? For you prospective CS Students who might be reading, what would you like to learn while obtaining that degree?
In looking at the two programs outlined, I noticed that they somewhat focus on training for specific products (VC .NET, 2003 Server, Cisco Routers, etc.) rather than underlying theory and principles.
.NET" but rather "experience programming C++."
As the owner of a small business who sometimes looks to hire developers for specific projects, I would probably not hire someone coming from this type of curriculum. In contrast, a programmer with education in principles could likely learn VC, gcc, VectorC or whatever compiler tool best suits the project. To this end, I would not put on my job search documents "experienced in VC
Computational Chemistry products and services.
The curriculum that you have posted sounds like something out of DeVry or Chubb and not something that you'd find at a college. Instead of having particular courses in .NET/Java/C++, have generalized data structures and algorithm classes that teach the basics of low-level software design and hammer the importance of efficiency home.
Having theoretical coursework may seem lame and not usefull post-graduation, but they often teach the concepts that are the most used in a CS position. These concepts can be enforced with projects, homeworks, and, most importantly, through internships or co-operative education experiences.
I am a computer scientist in the defense industry and I have seen other 'computer scientists' with degrees from schools whose curriculum approaches what you are proposing. They have a lot harder time thinking in terms of the problem and are 'hard-wired' to use certain technologies to solve every problem. They rely on the SKILLS they were taught in college rather then on the KNOWLEDGE they learned through theory and the application of the theory through constructive coursework.
Here's a link to the current CS curriculum of the school I attended, it has changed a lot since I went there but the focus on theory and knowledge is still present.
When I was in college, seems all we did was install things, set things up, put things togeather. Now here's a crazy idea.. break a system/network/router/etc.. real good, then give it to the students to figure out why it's broken. This could be improperly installed hardware, missing system files, broken network cable, the possibilities are endless.
Since I graduated, I do a lot more 'fixing' than I do setting up things.
For you prospective CS Students who might be reading
Ho ho ho now, Computer Science is very different from Information Systems/Information Technology.
What the hell? This is just a product training course.. not an IT curriculum.
An IT curriculum would look like
* introduction to programming (some intro language)
* statistics or some numerical mathematics course
* data structures
* concurrency
* operating system design
* database design
* artificial intelligence
* network topology and routing theory
etc.
It's 10 PM. Do you know if you're un-American?
The things that one should learn at college should be more permanent. Learning a technology or other is irrelevant. And technology changes (a lot). Today is Windows and Linux, but in ten years, who knows?. Formal education should go to the basics. If you learn about networking, you should learn the difference between state-full and state-less protocols, and the two army dilemma. If you are learning about programming, you should learn about paradigms (several of them, imperative, functional, objects, etc) and, maybe, concurrency issues and stuff. If you are learning databases, the best thing is the relational model. Focusing on tools instead of concepts it's bread for today and hunger for tomorrow. Hope it helps, Aureliano
For Network Engineering, I'd expect to see courses on network topology principles (regardless of whether it's Cisco or not you're applying it to). OSI, TCP, IP, broadband networking principles, wireless technologies, security, cryptography, oh and security.
I'd also expect to see classes on the foundations of operating systems and the core aspects of them, how they work, why they work the way they do, etc. Also fundamentals of computer systems themselves -- how they are designed, where they are headed and how, etc.
How about the design and use of compilers in principle? How they work, why they work, why you use the syntax of C/Java/C# vs. something else.
In short, you're way too specific. These seem like courses I'd take to get a certificate in each, not a degree. You can have a C++ programming course with Microsoft Visual, but that should be up to the professor or the curriculum on top of it. I've been in C++ programming classes that allowed the students to use whatever C++ compiler they wanted, since it was the underlying programming priciples that were important, not that we knew how to navigate Microsoft's expensive interface.
Trolls lurk everywhere. Mod them down.
This isn't a CS curriculum, it's a trade school curriculum. Here's why:
/. can tell you that once you pick up the fundamentals of programming (which, fyi, takes years to come to grips with and more years to master), switching languages is as easy as learning syntax and a little about the internals of the language. C -> C++ -> Java -> Pascal -> Perl -> VB...all have the same fundamentals.
First off, don't have speicifics! College should make you learn to think, not make you learn what to think. It's trite, but it's true...the best curriculums expose you to new thought processes, new types of systems and new algorithms.
Why are you taking three semesters of 3 different databases? Have one course: Relational Databases, and take a week to explain the difference between the three. You aren't trying to get someone their certification before graduation.
Where's your fundamental coursework? Data objects? Operating systems? Comparitive languages? Learning how to write hello world? You need these courses as the backbone. Anyone on
Two semesters of Exchange? Why? Very few people actually need to know the inner workings, and buying a book for $50 is tons cheaper than two semesters. Teach this through network theory and protocols.
Historical courses...a history of software, hardware changes/design, the 'family tree' of langagues...these help students to flesh out why the smartest people in our field made the choices (some good, some bad) that they did. There were good reasons for creating what seem like God awful languages ((((Lisp/Scheme?)))) as well as needs that lead to developments like Perl and relational databases. Having a professor over the age of 50 who remembers the days before relational databases is a must...someone who worked on a team to write their own would be even better.
I liked the network theory portions of your curriculum, but there's way too much. A semester (maybe two) on the history of networking, TCP/IP and other protocols (why doesn't anyone use Token Ring anymore?), along with basic, cross platform client/server networking in C (if you can write it in C, you can do it in any other language IMHO). Don't have an entire semester of routers, it's just not worth it.
In general, the best curriculums require overviews and offer electives in specifics, typically available starting your junior year (after you've gotten your feet wet). As much as possible, stay away from specific, commercial technologies. Even though Cisco is the leader in routing, teach what routing is without using the name 'Cisco'. If the student is smart, they'll be able to recognize what Cisco did well and why becaues they have the theory to back it up.
--trb
IT people need to be able to read and write coherently.
I don't care if you're the best Java/.NET/C/whatever programmer on earth. If you cannot effectively communicate, you are not a very useful employee.
Conformity is the jailer of freedom and enemy of growth. -JFK
Look at RIT
it.rit.edu
IT can't be compressed into one track -- you need diffrent skills for diffrent parts. Your webbies will be diffrent from your DBpeople who will be different from your systems people who will be diffrent from your security people who will be diffrent from your HCI people: There's a lot to IT.
There's also a lot of overlap. (I haven't RTFA, sorry. Papers to write.)
1) IT people need to know how to program in a REAL programming language. Right now, we consider that to be java, but that's going to be an internal flamewar.
2) IT people need to know how to speak. Lots of communicatino courses
3) IT people need to know how to get requirements. Lots of HCI fundamentals -- interviewing, STDs, DFDs, etc..
Beyond that, look to RIT to get some specific ideas.
IT is not CS, and it isn't IS. We're happily in the middle.
OK, I'm not qualified to give an IT/IS curriculum outline -- What I DO feel qualified to do is suggest a generic CS outline.
As many other posters have pointed out, the outline presented reads like a trade school/training course outline: Learn Cisco IOS. Learn MS Win2K+3. Learn Linux (presumably redhat). Learn MS SQL Server, MySQL, Whatever. Learn VB. Lern Visual C++. etc.
Rather than tying students to a particular product, teach them genericly useful skills.
For example:
Now that they are well-versed in the basics you can start feeding them more advanced topics:
This course would include a BASIC discussion of security.
One of the most important things that any student - IS, IT, CS, Trade School, WHATEVER - needs to learn is HOW TO READ THE F***ING MANUAL -- The great failing of my school is that there are people at my level (seniors) who have been "using" the CS department's UNIX machines (Solaris) for almost four years now who do NOT know about "man" and "apropos".
The things employers (my employers anyway) look for are the ability to THINK and solve problems, and the skills to know where to look to find the answer -- Man pages, news groups, google, etc. are all resources that seem to be wasted on many of my peers. Not knowing where to look is a huge resource sink in the Real World, and will not be helpful to your chances of future employment.
/~mikeg
First of all it uses words like Linux, Windows, Exchange... Those are things you can learn by reading HOW-TO's on the Internet and O'Reilly books. Paying tuition for this sort of thing seems like a waste of money.
This may be a radical point of view, but I believe that one should only hire a teacher to learn things that one could not learn himself. An extreme example of that is playing a musical instrument - you can take 3 years to read all the HOW-TO's on piano playing in the world, and I will bet that a 7 year old who has a good teacher will play far better than you after the same period of time.
I rank myself pretty high when it comes to knowledge of computers and networking, and yet I never took any courses on Linux (or UNIX - Linux barely existed back then). The things that helped me most in my career were my ability to read, write, speak, listen and understand, experience in basic science (math and physics), my musical training, my study of foreign languages (English being one of them) and perhaps the few courses in programming (BASIC and Pascal).
You have to focus on skills that do not become obsolete - creativity, ability to think out of the box, persistence, patience, communication skills. And when it comes to spefic knowledge, learn history, science, literature - they are constants, their value does not decline with time.
The specific knowldge of "Linux", "Windows", "IOS" or "OSPF" etc. should be treated as "figure it out when you need it and foget it afterwards"
Are you trying to build network admins, system admins, user support personel, operations staff, or what?
I've actually thought quite a bit about this, as I used to work in higher education (user support, programming, system administration), and I believe that there are two key aspects that you're missing:
You also have to give the students some choices. You should have more classes offered than are needed to graduate, and designate them as core and elective.
I'm going to assume that a person is going to take 15 credits per semester, with there being 4 semesters for an associate's degree, 8 semesters for a bachelor's, and am going to ignore master's, and assume that those folks would be in IT management (MIS, or Engineering Management degrees).
I would want someone working on an associates to intern at least one summer, and a bachelor at least two. Also, work study [about 10hrs per week, qualifying for 3 credit hours per semester] for 1/2 their semesters. I'd prefer each of them to do their first semester in user services, no matter what the discipline, as system administrators need to have an appreciation for what the front line support has to go through.
Work study tasks might include such IT related tasks at the university as telephone support, supporting a computer lab, or being assigned to a specific academic or administrative department to handle their support issues. They might work inside the university's data center, helping with network wiring, configuring hardware and racking systems, but well, that all depends on the size of the data center.
They should be working with full time staff members, not left on their own, like overnight operators monitoring logs. [maybe as a paid job if they're known to be trustworthy, but not as part of work study]. For those doing user support, they should be able to escallate problems to other full time staff members, should it be outside of their scope.
Okay, this message is getting too damned long... Here's a few thoughts about classes. Which ones are core, and which ones are elective, and which go with which specialization can be worked out later. [some should be apparent] Not all of these would be 3 credits.
Well, you get the idea... There's so many more classes that you could teach. I haven't even touched upon hardware, and only barely on OSes.
Oh, and for the core c
Build it, and they will come^Hplain.
Back when I was in University computers were still a relatively new thing. There weren't any entrenched ideas about how it should be taught. And Microsoft was a decade away from a monopoly.
Consequently, we were taught computer science. No programming, not server administration, and most definitely not Windows. Very first class was Pascal, just to teach use the basics of programming. The next was assembler to learn the low level stuff about how computers worked.
Then the very next class was Algorithms and Data Structures I. We were to use C on BSD UNIX, neither of which we had been exposed to before. The first assignment was due in a week. This sink-or-swim method taught us two important lessons. First, language wasn't important. Second, it taught us the real-world skill of learning new stuff on our own.
After that the core classes were more data structures and algorithms, programming language concepts (where we learned lisp, prologue, ada and smalltalk, among others), and compiler design and construction. Others outside of the core included networking, operating system principles, etc.
I felt it was a well rounded curricula. But when I talk to recent University graduates, they're learning tech-school stuff like Windows, CISCO routers and Linux administration. While these are important skills, they're not computer science. If you want to learn a trade, go to a tech-school. Real colleges and universities are for education. Knowing the technical details of Windows might serve you for the next five or ten years, but learning the underlying principles of operating system design will serve you for a lifetime.
Aeronautic engineers don't go to school to learn about Beechcraft and Lear, so why are software engineers being taught CISCO routers?
Old Fart signing off...
Don't blame me, I didn't vote for either of them!