Beginning Developers: Free Course from MIT 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"?"
Re:Steer clear (Score:1)
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? (Score:4, Insightful)
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
Sorry, some examples (Score:2, Troll)
Re:Sorry, some examples (Score:1)
They invariably want to use Microsoft products
Okay, you've convinced me! :)
GMD
Re:Sorry, some examples (Score:2)
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 (Score:1)
I think it's the effect it has on other peoples programming ability that might be the problem
Re:Sorry, some examples (Score:1)
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 (Score:1)
PS - you did set yourself up to be trolled.
Re:Sorry, some examples (Score:1)
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! (Score:1)
Re:Steer clear (Score:1, Insightful)
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.
Re:Steer clear (Score:1)
not impressed (Score:5, Insightful)
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 (Score:1, Interesting)
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 (Score:3, Insightful)
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 (Score:2)
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? (Score:3, Insightful)
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.
The basics of /what/? (Score:3, Insightful)
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/? (Score:2)
black art? (Score:2, Insightful)
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)
The best tool is often... (Score:1)
Re:The basics of /what/? (Score:2)
Eh... (Score:4, Interesting)
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... (Score:2)
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.
Cough, cough (Score:2, Funny)
I Had Daniel Jackson (Score:1, Informative)
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.