Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Beginning Developers: Free Course from MIT

michael posted about 12 years ago | from the crispy-brain dept.

Programming 34

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"?"

Sorry! There are no comments related to the filter you selected.

Steer clear (-1, Troll)

PhysicsGenius (565228) | about 12 years ago | (#4388389)

As the Cheif Scientist of a Big Name Physics Laboratory, I have to do a lot of hiring of physicists, janitors and programmers. 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. If you are going to learn to program (and in today's economy, I actually don't recommend that) please steer clear of MIT.

Re:Steer clear (0)

Anonymous Coward | about 12 years ago | (#4388441)

PhysicsGenius is a boring troll who also steers clear of anything resembling style.

Tell me, PhysicsGeek, is 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?

Re:Steer clear (1)

heliocentric (74613) | about 12 years ago | (#4388533)

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

Worst in what way? (4, Insightful)

GuyMannDude (574364) | about 12 years ago | (#4388718)

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.


Sorry, some examples (2, Troll)

PhysicsGenius (565228) | about 12 years ago | (#4388832)

  • Their declarations are always global (I think this comes from living in The Hub)
  • They invariably want to use Microsoft products
  • They use C++
  • Their array initialization routines are almost always O(n) instead of O(log n)
  • They never shower

Re:Sorry, some examples (1)

GuyMannDude (574364) | about 12 years ago | (#4388859)

They invariably want to use Microsoft products

Okay, you've convinced me! :)


Re:Sorry, some examples (2)

mbadolato (105588) | about 12 years ago | (#4389438)

Their declarations are always global (I think this comes from living in The Hub)

Always? 100% of the time? 100% of the MIT students?

They invariably want to use Microsoft products

so? You don't like them, but someone else does... that makes them a crappy programmer?

They use C++

Ah so because they use a particular language, they suck. Right. Of course, you fall into the same trap by essentially stating that C++ sucks, and offered nothing there eithe.

Their array initialization routines are almost always O(n) instead of O(log n)

ok, so they suck as programmers because of how they initialize arrays

They never shower

and body odor has exactly what to do with programming ability?

Honestly, you say the MIT programmers are the worst you've seen, and those were the best examples you could come up with?

Re:Sorry, some examples (1)

styrotech (136124) | about 12 years ago | (#4389762)

and body odor has exactly what to do with programming ability?

I think it's the effect it has on other peoples programming ability that might be the problem :)

Re:Sorry, some examples (1)

LordNimon (85072) | about 12 years ago | (#4389491)

# Their array initialization routines are almost always O(n) instead of O(log n)

I may be setting myself up here, but how do you initialize an array in less than O(n)? You have to write to each array element at least once to initialize it, and that's O(n) at a minimum.

Re:Sorry, some examples (1)

larry bagina (561269) | about 12 years ago | (#4389939)

  1. int numItemsInArray = 0;
  2. Use SIMD instructions (AltiVec/MMX)
  3. Use a multiprocessor machine [with a limit of O(n/u), where u = # of processors].

PS - you did set yourself up to be trolled.

Re:Sorry, some examples (1)

LordNimon (85072) | about 12 years ago | (#4390089)

1. That doesn't initialize the array, it just initializes the array count. And it's O(1), not O(log n).

2. Still O(n), not O(log n). Using SIMD instructions makes it faster, but doesn't change the order. Remember, O(n/4) is really the same thing as O(n).

3. Same deal. You're dividing n by a constant, so the order is the same.

Physics Genius is a troll. Every time he posts! (1)

xintegerx (557455) | about 12 years ago | (#4400038)

So put him on ignore and stop replying to him.

Re:Steer clear (1, Insightful)

Anonymous Coward | about 12 years ago | (#4389157)

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.

Glad I'm not the only one. (0)

Anonymous Coward | about 12 years ago | (#4391856)

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.

Re:Steer clear (1)

WillyElectrix (306880) | about 12 years ago | (#4394751)

I was initially attracted to MIT because they do have a lot of prestigious alumni and faculty (Bill Gates, Richard Stalin, etc). I believe that both Gates and Stallman went to Harvard as undergrads. But many a famous CS brain has passed through the 'Tute. One has to remember that CS as an undergrad major is relatively new at most universities and many schools have a mix of CS-like majors (computer engineering, computer information science, etc) under the auspices of the schools of engineering, arts, or business, each with its own set of requirements and objectives. Some schools require their majors to take theory classes (e.g. automata, formal language theory) while others require heavy software development classes. In other words, there doesn't seem to be much standardization at the undergrad level and its to one's advantage to shop around and talk to some alumni and current students. At LSJU, we had regular instructors who were generally pretty good at pedagogy. The exercises weren't always "real world" but they were interesting. I had a couple classes with Really Big Name Profs and they were horrible. -d.

not impressed (5, Insightful)

jilles (20976) | about 12 years ago | (#4388698)

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.

Re:not impressed (1, Interesting)

Anonymous Coward | about 12 years ago | (#4389336)

You're absolutely wrong.
As someone who took the course, I can tell you at least 3/4 of the time was spent in things other than coding.
Documenting, Design, etc.
At the end of the course there is a "large software project" that takes about a month to complete and fairly accurately simulates working in a company type atmosphere.
The course is definitely not all about coding.

KLOC fuzzy (3, Insightful)

Tablizer (95088) | about 12 years ago | (#4391242)

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.

Re:KLOC fuzzy (2)

jilles (20976) | about 12 years ago | (#4392529)

I know size is a relative meaning. KLOC is the best measure there is, unfortunately. Anything else quickly gets domain/technique specific. However, what I'm trying to point out is that most systems you are likely to encounter during your study are small systems that can be constructed by one or two programmers in a matter of days or weeks at most.

In real life you encounter systems that take months or even years to complete by larger groups of people (I've seen cases where 300 people were working on a system for four years before the first release). University does not prepare studens for that kind of scale. Software engineering is about letting methods and techniques scale to build large systems in a predictable, controllable way.

When did they replace CLU? (3, Insightful)

Gerry Gleason (609985) | about 12 years ago | (#4388778)

When I took it, the language was CLU, which is closer to Java than anything I have seen before or since. It seemed much easier to grok than Java, but maybe this was because I was young and my brain still somewhat empty.

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.

Very desapointing (-1, Flamebait)

Anonymous Coward | about 12 years ago | (#4388833)

I attended the free course from MIT, and to my displeasure, they were not handing out free sandwiches. The MIT staff ignored my complaint, it's not like I wasn't yelling loud enough! I don't recommend this course to anyone.

The basics of /what/? (3, Insightful)

devphil (51341) | about 12 years ago | (#4388865)

it covers many of the basics of software development, from OO to testing to documentation.

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?

Re:The basics of /what/? (0)

Anonymous Coward | about 12 years ago | (#4388912)

Like what, changing your diapers?

Re:The basics of /what/? (2)

Gerry Gleason (609985) | about 12 years ago | (#4390579)

In spite of the comment you quote, this is not an intro course. It is a lab course that usually isn't taken until the third of forth year. The studend should know something about OO by the time they get there.

black art? (2, Insightful)

Tablizer (95088) | about 12 years ago | (#4391189)

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:

The best tool is often... (1)

jeko (179919) | about 12 years ago | (#4392631)

...the one you know best how to use.

Re:black art? (0)

Anonymous Coward | about 12 years ago | (#4401634)

Basically, NEVER use Java or C++ style "OO". At a pinch, use Smalltalk or ObjC. But If you want proper OO, you'll have to bit the bullet and learn the Common Lisp Object System (CLOS).

A major problem with "OO" as the Java-zealots see it, is that methods are specialised only on type of their first argument (the bit before the dot in the Java syntax arg1.method(arg2, arg3, arg4); )

It's "single dispatch". What you want, what you need, IMHO, for useful OO, is CLOS multiple dispatch. Where eating a pie with a fork can give a different result to eating a pie with a spoon, without having to pass an object of type "implement" into the method and have case (type-of implement) code to procedurally emulate multiple-dispatch on an ad-hoc basis.

CLOS allows what I like to think of in java syntax as (arg1 arg2 arg3 ...).method(arg4, arg5, arg6, ...);

That is to say, a method does not "belong" to a single class, but to a "relationship" between classes.

Much more powerful than Java OO, and mirrors closely the noun/verb relationship in natural language.

Eh... (4, Interesting)

rixstep (611236) | about 12 years ago | (#4389319)

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

Re:Eh... (0)

Anonymous Coward | about 12 years ago | (#4390386)

This is not a a first course in programming. Granted, I see nothing on that page or a click away that would tell you what level course this is, and that is clearly a shortcoming of the page. On the other hand, why did the original poster and michael assume this is a beginning course? I just happen to know it's not because I'm an MIT course 6 graduate, who took 6.170 junior year, a pretty normal place for it in the curriculum.

You want beginners to get a good overview of computer architectures and how they relate to software? Fine, that would be covered quite thoroughly in 6.001 [] and 6.004 [] .

Re:Eh... (2)

Tablizer (95088) | about 12 years ago | (#4391288)

I think we had this argument before. IMO it probably would not have affected my development style much if I never had exposure to assembler and lower level stuff.

The only exception perhaps is internal data representation of strings, numbers, and the like. But beyond data, assembly and machine code training did almost nothing for me.

If I went into assembler or tight embedded stuff or stuff in need of high optimization, it would perhaps made a difference, but I don't think it does when using 3rd+ generation langs and tools.

I wish instead I was taught more formal set theory and relational theory. But, they did not have that then.

Re:Eh... (0)

Anonymous Coward | about 12 years ago | (#4395002)

I've taken this course at MIT and I think your comment reflects a certain misunderstanding of the curriculum. The course is designed to teach basic software engineering techniques, not to teach about hardware, etc. For that, there is another course, called 6.004, that every MIT EECS student has to take. You design your own computer, learning to do it from transistors all the way up to assembly language. I imagine that 6.004 will eventually find its way online.

Cough, cough (2, Funny)

Wonko42 (29194) | about 12 years ago | (#4389564)

That girl in the photo is really cute. And she's wearing glasses!

I Had Daniel Jackson (1, Informative)

Anonymous Coward | about 12 years ago | (#4389760)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?