HUJI CS Department, and how it Affects Students

I am researching how the organizational culture in the (HUJI) CS department affects students. If you have thoughts, ideas, or an opinion on this issue, I encourage you to let me know.

The research is for a seminar paper I am writing on the Computer Science department (‘chug’) in Givat Ram, its organizational dynamics, and how they affect the students’ learning experience. More specifically, I am interested in how the various logistic, academic, and cultural structures existing in the CS department – as well as its interfaces (e.g. with advanced studies programs, with the high-tech industry, etc.) – affect the average undergraduate student.

I am interested in practically anything you can think the Chug (department) does that affects the student’s entire undergraduate experience, outside of the actual CS academic content studied. Arbitrary examples may include the amount of work expected of a student to invest weekly, Professor-Student relations, the size of the classrooms, various in/formal codes of conduct, existence (or lack thereof) of social activities/facilities, chug-organized meetings, Jewish-Arabic or male-female ratios & interaction, whatever.

So, if you have any thoughts on this; if you’ve ever said to yourself (or to your  friend, or blogged about it, or put a petek in the Kotel, you get the drift) “Man, because of so-and-so, my studies are this-and-that” – let me know! If your idea is useful, I’ll be sure to let you know and include your name in the bibliography, not to mention entering your name in a sweepstakes to win a Honda Cruzer ®.

On a personal note, I am very excited to be writing this paper, as this is essentially studying a topic I have a heavy personal interest in anyway.

There exists (surprisingly?) little literature on University organization culture; as often noted, this is not the least of which because universities, especially as they relate to undergraduates, have very unclearly defined goals to begin with. Are they about research? Educating their students for knowledge’s sake? Crafting the next generation of researchers? Making money? Doing what the state requires of them? This severely limits any possibility – some would say, any point – of researching how the inner organizational structure, dynamics or behavior affect that undefined goal. Furthermore, most existing organizational behavior work (including in Israel, including Gideon Kunda’s “מהנדסים תרבות”), has been focused on profit-inclined corporations, where both the collective and individual goals are much better defined than the university’s case, notably in the undergraduate case.

It is worth pointing out two major differences between normative organizations (who are usually the focus of organizational behavior studies) and what I purport to research presently:

1.       A university-student relationship is not an employer-employee relationship. The student is only part of the university (as an undergrad) for 3-4 years; this time limit is well-known ahead of time and affects both sides’ behavior. The student pays for his time, and his relationship with the organization resembles more that of a client than of an employee. In other words, the student is not effectively part of the organization; he is affected by the organization’s behavior, but has very little say in creating or affecting it.

2.      Due to reasons including the above (but also due to the fact that I am more interested in the individual than the organization itself), I am not going to research why the chug is/does what it is/does, but rather examine indeed what and how it does the things it does; effectively, I am planning (hoping?) to research and depict what the CS undergrad’s degree feels like, considering all things the degree consists of but the actual computer science itself.

So, to recap my main point: Do you have an opinion on how the CS department treats its undergrads – anything from how much the classes are heated to the age of the TAs to computer labs’ opening hours – let me know. Today is a good day for science!

Sella_vs_Monty_Hall

The following is the story of how I challenged the conventional academic wisdom regarding a known mathematical problem, resiliently tried it out ‘for real’ in the field, and discovered that – lo and behold – science was right, and I was wrong.

The reader (you) is probably familiar with ‘The Monty Hall Problem’. Most CS curricula approach it at some point, though usually as an amusing thought provoking exercise along the lines of “most probably two people in this class share the same birthday”. If you’re not familiar with it, the Internets are full of great explanations of it; I’d personally recommend YouTube for this one. For the rest of this text, let’s assume we all know what we’re talking about: Curtains, you choose, host opens all the rest but one, they’re empty – should you switch?

My own first encounter with said paradox was some years ago, in Cecil Adams’ excellent ‘The Straight Dope’, which in turn was commenting on Marilyn vos Savant (Guinness’s highest IQ!) approach to the paradox. Quite a confusing one indeed, as both Adams and vos Savant switched around their answers several times, not the least of which due to thousands of letters (from PhD-toters, no less!) claiming *both* sides of the argument. So, assuming you know what we’re talking about by now, just to make sure we’re all on the same page – the final score is it is decidedly better to switch. This is contrary to basic logic, and indeed I myself could (and have) make what I feel would be a compelling case to the contrary.

Since both Adams and vos Savant have been (by their own admission) confounded more than once on this issue, I did not feel as bad when this issue came up in data structures class (like I said, it was more going out on a tangent than any real relevance to CS material) and I simply could not fathom why switching is the preferred strategy, assuming the host has, as usual, opened all but one of the non-selected curtains, revealing them to be empty. I took it up with the lecturer (Prof. Dorit Aharonov), but to no avail – I could not be convinced, and science, science is rarely convinced. Her last piece of advice, by way of conjecture, was to write a program that performed ‘the game’, run it a thousand times, and see for myself what the results were. Words easily spoken than done – that is, for a first-year student, who would prefer to use his theoretically spare time for, say, breathing.

