Women in Technology

Hear us Roar

Then = Now + 1

by Nikki Downes-Martin

Nikki Downes-Martin started work as a programmer over 30 years ago, but soon developed an interest in analyzing and designing business processes.

My degree from Swarthmore College in 1962 was in Engineering Sciences. Ten years later, a divorced single parent with four boys and a very brief work history at Bell Labs, I needed a job. My engineering education seemed out-of-date and programmers were in short supply. One Fortran IV manual—but no hands-on experience—later, I had a job with Raytheon Missile Systems Division. My starting salary in 1973 was $10,000 per year.

After one year at Raytheon writing code to process Sam missile flight path data and one and a half years at Honeywell writing re-entrant disk driver code (and too much documentation) for the 716 minicomputer, I went to Digital Equipment Corporation, where I would work—primarily on manufacturing systems—for the next 17 years.

I learned all my programming skills on the fly: Fortran IV (using punched cards), assembler (using a line editor), Basic (what a treat an interpreted language was), COBOL (briefly), OPS 5 and LISP (in the AI era), and C and C++. Lack of formal training notwithstanding, I had a reputation for writing clean code with good documentation and white space.

I remember with pleasure some of the technical puzzles I encountered, including:

  • Writing a bootstrap to toggle into the first 20 locations of the 716 memory. It loaded the first block of the full operating system bootstrap into a fixed location in memory and then jumped to that location.
  • Writing programs in Basic with a 32k memory limitation. Structuring programs to manage memory usage by opening and closing files as they were needed in the execution of the program. Occasionally, splitting the program into two halves and trying to minimize the number of times when the logic took you from one half to the other.
  • Writing and maintaining a home grown database with hash algorithms to find indexed records and linked chains of associated records.
  • Learning an entirely new mindset to program in OPS 5 and LISP.

Most of my work at Digital Equipment Corporation involved manufacturing systems: materials planning, order scheduling, bills of material, configuration management. In the mid-'80s, I presented a paper at the 1987 ASME Winter Annual Meeting describing a first step in automating the transition from engineering bills of material to manufacturing bills as engineering changes orders are applied.

But my most satisfying job ever was as the sole support of a small scheduling/materials planning group in manufacturing. I did it all—from defining business requirements to 1:00 a.m. calls from operations when there was a problem with overnight program runs. I understood what my users needed; in fact, I had a broader view of the process than the folks in the trenches and a more detailed view than the management team. I had never been more certain that I was doing was exactly what was needed or more certain that my work was appreciated.

Once I left Digital, I worked freelance doing IDEF0 process modeling in a variety of industries such as, cabinet manufacturing, oil pipeline, maintenance management, vendor managed inventory replenishment, online internet service. My most exciting assignment was four months spent in South Africa with Dan Thornhill (IDEF0 modeler and mentor extraordinaire), modeling the national electrical distribution system, just before the first post-apartheid elections in 1992.

Throughout my 30 year career, I worked in predominantly male groups. With the exception of being at Raytheon, most of my peers were younger than me. I always felt comfortable and accepted as one of the guys among the programmers, but I also felt a need to be an exemplary representative of my gender. Having grown up with brothers in a family that teased one another, I was comfortable with the kind of humor I encountered among them; I didn't mind being laughed at when I did something foolish. There were issues about acceptance, though, when I first began to support users in a manufacturing plant. So I was pleased when those guys began to tease me; it was acceptance.

With one exception, I did not experience any sexual harassment—mildly risqué humor and the occasional pass, but nothing that felt excessive. My own sense of humor has a risqué side, but I found I had to censor that. Men my own age and older tended to interpret such humor as an invitation to much cruder remarks even though they took for granted I wouldn't object to less crude, but still risqué humor, they regularly used in the presence of women. I have always assumed that they were all editing themselves to a greater or lesser degree in front of women.

My status as a divorcée has sometimes lent itself to misinterpretation. When I worked in the Artificial Group at Digital (under my maiden name), my oldest son – just out of college – was in the same overall group. I walked up to him in the cafeteria one lunchtime, while he was talking to a small group of colleagues I didn't know. Putting my hand on his arm, I said, "Am I going to see you tonight?" "Yes," he said, offhandedly. When I got to the cafeteria door, I had second thoughts and went back. To the group, I said, "You do know he's my son, don't you?" There were definite signs of relief that they were not suddenly privy to an office affair. Although I did have personal friendships with a few of my male colleagues, once or twice that did not sit well with their respective wives, so I tended to avoid becoming friends with married guys. While I socialized with a few of my colleagues over the years, my only two lasting friendships are with women. It may say something about the difficulty of making friends across the gender boundary at the office, but it probably says more about my own tendency to have just a few close friends.

In 1970s, Hackman and Oldham studied job design and identified five factors that contribute to a satisfying job: skill variety, task identity (i.e., the completion of an identifiable piece of work), impact on others, autonomy (of both schedule and procedures), and feedback from the job itself. Programming was the perfect career for me: it was intellectually challenging; often solitary; and I got satisfaction out of creating a good design and writing clear, maintainable code. In most of my career, I got to implement a solution from conception to roll-out; and the programs gave me instant feedback about whether or not my code worked.

I am mostly retired now, but the programming lingers on. When my mother went into assisted living, I built an Access database of her possessions and used it to disperse them to her children and grandchildren. I have written a program to translate the export file from my genealogy application into a form that can be imported into Access for my brother. And, just last week, my husband and I laid out the logic for an Excel application to load a two dimensional array with all the possible combinations of the elements of a list (of unknown length) of lists (of unknown and varied lengths). Programming had always been task based rather than recreational to me, but, nowadays, I'll take any excuse to break out my keyboard.

Return to Women in Technology.