Some old, some new.

coders

Bernie Cosell worked at BBN, writing code for the Interface Message Processors (IMPs), which connected the first two nodes of the ARPANET. He started as an application programmer but within a few weeks moved on to system programming and became the “czar of the PDP-1 timesharing system”. Of all the things to be a czar of... His first computer in high school, an IBM 1620, didn’t have arithmetic hardware. Even addition was performed with lookup tables.

His first project at BBN was a hospital communication system, between doctors and nurses on different floors. Debugging was pretty difficult, requiring flipping switches on the front panel and reading the lights that lit up. Bernie had a pager that would buzz when the system crashed, then he’d go to a payphone and call the hospital, and provide instructions about which switches to flip to fix the problem. Over the phone.

Bernie quickly developed a reputation as the guy who could fix problems nobody else could. But his secret was that he’d rewrite a lot of the trouble code without actually finding the bug. The potential danger is that you introduce more bugs by doing this. Bernie avoided getting in too much trouble because he was always very methodical, but he readily acknowledges that if you’re not careful you can leave things much worse off.

Some people should read Knuth, but probably not everyone. You need some understanding and feel for how different data structures behave, but it becomes tempting to use the cool stuff. “This is the ideal place to do an AB unbalanced 2-3 double reverse backward pointer cube thing and I always wanted to write one of those.” What does make one a better programmer is writing lots of programs.

The software for the IMP was written on a PDP-1, then printed out onto paper tape and fed to the Honeywell machine. Debugging was fun. I think in part due to the development process, they had the original source listing, but this wouldn’t exactly match the binary running on the machine. Instead, they would load a series of patches into the machine, but wouldn’t update the master image. They’d fix bugs by adding a jump, running a bit of code, jumping back, etc. They had paper printouts of the code, marked up in ink, but maybe not every copy of the printout had the same markings. That must have been delightful.

Bernie wrote Doctor, the ELIZA clone.

We return to the topic of rewriting. Don’t fix a problem by adding a specific fix if it doesn’t belong. By this, if the patched version of the function doesn’t look like it was originally designed that way, the fix is wrong. Code shouldn’t look like an accumulation of fixes, but rather the result of divine inspiration. I like this idea, which I’ve never seen expressed quite like this. Reading code, it’s very common to see little conditions sprinkled here and there to handle this or that edge case. The result works, but it’s very fragile. Can the code be redesigned to have fewer afterthoughts?

Keep an up to date mental vision of how a project should look. Nobody will approve time to rewrite everything, but whenever a bug is fixed, steer the code in the direction of the ideal version.

Bernie mentions that everything is more complicated now. You can do things that couldn’t be done before, but at the same time he’s stunned how complicated Tk is and how much code there is to make a button bigger or smaller. “I’m glad I can have a little bit of repute as having once been a good programmer without having to actually demonstrate it anymore, because I don’t think I could.”

founders

Hope you’ve got your shots, it’s viral week.

James Hong founded Hot or Not to settle a debate with his brother about whether a girl was hot or not. They started with their own pictures, but very quickly the site grew in popularity. Their bandwidth bill was going to be enormous. They quickly moved the images off site. Instead of submitting a photo, you’d submit a link to a picture on GeoCities, and Yahoo would pay for the hosting. That solved one problem for a while, but as the site grew they needed better hosting. They called up Rackspace and asked them for free hosting in exchange for exposure. This worked. Then another startup, Ofoto, wanted to host the photos because it would drive traffic to their site. So they went from paying for hosting, to free hosting, to getting paid to host. Nice deal.

HP’s first product was a bowling foul line indicator. (Fact check: true enough.)

James Currier founded Tickle, an online quiz site. He was in business school and looking at the big internet companies, and they were all focused on replicating existing media. “For example, Spinner.com was putting radio online, and they got sold for $340 million. I thought that was crazy.” Dude, they put radio on the internet! One day in school everybody took a personality test, and when the results came back everybody talked about it for weeks. James decided he could make such tests available to everyone. Old media tells us about other people, Tom Brokaw, Tom Cruise, but doesn’t help us know them. The internet was a new medium that would let us learn about people we know.

The first tests were designed to help you find a job, or pick an SUV or a minivan, or make other life choices. Seems like a far cry from the which color smurph are you quizzes popular today.

James had some difficulty selling the idea at first, because nobody wants to be the first. They want to see what everyone else does. Eventually he worked his way to getting a term sheet, and suddenly he was getting acquisition offers, even though nothing else had changed.

The various scientific tests weren’t really attracting many users, but James remembered that advertisements with dogs and babies are more memorable. “Let’s do a test for what kind of breed of dog you are.” And so it begins. Eight days later they had a million users.

man-month

A review of the propositions of the original Mythical Man-Month in outline form. “If this is all the original book said, why did it take 177 pages to say it?” Indeed, the whole book is here, but it’s not actually that useful without the accompanying prose.

One notable correction made is the assertion that developers should always have complete access to review the internal implementation of the components they use. Brooks has reversed his position, and now favors encapsulation.

As a checklist, I think there could be some benefit to regular review. There’s too much material in the book to remember it all all the time, but the outline makes it easy to identify ways to improve processes.

pragmatic

44. Write documentation. Internal documentation can take the form of comments, which should explain why something is done. The code itself explains how it is done. Keep a single authoritative source for things like database schemas instead of repeating them. Use markup languages that allow producing output in a variety of forms. They mention that it’s bad for programmer to throw material over the wall to technical writers, but don’t provide an alternative.

45. Manage expectations. Actually, they don’t like this phrase as elitist. Instead, work together to come to a common understanding. But really, that just sounds like a nice gloss on dealing with an unreasonable user. I don’t think it’s easy or automatic, so perhaps manage is the right verb.

46. Take pride in your work. Sign your name to it. But don’t be jealous.

code

Numbers are numbers, but floating point is floating point. There are lots of kinds of numbers, like fractions, irrational, transcendental. Binary coded decimal is a convenient way to handle fractions like dollars and cents with a computer. It’s an example of fixed point. When using fixed point, though, you need to know what range of values will be represented.

Remember when you learned about scientific notation? We can write big numbers like the earth is 4.9 x 10^11 feet from the sun. This splits the number into a fraction part, or characteristic, or mantissa, or significand. That’s the first number. The number after the ten is the exponent.

Now let’s take a number and chop it up into a series of negative powers of two. This gives us a binary point representation. And now we dissect IEEE 754 floating point numbers. Sign bit, exponent bits, significand bits. Do not use floating point for money. It can be difficult to calculate results for functions like sin(x) using floating point because the infinite series is infinite, but if you know what you’re doing you can stop after twelve terms for 53 bit precision.

Once upon a time, floating hardware existed on a special coprocessor and you had to write special code to use it. We’ve moved on a bit since then.

coda

A lighter set of chapters. James Hong also provided some dating tips (don’t date crazy girls even if they’re hot) but it’s probably not relevant to one’s programming career.