Learning computer science old school

When I attended the University of Maryland, our computer science courses were taught using a Univac 1104, fed batch-mode by punch cards. There was a room available with IBM Model 29 keypunches modified to produce the Fieldata format used by the Univac, but there weren't enough of them, so there was always a wait to use a keypunch machine. However, for last-minute quick fixes, there was one "express" machine, for five cards or less. There was always a line for it too, which moved slowly as people would hunt and peck in slow motion, then reject the card and start over. People would take ten minutes to punch a few cards!

So I acquired the habit of just going to the front of the line, and keying peoples' cards for them. I could blast through the entire line in a few minutes. As I was doing so, I'd point out errors for people, to save them the time of waiting in line again, or worse yet, submitting their botched job and waiting a couple of hours for it to fun.

Happily, people rapidly got used to my habit, and realized I really wasn't going to try to steal their homework.

After class class

When I was studying computers in school, the early courses were packed, and used as weed-out courses to reduce the student load in the higher courses to a smaller set of theoretically more appropriate students. However, I took issue with the courses that weeded people out by being taught poorly. Since there was no mechanism to test out of these, I had to go and take them too, even though I pretty much knew all the material.

I noticed that the lecture hall for my ForTran class was vacant after the class ended, so I'd stick around, and re-teach each day's lesson in my style to whoever felt like hanging around. I got a huge benefit from this, as teaching something is a great way to find out what I really understood and where I was on thin ice. The stuff I realized I didn't quite get either, we'd work through together. A win all around.

If you insist on my help, you're gonna get it!

A while back, my company was subcontracting to another company on a government contract. One day they called in a panic, saying the system wasn't working and I had to drop everything and get out there NOW. It was a couple of hours through DC Beltway traffic to get there, so I wasn't enthusiastic, but I didn't really have a choice.

So I showed up, found the guys with the problem, and they sat me down at a computer. This was running their test version of the system without our debug passwords installed. So I asked for the system password, only to be told it would take a couple of hours to find out whether I was even allowed to have it. "Ah, got it!", I crowed, hammering the keyboard like a maniac. "What's the database password?" Again, they said it would be a while before I could get that. A few seconds later, I chirped "Ah, I figured it out" and kept going. "What's your encryption key?" And so forth.

It turned out the problem was that the software, just sitting there doing nothing, would absorb 72 database connections, and each user session took six more. It didn't take many users before they'd hit the limit of 100 simultaneous connections. They asked me how to fix it, and I explained that they had two choices - rewrite the software to not be so profligate with database connections, or increase the number of allowed simultaneous connections. "How do we do that?", they bleated. I explained that the proper way to increase the number of database connections was to write a large check to the database vendor. They didn't like either answer.

I later heard that their security manager had been aghast at my "hacking" their system to obtain the passwords needed to do the job they insisted I come do instantly, and I was no longer allowed in their data center. Which was fine with me.