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"?"
PhysicsGenius is a boring troll who also steers clear of anything resembling style.
Tell me, PhysicsGeek, is physics_seeker@yahoo.com a real email address, or will any harvesters that pick it up from this post simply bounce their spam?
PS - Why the hell are the editors posting a dupe story when the submitter even gives the other Slashdot references?
If you are going to learn to program (and in today's economy, I actually don't recommend that) please steer clear of MIT.
Maybe I'm unique in my feelings about SE and programming, but I feel software engineering and programming to be quite different. I feel they are similar to a mechanical engineer and a machinist. The ME designs things, uses their knowledge of how things work (limitations of physical media [strength, size, weight/mass], timing of things, etc...) to design something. This design is then turned over to machinst, who although is skilled in their trade at making designs reality, does not (IMHO) add much to the product other than just making it. Don't get me wrong coders and machinists are highly skilled people and don't just walk in off the street. But, machinists who design do not always get the greatest of results - they are approaching the system from a completely different angle. Similarly coders who design (without formal design input, i.e. they were just young code monkeys) do not always make the best design of a system. Granted, with experience a coder will get to see many different designs and (through the likely maintainence phase) see how these designs worked - then this coder would work well as an engineer.
So, to take my approach and your input and put them together and that just makes the MIT course on software engineering sound better. If you want to have a good designer do not corrupt their mind too much with code (they do need to experience it to see how their cog fits into the system), and if you want a great coder do not bog them down with waterfall model, OO message passing, and other fundamental SE things (they do need to experience it to see how their cog fits into the system).
Wheeeee
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)
I agree. I went to MIT for 3 semesters and transferred to Penn State to finish up my CS degree. I was initially attracted to MIT because they do have a lot of prestigious alumni and faculty (Bill Gates, Richard Stalin, etc). I had been told the CS program was harder than pretty much anywhere else.
Every one of the CS classes I took was taught by assistant professors (who did little more than read from a book or powerpoint slide!). The TAs weren't particularly knowledgeable, either. In talking with upperclassmen, the big name professors only teach one or two classes a year, and only to graduate students. The rest of the time, they're too busy writing books and journal articles about procedural programming.
Anyhow, I transferred to Penn State. My CS professors have been much more involved, and have real world experience. If you've ever used a SCSI drive with linux, you can thank Prof. Englezak (who teaches a great linear computation theory class). He even has a grad student writing a dissertation on adaptive linux pipe overflow/deadlock detection algorithms.
- 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!
After working on a small government radar tracking project, I had a grad-level class with Prof. Daniel Jackson on Software Design. Unfortunately, I'm not academically brilliant, because it usually took me an hour of stewing on a knot in my stomach before I figured out why it was there. So, I always ended up questioning decisions after they had been made. With MIT's liberal drop policy, I dropped the course nearly at the end, but here was my general experience.
1) We were "improving" a NASA app that was having scalability problems
2) No one had even benchmarked the application to see what the bottleneck was. I didn't even know how to bring the app up.
3) The course was primarily for his graduate researchers so that they could get credit for their work and he was expecting near-full-time work from everyone. They obviously were spending a lot of time on it and discussing it outside of class, thus the others in the class were pretty well out of the loop.
4) I got the feeling that there was no real engineering going on. It was purely mathematical and analytical (i.e. let's do this in my new modeling language). (At least there wasn't any going on during classtime).
So, when the course was over, I had the general feeling that my 2.5 years of full-time experience being on a 12 man team creating an object-oriented radar tracking app from the ground up (including having a nearly identical performance problem!) didn't amount to a hill of beans because I couldn't express it in the right "terms" and didn't have an IQ of 250.
I'm not saying I was perfect in this. Just that you don't ignore someone with that much domain expertise.
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.
Shift the M five places to the right, and I'll tell you of the same horrible things happening to me.
I'm now at a community college. While there's still powerpoint presentations and stuff taken from a book, the instructors tend to add more to their teaching. Plus, I can actually ask them about stuff not listed in a book and get decent conversation.
Maybe it's because they hold positions in the real world related to what they're teaching. *shrug*
Not to rag on any schools, I'm sure some people find programs where you read out of a book just fine and dandy. But when looking at where to get an education, caveat emptor. Find out how the instructors teach before wasting large sums of money on something you could teach yourself.
...the one you know best how to use.
He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
So put him on ignore and stop replying to him.
Cover your eyes and click this link!