Hiking & Writing
I’ve thought a lot recently about what motivates me as an engineer.
Is it “Coming Face to Face with a Technical Challenge”?
Is it “Learning a New Programming Language in Record Time”?
Is it “Completing an Impossible Project on Schedule”?
Well, tackling those tasks can be powerful motivators, but there’s something more fundamental at work.
Go down to Home Depot for a fancy screwdriver-combination-wrenchifier-thingy? What? It’s only $29.99?
Just gimme my toolbox and leave me alone. I’ll make it work.
$29.99. It reminds me of how the Internet wants me to buy a new software tool for everything. Need a new web page? Buy my new editor; my new web language; my new UI designer library. Need a new program to control your streaming device? Buy this online, cloud-based, Web-oriented, futuristic language system! Buy before midnight tonight and we’ll throw in the manuals and a 29-session video course for free!
Gimme my toolbox.
Gimme a break!
A good text editor, a good C compiler/linker. A good command line based operating system. A decent I/O library. And I’m all set.
Actually, who needs a compiler and linker? Just give me an assembler and I’ll re-write part of the operating system to make it leaner, faster and so proprietary we’ll have a professional marriage made in heaven.
You laugh? I’ve done all of those things.
Yes, even the marriage made in heaven.
In the early 1980s (remember?), before personal computers replaced mainframes, and before we cycled back to the thin-client and server architecture (which, by the way, isn’t much different from the “smart terminals” and mainframes of the 1970s – sorry to disillusion you), there were times when the program wasn’t fast enough, or wouldn’t fit into memory. Imagine? In 64KBytes it wouldn’t fit? On a 20MByte hard drive it wouldn’t fit?
Well? What’s it gonna be? Left turn or right turn?
The road straight ahead is washed out, so our plan to go that way is ruined.
Yes, I know that that route was a change from our original route just a few months ago, but who can predict the weather? The weather this month was very disappointing, and that road is washed out.
What, you say, we could still go that way? We could climb down in the gully and wade across, then up the other side?
Hmmm. Well, I can’t see the other side, so it may as well have fallen into the sea, and if we try to wade across we can’t carry everything we’ve brought that we need. So we’d have to live quite a bit differently on that route — assuming we get across and not swept away in the next storm.
I don’t see any alternatives except to choose ‘left’ or ‘right’. A veritable fork in the road.
Ah, one’s career is hard to foretell. Gone are the days of permanency, pensions and picnics. But unless we want to turn back time, or move to another culture, we can’t change it.
So, on we go. Into the wilderness. “Follow the yellow brick road”? Well, the yellow bricks just got washed away, and now we’re down to cobblestones. They say cobblestones last longer anyway, even if they jar your teeth loose! Even though “we’re not in Kansas anymore”, let me quote their lyrics:
Carry on my wayward son
There’ll be peace when you are done
Lay your weary head to rest
Don’t you cry no more
Remember when a fuse blew down in the basement?
And you couldn’t remember where the new fuses were stored?
And you couldn’t read the tiny letters on them anyway?
So, you shoved a penny in the fuse holder, and said “I’ll fix it tomorrow“?
Funny how we still do that.
Maybe it’s because so few people remember what happens when you put a penny in the fuse holder.
Maybe it’s because so few people remember what a fuse is.
Well, yes, the title is a blatant attempt to squeeze a few keywords into one phrase. But, yes, there was word processing on mainframe computers, even before there were PCs.
This is the story of bending such a text processing system to do my will.
Back in the olden days, there were things called “mainframe computers”. They got that name because they were in mainly big – very big – frames, and computed, and were kept in air-conditioned rooms while human beings lived in the heat and humidity that had been their lot in life for generations. Ah, to be a mainframe technician! It meant staying cool in the weather of the East Coast. But anyway, these massive machines were connected to terminals, each providing typed input and showing the output of programs running on the computer in a time-shared environment. Sounds like client-server? Well, not so far off.
Well, the mainframes had programs which could format text into printed materials. These were text processors. The output was printed on equally massive line printers in the same air-conditioned room as the mainframe. One had to walk down the hall to get one’s “print-out’, and check it for errors. IBM had a very good example of this system with their IBM/370’s and their Script/VS text processing program.
This was the beast that had to be tamed.
1992 brought a change at IBM Microelectronics. It was a big change. Facing business pressures, and with a stockpile of cool technologies, IBM chose to open their doors and sell their technology capabilities to the rest of the semiconductor-using world! True, those heady days of three-level-metal, 8-inch wafers seem simple now, looking back. But at the time those techniques, and others, were state of the art.
I was working in Program Management, and had gotten a taste of travel, and being in front of customers. I liked it. I wanted more. I signed up and moved to the Field Application Engineering department, serving external (and internal) customers with IBM’s premier ASIC offerings.
The biggest challenge in selling what IBM had was that IBM had different stuff. There were other ASIC companies out there, but IBM had top-end silicon, packaging, tools, sign-off methods, testing, and more. How to convince the customer that those things are worth a bit more, and that their design engineers could make use of it?
Soon after the successes in designing subsystems for a new 20MHz tester, while looking around for more ways to contribute to the team, I came into the office on a Monday morning to see a meeting announcement.
“We have all been given a new mission,” proclaimed our manager. In those days, this was not an uncommon occurrence in IBM, yet my co-workers and I had worried looks.
Yes, indeed, I can write code with one hand and wire-wrap with the other. “Prove it,” you say. Well, I did in the late 80s.
After several years working on test equipment purchased by IBM, I decided it was time to take the plunge. A different department in IBM was developing a new tester in-house, and they needed help. So, an interview or two, and I transferred over there.
I arrived in time to get the assignment to design a “fail buffer” subsystem for the tester. This peripheral would collect fail information as the equipment ran patterns on the prototype memory cards. Software would be needed to count errors in that collected data, analyze patterns in the failures (row or column problems), and output reports. “I can do both – the hardware and the software!” I said. “It’s yours,” replied my new manager.
I see this pattern in the projects I tackle in my professional life:
I enter into a new field – whether a new computer type, a new programming language, a new technology; I learn it; then I write about it and explain it to others; then I find its limits and try to push through those limits.
It began early.
