Slashdot Mirror
Beginning Developers: Free Course from MIT
arrogance writes "Yes, this has been posted on /., and on Wired (five days after the /. story). But there are occasional postings on slashdot about Where to Start Learning to Program. There's a software engineering course at the MIT site that looks like it covers many of the basics of software development, from OO to testing to documentation. It also deals with a team based project end-to-end, which is a great way to learn, but it might be tough finding two or three like minded people to take the course with. Has anyone tried these courses? Are they any good? Have any slashdotters (is that a word?) taken the course "live"?"
As a Ph. D. student in a software engineering research group, I'm somewhat knowledgeable about software engineering education. I must say I thought the course is a typical example of a course compiled by someone who has never been involved in a project larger than 'hello world'.
The biggest misconception here is that software engineering somehow is about programming. In a large scale software project, the actual programming is only something like between 10% and 20% of the effort. The rest goes into negotiating requirements, design, testing, planning, dealing with the fact that there are multiple people involved (i.e. project managers, customers, designers, marketing, other programmers). Actually convincing students that this is true is a huge challenge, most won't find out until after they are working on large industrial projects.
This course only prepares them for the 10-20% of coding. Like a good academic course it has a strong focus on designs (I have never seen a large industrial scale software project with up to date, detailed designs) and the actual programming concerns small toy programs. What it doesn't prepare them for is large scale software (>=100 KLOC) various development methods, various testing methods and their flaws, maintenance (very few projects actually start from scratch), projectmanagement, the fact that customer requirements will continue to change, internal and external conflicts about who does what and when, etc. Various very thick software engineering books exist (e.g. Sommerville or van Vliet), implementation is not the main focus in those books.
"An introduction to OO modeling and programming" would be a more appropriate name for the course.
A proper Software Engineering course involves letting large groups of students work on a medium sized project (for example provided by local software companies) and teaching them about the principles of software engineering (using e.g. the books mentioned earlier). Even that won't prepare them fully but at least they will experience strugling with deadlines, colleagues, changing requirements and interacting with customers. We have done just this in the past two years at the university of Groningen in the Netherlands.
Jilles
While MIT is an adequate school for physics or janitorial supply ordering procedures (though CalTech is really the best for both), without fail the worst programmers I see came from MIT.
I really hate seeing comments like this on slashdot. In what way are MIT grads terrible programmers? Dammit, give us some specifics, Man! I see so many of these fucking posts here:
"I am an expert for reasons X, Y, and Z. In my experience, thing Q sucks. End of message."
So we're just supposed to assume that your opinion will jive with ours? If you're going to make a sweeping statement like "MIT programmers suck" then you should at least tell us why you think they are poor. What exactly are they poor at (initial planning, writing efficient code, commenting/documenting)?
I don't know if PhysicsGenius is a troll or not, but I see an awful lot of messages written in this same style. People, please, when posting a message giving us your opinion, try to explain exactly what your opinion is. Big sweeping statements don't help any of us.
GMD
watch this
Actually, it was a new course and a new degree requirement when I returned to MIT after two years working full time. My advisor thought it would be good for me to take it even though technically it wasn't a requirement for me.
My actual advice to people who think they might benefit from working through this course online is to go work on an open source project that interests you. The reason is that all the important stuff in software engineering is related to "programmin in the large". If all your experience when you hit the job market is from coursework, you've probably never seen a problem with more that a few hundred or thousand lines of code. That's just the point at which this stuff starts to matter.
Because I had worked for two years, I had a much better appreciation than my classmates of what was important. I wish I knew that before taking the course because the lab course I really wanted to take was Doc Edgerton's strobe lab.
While I'm overjoyed to see that documentation is something that's being taught as a basic fact of development, not something tacked on in the third year as an afterthought, I'm stunned that people (whether MIT or the article submitter) think of OO as a entry-level concept to be taught to beginners.
Yes, OO is a great tool. Yes, so are most of the others. The right thing for the right job. But surely there are other concepts to be introduced first?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
- Required reading is a book on Java. To me, this is a helluva way to teach programming to beginners. They don't learn anything about the machines they're dealing with - and as a result, you're going to get more of the bloated and bugged output you have today.
I don't give a royal hoot about objects - not where beginners are concerned. How about register shifts, how about how an accumulator works, how about some frikkin assembler?
These people are being taught to fly and they can't even crawl. Major disaster.
That girl in the photo is really cute. And she's wearing glasses!
Yes, OO is a great tool. Yes, so are most of the others. The right thing for the right job. But surely there are other concepts to be introduced first?
Regarding "right tool for the job". One thing that I cannot get a consistent answer from OO fans (I don't like OO) is when to use OO and when to NOT use OO.
Of course extreme OO zealots are going to say "always". But the more pragmatic lot agree that OO is not always the best solution. But there is very little agreement on when this is the case. They often say, "You just have to get a feel for when and when not", as if there is *no* pattern to when not to that can be written on paper.
I find this odd.
Determining the "best tool" for the job is very dark art. Until they solve this, they should call themselves "software artisons" and NOT "software engineers" (SE). There is too much subjectivity, or at least lack of articulation floating around out there among SE celebrities.
(OO skepticism: oop.ismad.com)
Table-ized A.I.
What it doesn't prepare them for is large scale software (>=100 KLOC)
IMO, the "size of the application" is a rather *fuzzy* concept in a good many places. Where one "application ends and another starts" is often hard to tell.
Perhaps if your shop builds big giant EXE's for whatever purpose, then such is more clear cut. But if one is using interpreters or web apps, then there is no one single glob to measure.
Often there are many smaller "applications" (loosely used here) that all tie into the same central database. Do you count each little application, or is anything that uses that databases counted together?
If the first, then I would note that the size of the "app" stays relatively consistent regardless of the size of the database. The average might increase in size a bit because the schema grows more complex, but it is at a pace slower than the DB size in most cases.
Table-ized A.I.