My First Programming Job in 1981, and How It Shaped My Career

A little more than 31 years ago I got my first programming job at a defense contractor, General Dynamics, in an IT division that supported the F-16 division (now Lockheed). I had no work experience and no education in programming.

Unlike today, it was possible to get a programming job despite a circumstance that wouldn't even get me a phone screen today. I had been programming since I was 16, at least when I had access to a computer, but I had no job experience and never had a single programming class in college. I spent 6 years working on first a BS in Chemistry and then almost an MS in Chemistry. But without a PhD I was a beaker monkey; although TCU had accepted me as a PhD student I decided it wasn't for me.

So I had no job for a few months until a friend mentioned GD was hiring. Apparently the head of the IT division liked to lay off people at the end of the year to look good and then desperately hire back afterwards. I applied and somehow got an interview with my future manager. Why? I have no clue. He asked a lot of general questions and one programming puzzle and apparently I impressed him. Like I said today this would be science fiction.

On my first day of work in October, 1981 I wore a new suit, got a migraine at noon and went home early. Not an auspicious start.

The first couple of weeks I learned JCL and the IBM mainframe. There were two old guys who worked there, my age today I imagine, and they worked on 6 batch applications simultaneously, making a single compile/run cycle per day for each. Even today I can't imagine how. We thought of them as a pair of Yodas (of course not the real Yoda, he didn't exist yet). They starting programming when computers were coded with wires.

Soon I was moved to a group that worked on a super-mini computer which need more bodies and got my first real assignment. The F16 computers were soon to be coded in Jovial-J73 since Ada was still just a thought. The various levels of managers (GD had at the time 18 layers of management) wanted the code to be formatted perfectly so I was supposed to write a pretty printer - in Fortran of course! Someone told me I need a recursive descent parser, and I had no idea what the hell that was. So I went to a library, since Google's founders were still in elementary school! I went to dozens of meetings with boring managers, all of whom wore suits, each with a different opinion.

Yet I learned something interesting. I never wore a suit after than first day and then even ditched the tie which made me an oddball, yet I found that if I spoke confidently and had a clue I got more respect from the suited managers than I should have had. I guess they assumed I could get away with my lousy clothes because I must be really good!

After six months I delivered the new tool and got an amazing reception. Actually, no one ever used it. Another lesson, just because customers are insistent on what they want, they may actually need something else or maybe nothing.

We had paid for a new Jovial compiler/assembler and I was on the team to test it. I tested the assembler for the first time and got a nasty phone call from the mainframe operator - apparently the assembler had hammered the mainframe and filled his console with hundreds of errors. So I had to figure out what was wrong without a rerun, or risk having a console shoved up my, well you know. It turned out it was a bad hash algorithm, which I had never heard of before, which had a nearly endless loop in it. My lesson here was that every project teaches you something new, and that being able to analyze code "on paper" was a valuable skill.

Later I wrote a trigonometric runtime package for the new Jovial compiler. The new Mil Std 1750A processor we were going to use on the F16 had no support for sines, cosines, etc. So I got some books (yeah the paper kind!) from the library and tried to figure out how to calculate them. My biggest fear afterwards was that I would read a newspaper headline someday "F16 Pilot Killed In Dogfight After Missile Fails To Launch Due To Slow Sine Function". But it was really complex coding and I discovered I could do things I didn't understand at the start and still succeed. No clue if my code ever flew though.

During my second year I got friendly with the two guys in the group next door - the Microcomputer Lab. I desperately wanted in but my manager kept saying no. Then a miracle happened. The President of GD asked three VPs to get someone to build him something that would allow him to read email at home on his son's Apple II+ with its 40 column screen.

They ignored him for months. Bad idea. One day he asked for the software and they told him it would be ready by the following Saturday. Of course they hadn't done anything. Now a global panic search started to find someone who could write 6502 assembler for an Apple II, and do it in a week. My buddies in the ML asked me if I could do it and of course I said yes (I knew a little but never more than short bits of assembly). So I jumped into the lab where the VP's had procured an Apple III and some sample code from Apple on doing serial IO. All of the VPs and a bunch of other random people from all over the company were in the room - to watch me code. Talk about extreme programming. I had to write a VT-100 emulator in a week in assembly I had to learn with all these anxious people watching. Yikes!

