Diatribe

*Warning - ritual diatribe against MU's stinking system and its consequences follows.*

On Saturday, we suffered through our last exam - Software Engineering was the name of this final torture. Very useful subject, as far as the software industry goes. Unfortunately, it doesn't meld very well with MU's exam-oriented style(hell, nothing that really qualifies as engineering melds properly with it), so the whole thing just degenerated into another contest of memory. Predictable, but no less painful.

So far I've been under the impression that the fellas in charge knew that their system was fundamentally incompatible with the maverick field of computing. Maybe the inertia of this massive system was why they left it the way it is. Now I've begun to wonder if that was an overly charitable conclusion. Maybe they're just too dumb to realize it. Fine. Nuts to them - I'll be out of their organized insanity in another semester. There's no hope of fixing it, any more than there was of fixing the useless mess that they made of the secondary education system. These idiots are incapable of realizing that while memory and knowledge are connected, they are not identical.

Since I've been reading a lot of Joel Spolsky recently, I'll quote him on interviewing:

Just for fun, here is the worst interview question on Earth: "What's the difference between varchar and varchar2 in Oracle 8i?" This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of useless trivia and people that Fog Creek wants to hire. Who cares what the difference is? You can find out online in about 15 seconds!

The dudes who run our technical education are the kind who think asking questions like that one is a good thing. They can't distinguish between useless trivia and the kind of skill and understanding and knowledge that gets used in engineering or research. There is a place for that kind of trivia - if you work on anything moderately complex, you will eventually end up with a whole lot of little details like this in your head. I know dozens of obscure things(ask any of my bored-to-death pals) about dozens of obscure subjects, but I never sat and studied the damn things! They just stuck in my head as a consequence of a lot of reading.

To intentionally fill your mind with the kind of information that could be looked up in a minute is a slightly odd pastime, but perfectly acceptable. I've done it myself, on occasion. But to force it upon others is positively criminal. And to call it an education on top of that is equivalent to mental genocide. Sort of like those mad priests of the Spanish Inquisition who burnt 'witches' at the stake, and told them they were saving their souls besides.

In any event, there's nothing I can do about it. One strives to minimize contact with these people - argue too long with a fool and you'll become one yourself. Better to learn all the useful stuff on the side, like some of us have done. A lot of people will get away without any real skill, but in the long run, we geeks will have the last laugh. We always do. We did build this world, after all.

I remember this incident last year during CPLAB(Java) practicals. It was the first time I saw how a lot of my classmates wrote code. I knew they were bad, but I had never expected to see what I saw.

Our class was divided into three batches - A, B and C. For CPLAB, A and C had one teacher, and B had another one. Those of us who were in the B batch were considered lucky, since the prof had declared that we could use any language for the project. No prizes for guessing how many of them used VB...Not even 'good' VB - no COM, Web programming, or anything. Just the usual 'draw the interface, create a bunch of recordsets, fire a few queries, and display.' Me and Hrishikesh(Kolhatkar, not Thite) produced a fantastic Java project, but then we belong to the tiny minority that enjoys writing code, unlike most people.

The A and C batches had a more sensible teacher. CPLAB is basically a course in Java, so she declared that all projects had to be in Java. This made several people very unhappy, but it was the smart thing to do. Or so we thought.

It was right at the end of the semester, when the projects were due. The B batch had finished, but A and C were busy working away, struggling to finish. And then I saw how the other side coded. This is the general algorithm:

1. Figure out what you need to accomplish.
2. Search through the Java Complete Reference until you find a piece of code that does it.
3. Type it in, usually with only two fingers. This is where most of the effort was expended.
4. Struggle to debug it, wondering angrily why it doesn't work properly.
5. Call for help from me, Hrishikesh or Sagar(who was busy working on his own project and trying to remove a persistent bug that eventually became a feature).
6. Watch as the unfortunate debugger gapes in horror at the morass of contradictions that unfolds on the screen before them.
7. Thank the aforementioned debugger who staggers away having rewritten half the code, wondering what possessed him to help out.

Hrishikesh and I ended up helping so many people that we could have started a consultancy and raked in the moolah that day. I kid you not.

To be fair, though, there were a few who were actually trying to understand what they were doing. These people were more fun to help, but it's a headache without the javadocs. People, download the docs, for heaven's sake! You don't have to remember a gazillion obscure function signatures to be a good developer. They're all written down nicely for you. Documentation is your friend. So is Google. Use them, tinker a lot(this is very important) and you'll be coding cool stuff in no time.

For those who still have more than a year of MU engineering left, hang in there. Do the following stuff:

1. Read Paul Graham and Joel Spolsky.
   
2. Write code of your own. Learn another language. Try something really high-level like Python or Ruby.
3. If you don't understand C pointers, don't despair. Not every mind can handle the weird thought patterns involved.
4. Learn something about algorithms - you don't have to become an expert, but the mind expansion is well worth it. Try out TopCoder. Learn stuff at USACO.
5. For God's sake, read something more than your textbooks! You need sources for new metaphors if you want to improve your thinking.
   
6. Learn how to write fairly well - the best programmers are also fantastic communicators. You might want to get yourself a blog. It's a great way for blowing off steam too!
   

And the principle that underlies it all - Have fun doing it! This is the most important thing. If you don't enjoy computing, it might be best to get out early. (Wow, I sound like some guru handing out sage advice!)

Finally, don't pay too much attention to what I write. I'm just ranting most of the time.