By now, is there a person in the world who isn't familiar with the annual WMCSCI spamference and the bogus paper submitted and accepted by them in 2005? Well, technology has caught up, and now Nagib Callaos and the other folks who run this and similar conferences can click on the link from the title above to get information on automatic detection of bogus papers without all that messy and bothersome reviewing.
Wednesday, April 26, 2006
Friday, April 14, 2006
Following up on my previous posting about Money magazine ranking software engineering as the best job in America is the Reuters article linked from the title above. They've got more information about the methodology used, which seems to suggest that they didn't introspect very much regarding what produced their numbers.
For example, they list college professors second, but they lump together university and community college, part time and full time, tenure track and non-tenure track. The result, is a statistic that the average work week is 30 hours and the average number of vacation days is 31. But, as anyone who works in academia will tell you, full-time faculty work many more than 30 (or 40, or 50...) hours per week, and generally faculty don't get any paid holidays (other than national or state holidays). The low work week is probably a result of including part-time faculty, who I strongly suspect would like to work more hour but who can't (perhaps because their employers would then have to pay them benefits). I don't know where the vacation day figure comes from. Faculty typically don't teach during the summer, but then again they don't get paid then either, unless they have research grants (in which case they're working many more than 30 hours/week doing research).
On the other hand, flexibility and creativity assessments seem more reasonable. So, perhaps the frenzy of the dot com bubble being over, workloads and stress have become less of a factor in the software industry?
Posted by Michael Stiber | 4/14/2006 03:10:00 PM |
Wednesday, April 12, 2006
You may argue about the exact ranking, but not its presence in the top 10. It also ranks second in job growth rate. Of additional interest is the #7 ranking of computer IT analyst (ranked 7th also in job growth rate). Oh, and college professor is #2.
Friday, April 07, 2006
- I initially left the project wide open to student input; I would have been perfectly happy with any project they proposed, as long as it exercised the various topics we needed to cover. Failing that, I proposed what eventually turned out to be a simplified version of del.icio.us, except using hash tables, AVL trees, red/black trees, and graphs -- instead of databases -- for the back end. The project eventually developed an architecture with a back-end server (the bulk of the project) responding to CGI application requests. It actually is quite a nice job; I'm just waiting for a couple students to finish a "story of the project" web page (which I indicated was beyond the scope of the course itself) before making the URL public (just for looking; I won't leave the server running).
- Project management
- I am by nature a pretty hands-off person. It was not my goal
to micro-manage the project, and in fact I would have been happy
to have the students do everything. However, I couldn't make
that a requirement of the course, as it wasn't a project
management course. Instead, I gave them a lot of leeway, and
if they didn't take up the slack, I gradually tightened things
up and prescribed what they would do. So, at first things were
wide open, even including the project itself. Then, I specified
the overall project goal. I later led an in-class design
exercise, and broke the project down into subsystems and tasks
and farmed them out to teams. So, step by step, I produced more
specific directions on what would be done, by whom, and
when. Eventually, we had all of the elements you'd expect of a
project: milestones, interface documents, version control, team
meetings, group meetings, weekly reports (with required
reflection on successes, failures, what they were doing right
and wrong, and what they'd do differently the following week),
code reviews, etc.
Certainly, I could have done all of this from the start -- it's how programming assignments would normally be done in CS classes -- and more could have been accomplished. but I think there's value in students being given a chance to do something, see that one approach doesn't make much headway, and then see that an alternative given by me works. I think, as long as you don't allow things to get too chaotic or students to get discouraged, this is better than laying everything out at the start. We were still able to accomplish all of my essential goals, and that's all one can really hope for in one quarter (did I mention yet that the quarter system sucks?).
- I developed a rubric for grading student presentations and summarized it in my syllabus. These are undergraduate presentations, and so they of course can't be expected to be up to the level of presentations in a graduate seminar. Beyond the experience itself, it helped to give me clues regarding what topics to cover in more detail.
Take home message: size does matter. Smaller classes are better.