This is part 2 in my series of how the Mac reminded me why I fell in love with software development, and why it still matters.
While reading Andy Hertzfeld’s anecdotes (and those of his colleagues) of designing the original Macintosh computer, I was inspired, inspired to take account of my own passions, the passions that these stories reminded me of. Today, I continue that list:
I love to create new patterns. I love solving problems through discovery, inventing that which has never existed before. (From part 1.)
I love applying principles in new ways. I love working with abstractions, and turning them into concrete expression. I love challenging the status quo, breaking through the limits of what everyone else says is “possible.”
My first computer-related job, at least the first one that anyone paid me money for. I started while I was still in high school, circa 1987, at a now-defunct small company, called “EFG,” who consulted on and resold name-brand universal life insurance. I ran the IT department. Actually, I manned the computer room.
(“EFG” stands for “Eden Financial Group,” which had at least one office in Dedham, MA. As I later heard, they fell apart shortly after I left. But I’m sure the one had nothing to do with the other. That company, by the way, has no relation to any of the other companies named “Eden Financial Group” that currently exist across the country.)
When I started, I worked with my predecessor, another student, who recruited me as his replacement because he would be moving away to college. One of the things we did there was to produce “illustrations,” that is, financial scenarios, what-if‘s, to show what would happen if a client took out a certain policy over a certain period of time and paid a certain premium into it, borrowed a certain amount against the face value during certain years, and so forth. Similar to the mortgage calculators you find online, except way more complex.
We had a spreadsheet that worked out all the figures—a Lotus 1-2-3 spreadsheet. And as I recall, this spreadsheet ran a script that prompted for the various inputs that it needed. And then we would print out the results to mail or fax to the client.
We also distributed this spreadsheet as stand-alone software (on 5¼″ floppy diskette) to field representatives. To do so, we needed to customize a number of fields in the spreadsheet—go to such-and-such a cell; enter such-and-such data; go to the next cell; lather; rinse; repeat until nauseous. We also needed, if I remember correctly, to configure the script to run automatically when loaded, or at least to show the correct page. And then save the file on a diskette. This process took some minutes—maybe a half-hour. And we did it many times.
After a month or two, I was wearying of the rote repetition and redundancy. (Rrrrr…)
I proposed that we could automate most of the process by adding a distribution script that would prompt us for the customizations, set the whole thing up for distribution, and create the distribution disk. Have the computer do all the hard work for us.
My coworker, a natural-born management type, probably felt some responsibility for me being there, that anything I did reflected on him, in one way or another. And he also must have created dozens (hundreds?) of these distribution diskettes, all by hand, over the months (years?) before I showed up.
I told him of my idea, and he said, “You can’t do that. It’ll never work!”
So of course, I did it anyhow. I was young enough not to know that something is impossible, just because someone else says it is. And it worked perfectly. And sped up the process immensely. And reduced the chance of human error, too. (But that was just a bonus.)
I’m sure the code was fairly straightforward, might have required a little finagling during one phase of the process—but I don’t remember which or why. No matter: for some reason, my coworker just couldn’t imagine a script to customize the spreadsheet for distribution, just as we had a script to customize it for printing on-site. But it seemed obvious to me, and I found the exercise extremely fulfilling.
What reminded me of that story was, oddly enough, Bruce Horn’s description of the Mac’s Resource Manager. “The Resource Manager,” writes Bruce, “was a solution to several problems… When I started talking with the rest of the team, Larry Kenyon and Andy Hertzfeld realized immediately the importance of resources, and realized that they’d have to make changes in the rest of the system to take advantage of the Resource Manager.”
Then this paragraph: “Bob [Belleville] told me to abandon the project, that we didn’t need it, and that I should focus on the Finder. Of course, the way I planned to fit all the pieces together with the Finder also required the Resource Manager, and I thought it would take much longer to try to code the system without it. I told Bob that I was going to do it anyway.”
I have so been there.
(Continued with part 3.)