A couple years went by, and personal geopolitical motions have transpired – namely, my political ban on my favorite newspaper “Haaretz” (which is a matter for another post), which left me bored for meal-time reading material. A friend recommended and loaned a pop-sci book on game theory (in Hebrew, by Chaim Shapira, who is not perfect, but can certainly bring to life relatively difficult math theories. An poor Israeli man’s Malcolm Gladwell?), and over a Shabbat lunch I found myself rereading the same belated Monty Hall story, problem and solution – when given the choice, switch. Enough is enough, I decided – it’s time to do this right. No theories, let’s take this into the field; two years too late, I was going to settle this once and for all.

Having waited two years turned out, unsurprisingly, to at least considerably shorten the difficulty of the task of writing a software program to simulate such a Monty Hall game. Not the least of which due to having learnt Python, that quasi-magical programming language which, well, lets you do anything, easily.

So, basic program is:
1. Initialize array of X doors
2. Randomly ‘choose’ one door
3. Randomly ‘place prize’ in one door
4. Randomly open all doors but chosen one, and another one (with the prize, if chosen door != prize door)
5. Check to see if user should have switched, or not.

Bottom line – having written the (very simple) code myself, and having run it a few times, I am very proud (or rather, disappointed) to have discovered that indeed, the preferred strategy is simply to switch. Playing around with the parameters (namely, the number of doors) lets you easily see the expectancy how much more preferable switching is, and that is exactly 1/(# of doors). I.e., in the simple case of 3 doors, 1/3 of the time ‘not switching’ is better; 2/3 of the time you should switch. In the case of 1,000 doors – only 0.1 percent of the time ‘not switching’ is preferable. This is perhaps most intuitively explained as, instead of going through the farce of opening empty doors, just having the host let you choose between the one door you did choose and all the other doors together. In effect, of course, this is the exact same thing as the opening-then-suggest-to-switch routine.

Like I said, this is nothing new to science – the Monty Hall Problem has, for all it matters, been ‘solved’. It was, though, an interesting learning experience for myself – a see-for-yourself epiphany accessible only by toll & sweat.

I’ve shared my code here (http://sharetext.org/CZGS); you can (and I encourage you, if you feel the same about the MHP as I do). If you don’t have Python on your computer, you can also see, edit, and run the code here (http://codepad.org/lbh5VVHU) to get a feel-for-yourself.

Hooray for science!

Blogging is Good For You

I love New Year’s Resolutions. One of my resolutions is to go back to blogging more. Hear ye, my resolution this year is to blog at least once a week. I’m not sure many will be reading this, but that’s not really the point. Blogging is good for you. It is good on several levels.

This idea has been better explained elsewhere (one of my favorite’s is Spolsky’s #1 tip here), but to sum up my thoughts, blogging (intensively) will help you:

1. Practice your creativity. (Which like anything else, must be honed.)

2. Practice your English. (Assuming you are writing in English, of course.)

3. Practice your expressive skills.

Assuming any of these skills is important to you, you should be practicing it, and blogging is an extremely cost-efficient way to get that done. Its main downside (apart from inherent difficulties such as writer’s block, but for that, see point #1 above) is vague social anxiety at the “audience”‘s reception, but that’s just another (unintimidating) exercise in overcoming fear of public speaking, etc.

Perhaps the main issue is #3: Expressive Skills. You don’t have to be Shakespeare, but it seems the average level at which people are able to express themselves is downright embarrassing. The worst of it ESLers (non-native English speakers, writing in English), massacring non-capitalized “i”s, mixing up homonyms (its / it’s; their / there, etc), and general lack of basic grammar.

It is perhaps unfair to judge people in their non-native tongue. As a disclosure, I have personally have the simple good luck (in this aspect) to have been brought up in an English-speaking environment. (Incidentally, I also grew up watching a *lot* of American television, which though often considered a waste of time, I believe was extremely beneficial to early language absorption). However, anyone in any tech field knows, English is the language of technology. Not just in terms of one-liners; not just the alphabet used to represent symbolic variables in software code or single-word menu headers. English – especially written English – is the language of everything. System design specs – multi-page documents, at least – are in English. Business plans are in English. Any international interaction (integration, selling, etc.) is in English.

You should know how to converse in (written, at the last) English fluently. For more convincing examples of this need, see Spolsky, as referenced above. For practice, see your local blogging hosting service.

So go. Go out and blog. It’ll make you feel big and strong.