As an introduction to computers at our local elementary school, the new tech coordinator had proposed a lesson where students would be given a set of “early computers” (abacus, calculator, slide rule) and asked to identify think about “Why are these tools considered computers? ”

There was a need for a few extra props, so I sent out an email at work… “anybody got a slide rule?”

A colleague replied that his mother-in-law’s first job title was ‘Computer’. She majored in math and worked for NACA, the predecessor of NASA. Her job was to compute the solutions to equations — because there were no machines that could do that.

I have since corresponded with Mary Houbolt and she has agreed that I could share her story below. It’s a bit of history that was not well-known to me. I was interested to hear it and thought you might be too.

(my comments in italics, Mary’s in plain text)

When I was taking Computer Science and Cobol programming at Mercer County Community College (near Princeton) the teacher was telling us the history of computers, “first generation computers, second generation, etc.” — fingers, the abacus, that huge one that took up a city block, etc. When she finished, I couldn’t resist raising my hand and telling her about myself, that I was a first generation computer. She obviously enjoyed it and so did the class.

When I graduated, I was asked right away by NACA, Hampton, VA to come and work there. All math majors from Woman’s College of the U. of N.C. (Greensboro, NC) were asked to come. Our math department had a great reputation, and my favorite teacher of all time was the head of the math department there. You didn’t have to study. You just had to pay attention in class, do your homework, and you had it! I was so blasé about the job offer that I didn’t answer until the end of the summer and into Fall. Jobs aren’t that easy to come by any more, but at that time it was no concern. No application, no interview, just a job!

We used a Marchant calculator, although some offices used a Friedan calculator. The Marchant that I used was as big as an old fashioned typewriter.

I worked at Structures Lab, and there were 6 female computers in an office there. (This was at NACA, Langley Field, Va.) Most of the labs had computers (people) in them, although there was a section called The Computer Pool which was just a branch of nothing but people-computers. I think they worked for anyone on the Field who needed more computers, but I never saw the place.

When the engineers came up with very long equations for which they wanted values run through, we would set the equation up on a wide sheet of columnar paper and run the values through. Thank goodness some of the engineers would give us math to solve or parts of math problems to solve or I would have gone bonkers. Generally our materials were paper, pencil and Marchant calculator.

For example:

If an engineer gave us an equation like: x sq. + 3xy + z = A

We would put the letters and numbers in the headings of the numbered columns and find the value of A. I guess they would give us a range of numbers that they wanted run through:

1    2    3      4        5          6                                 7
x    y    z     x  sq     xy    3  * Col.  5      Col. 4 +  Col. 6 + Col. 3

I think you can get the idea from the above. Col. 4, for example, would have been the digit 4 written inside a circle which indicated a column. The paper we worked on was as wide as 3 sheets of typing paper. Some equation would take 3 or 4 sheets of paper to get all the headings on! The equations were verrrrry lengthy.

As I recall, they wanted most of the work shown because, of course, it would set up a pattern of a sort and would make errors easier to spot.

Remember, at this time, there were no real computers and no handheld calculators.

what did they do with all these numbers once they were computed?
Apparently in engineering textbooks, there are lots of curves that have been plotted on graphs that are somewhat classic. After we “computers” came up with the data, the engineers would plot the data and compare the curves they got with those in the textbooks. It would show them how things behave when you vary the parameters. If a certain curve would appear, it would explain to the engineer why the thing they were testing failed in the particular way that it did. Thus, it would educate the designer.

Mary also told this story which gives a broader picture of what work was like in the lab…
In the lab, were many machines that they used to test I-beams, cross-section panels of wings, and other shapes and various materials. They would put strain gauges (reminded me of EKG things that nurses stick on you) on the material to collect data and then stress the item by bending, twisting, or compressing it. I’m sure our computer results were related to that in some way, but I don’t know just how. Obviously, strength and flexibility of materials has to be built into airplanes. (Watch how the wings of an airplane flex up and down as you fly.) That has to be considered in advance.

You might be amused to know that in the lab there was a huge machine capable of compressing large things with a strength of a million pounds. (You can imagine the noise when a steel or aluminum beam snapped!) I remember one time, just for fun, taking a huge ball of tinfoil (may have been lead foil since I was a big smoker) that I had saved and asking if they would compress it. No noise, but we all got a kick out of what a small, neat cube it became and how very heavy it seemed when compressed. Engineers were always doing nutty things, and I guess I was no exception to the rule. LOL

I don’t remember any measurements being made of the tinfoil ball, :-) but I’m sure they could have been had there been a need for it.

Jarosaw “sztywny” Rzeszótko decided to ask ten questions to the programmers he admired the most and then posted the questions and answers on his blog (via slashdot). I enjoyed reading the Q&A, but what I find most wonderful and inspiring is to see someone take the initiative to connect with both famous and less known role models and then publish his findings to share with public. And to see the great folks and thoughtful leaders who responded to his questions.

Some highlights…

What do you think is the most important skill every programmer should posses?

Steve Yegge: Written and verbal communication skills. You’ll never make it very far as a programmer in any field unless you can get your ideas across to people effectively. Programmers should read voraciously, practice writing, take writing courses, and even practice at public speaking.

Linus Torvalds: It’s a thing I call „taste”.

I tend to judge the people I work with not by how proficient they are: some people can churn out a _lot_ of code, but more by how they react to other peoples code, and then obviously by what their own code _looks_ like, and what approaches they chose. That tells me whether they have „good taste” or not, and the thing is, a person without „good taste” often is not very good at judging other peoples code, but his own code often ends up not being wonderfully good.

But hey, it’s not the only thing. One thing that is very useful, especially in an open source project, is simply the ability to communicate well what you want to do, and how you are going to do it. The ability to explain to others _why_ you do something a certain way is very important, and not everybody has that ability.

That said, in the end there are also the people who just churn out good code. They may not be good at explaining it, and they may not even have great taste, but the code works well. Sometimes you need another person (one that _does_ have that hard-to-define „taste”) to maybe massage the code into a form where it’s useful in the bigger picture, but just the ability to write clear code for difficult problems is obviously a fairly fundamnetal part of any programmer.

David Heinemeier Hansson: A strong sense of value. The ability to ask yourself the question: Is it worth doing what I’m doing right now? So many programmers seem to waste oceans of time on stuff that just doesn’t matter. And not enough on the stuff that does.

Peter Norvig: I don’t think there’s one, but let’s say concentration.

Dave Thomas: Passion.

Guido Van Rossum: Your questions are rather general and hard to answer. :-) I guess being able to cook an egg for breakfast is invaluable.

James Gosling: To be self motivated. To be really good, you have to be in love with what you do.

Bjarne Stroustrup: The ability to think clearly: A programmer has to understand problems and express solutions.

Tim Bray: Ability to prefer evidence to intuition.

What do you think makes some programmers 10 or 100 times more productive than others?

David Heinemeier Hansson: The ability to restate hard problems as easy ones.

Peter Norvig: The ability to fit the whole problem into their heads at one time.

Dave Thomas: They care about what they do.

James Gosling: They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.