So after an incredibly long week we got to Saturday and I was able to demo it successfully and they took a floppy with the app on it and apparently the President loved it so much he wanted everyone to get a copy. Of course he could have bought a commercial one for about 60 bucks but when you are a defense contractor, who cares about savings! Now my manager wanted me back, but I used the magical power of 3 VPs to convince him otherwise.

The first lesson I learned from this was that volunteering to do the impossible has many benefits. The biggest lesson was that I could actually do the impossible under pressure.

My old manager did ask for a final report on whatever I was working on so I used a magical device that sat on my new desk - an Apple Lisa we had on loan. My first experience with a mouse and bitmapped display made me a believer.

GD was just getting into IBM PC's and I was sent to a training class on setting them up and upgrading them so I could become a resource. Today that all seems quaint. But once I got back I memorized every single catalog and tech note, and wound up being a resource for not only GD but also the entire local IBM sales force as I knew more about the subject than anyone else they knew. The lesson here was knowledge is power, and being helpful to everyone makes you far more valuable.

I wrote a bunch of new custom Apple II email reader versions. One day I got sick of how much money GD was wasting on this and decided to call the President of GD and tell him he was a moron. Needless to say I was gang tackled by everyone in the room!

The biggest project at the F16 plant was a new receiving inspection system. The F16 plant is a mile long and raw materials and parts come in one end, and planes out the other (basically we ate metal and pooped Falcons). All the incoming stuff had to be tested. They were going to spend $10Mil on building a system running on IBM Cobol on an IBM PC/XT (the first PC with a hard drive), talking with an IBM Series 1 that then talked to the IBM Mainframe. The only missing piece was a communications system that would handle the Cobol app and talk to the Series 1.

I had just gone to the West Coast Computer Faire, where I bought a copy of the new Turbo Pascal which Philipe Kahn was selling out of a 10x10 booth filled with boxes. This was my first IDE, and I haven't been without one since. I built a memory resident module that run underneath the Cobol app. First I discovered that the hard drive driver stopped all interrupts when it accessed the drive, which dropped a high speed serial connection. So they actually sent me to IBM to work with the driver engineers to figure out a system where a notification happened right before it did anything, giving a serial handler time to tell the target to stop sending. Man, this sounds so lame today, but this was uncharted territory then.

In the midst of this a crisis developed. Apparently a manager levels above me decided he wanted a computer on his desk to impress his peers. The next thing I knew the intermediate managers were packing up my PC/XT to give to him! I had to yell at them that the $10Mil project hinged on the work I was doing and without a computer I could do nothing. Now being a friend to all those sales people at IBM paid off, and we got some fancy plasma 4 mainframe session "computer" to put on the guys desk, which of course he had no use for, but it was orange and glowed!

After completing this project I decided to go off and do a startup in late 1984, which at the time was bizarre to everyone there. But that's another story, one that got me on this page.

A year later a group of guys from the ML group came by and wondered if I had kept a copy of the source code to my serial module. Apparently they had lost both the computer and my documented and archived disks!

So after my first 3 years (and now 10%) of my career, the lessons I learned still affect me today.

• If you speak confidently and know your subject people may actually respect you, even if you're not much more than a kid.
• Every project good or bad has lessons for you. You can never stop learning.
• People may insist on telling you what they want, but often it is not what they need.
• Knowing how to read and understand source code is a valuable skill.
• Doing the impossible can be a lot of fun, either you succeed and be the hero, or if you fail, well, it's impossible.
• Knowledge is power, and being willing to share it and be helpful gains you a lot of friends.
• Sometimes you have to fight for what is best for the project or even the company.

The biggest lesson might have been that with every new technology comes new opportunities and it behooves you to keep up as you never know where your career might take you.