I started working with computers in 1972 at Southern Oregon College. The housing department had an IBM 1130 and needed someone to run it. That experience helped me get my first job after college, working as a computer operator and programmer for the City of Portland.
Since then, I’ve been part of teams working on diagnostic software, scientific computing, design workstations, websites, and business systems. My responsibilities have included programming, engineering management, technical support, marketing, and teaching. The boundaries between those jobs were not always particularly clear.
Two days in Paris. Approximately.
In 1978, after about six months at Floating Point Systems, I went with a team to install an AP120B at Dassault Aviation near Paris. It was my first overseas trip.
Our machine had a white front with a green racing stripe. It stood out in a computer room full of IBM-blue equipment, particularly since it was installed directly in front of the IBM field engineer’s office.
The installation was supposed to take about two days. It took about two weeks.
We had trouble getting our equipment to communicate with the IBM system, and IBM would not let us attach test equipment to its system bus. We eventually found that the IBM documentation used to design the interface was incorrect.
It was an early lesson in the difference between how a system is documented and how it actually behaves.
There were compensations. I met Michel Rouillard and his family, visited the Louvre, and fell in love with Paris. The cafeteria at Dassault served wine with lunch—an engineering practice I was unable to persuade FPS to adopt.
Working on the whole problem
At FPS, I worked on diagnostic software for array processors and later managed a diagnostic engineering team. Much of that work involved APAL, a highly parallel assembly language.
Troubleshooting could take us across the boundary between software and hardware. During a later installation in Munich, I found an incorrectly dimensioned array in an assembler’s symbol table. At another point, I used a customer-supplied soldering iron to add two wires to a board. That improved the signals, although it did not fix the original problem.
These were team efforts. Customer engineers, hardware specialists, field support, and software engineers all contributed. Nobody necessarily had the whole answer at the beginning.
Later work at Metheus, Aptec, and Intel brought different combinations of technical work, customer contact, and communication. Understanding the technology mattered, but so did understanding what someone was trying to accomplish with it.
The web’s Wild West
My years at Hanlon Brown, later HB Design, overlapped the early World Wide Web boom. It was a Wild West period: hand-coded pages, changing browsers, and a great deal of figuring things out as we went.
We worked on client websites and the systems behind them. My responsibilities included front- and back-end programming, internal business applications, system administration, and managing developers.
There was a satisfying immediacy to that work. Write some HTML, open a browser, and see what happened. Then discover what happened in a different browser.
Alongside that work, I taught HTML, JavaScript, Python, and Unix at Clark College. Explaining something to students is a useful way to discover which parts you understand—and which parts you have merely become accustomed to.
Another beginning
Now I’m exploring the start of the AI boom, mostly for fun.
Or, to paraphrase Douglas Adams, that must be some strange usage of the word “fun” that I was previously unaware of.
I’ve been using AI to help make things I want: a watch-face editor, a newsletter builder, home-automation controls, and small applications and WordPress plugins.
I try to be clear about who does what. AI does much of the coding. I supply the requirements, try the results, and explain why something that technically works still isn’t quite what I wanted.
Sometimes it goes remarkably well. Sometimes the program builds successfully, installs without complaint, and displays absolutely nothing on the watch.
That part feels familiar.
The tools have changed enormously since the IBM 1130. What still interests me is taking an idea, working through the problems, and eventually having something useful.
And then noticing one more thing that needs fixing.