Editor’s Note: You may know MartianCraft for our expertise in the mobile field, but might be surprised to know how far back our experience goes. Den Richards is a partner and senior project manager at MartianCraft, but don’t mistake him for a typical manager with limited technical experience. Den was a software developer when we were called simply “technicians”. He offered to tell us his story and I couldn’t resist sharing it. It reminded me of when I started, how far we’ve come, and I hope it will do the same for you.

My passion for our industry took root in New Orleans while working between my first and second year of college. It was the summer of ’69. Woodstock was happening to my North, Vietnam was still raging well to my West, and Hurricane Camille would soon start brewing in the South. Me? I was taking an introductory summer course in COBOL at a local trade school and just looking to pick up some quick spending cash before heading back to college in Massachusetts.

So I count among my many blessings that quite by chance I became involved in the computer industry in its infancy. It was a virgin frontier, a wide-open landscape for imagination and skills and creativity, and for dreamers with boundless energy. Hey, I was 19. Everything was possible.

But new industries don’t have established paths to employment. Programming jobs paid well but entry-level positions were scarce, with employers all looking for seasoned, experienced workers. More often than not the point of entry to the workforce was through physical labor - as a machine operator. That’s where we earned our stripes, bided our time and waited for our chance.

I started as a tabulating machine unit-record operator. Think: boxes and boxes of 80 column punched cards, 2000 cards to a box, all being fed into machines we wired by hand; big metal beasts with IBM emblazoned on the front and hundreds of electromechanical relays clicking constantly under the hood. “Tab” equipment was nearing its sunset when I got my first job, finding itself being replaced by IBM 1401s and small System/360s. Still, I was excited to be breaking into the industry and determined not to squander this rare opportunity. I was making $1.65 an hour - 35¢ above minimum wage.

Each unit-record machine performed a different function. Functions were sequenced to perform a task. Machines had removable boards called control panels that we wired to perform the function we wanted. Each wire had a small phono-type plug at both ends. Each control panel was a matrix of holes leading to brushes, contacts, rollers and relays. So if I wanted the Interpreter machine to print a character represented by the Hollerith code punches in column 15 of the punched card, in the leftmost position of the card, I would plug one end of the wire into input 15 and the other end into output 1, for example. Easy functions like this used teardown panels we reprogrammed every day. More complex functions, often requiring several hundred wires, would take days to wire and days to test, so we never tore them down at all. We just took them out of the machine and shoved them in the board rack until the next time we needed that function.

Wires would go bad, brushes and rollers would wear out, sensors would misread, relays would fail, and yes, as Grace Hopper discovered, insects and electromechanical devices don’t play well together. Debugging was a painful series of replacing suspect wires with proven ones until that avenue had been exhausted. Then you called the IBM Customer Engineer and watched him diagnose internal machine components with the latest (very cool) analog test equipment. But in the end, he operated on the beast with screwdriver and pliers, and never left until the job was done.

In my first job I was responsible for running the day’s sales invoices (Yep, it was a night job. This just keeps getting better, huh?). I would get a batch of invoicing detail cards which had been prepared by one of our Keypunch Operators based on the day’s sales orders. I’d run them through the Interpreter so the punches could be converted to human-readable text, then run them through the Sorter so we could get them in Customer Number sequence, then merge them in with Customer Master cards in the Collator, then run them through the Calculating Punch to multiply quantity x weight factor x price and punch that product into each detail card, and then run the whole punched, interpreted, collated, calculated batch through the Accounting Machine where the Customer Invoices would be printed and a summary card would be punched out on the attached Summary Punch to represent that customer invoice in our accounts receivable system. Eight hours work if everything went just right. As you might imagine, I had a lot of overtime.

The Accounting Machine, in this case an IBM 403, was the centerpiece of unit-record equipment because it was the only machine capable of simple arithmetic operations and also of printing, and therefore it was the source of all customer, internal, external and management reports. It was effectively the Aircraft Carrier of machines, and all other machines in the fleet existed solely to support it. While printing, the accounting machine was simultaneously tracking four level breaks called minor, intermediate, major and last card (or final total). The first three of these level breaks were defined by field (specific columns on the cards) when we wired the panels, and the last was determined when we physically flipped the last card switch to the ON position thereby telling the machine that when the input card hopper was empty there were no more cards in the batch. (As opposed to: “the machine operator just stepped out for a smoke and will put more cards in the hopper when he gets back”).

As primitive as all this sounds today, it was seminal at the time in that it was a key component in the evolution of our industry from analog machines to digital machines. These simple Accounting Machine functions of recognizing a change in the value of a particular field, performing specific actions based on that change, and then printing a document containing that information, formed the basis of one of the earliest high-level programming languages for business applications - IBM’s RPG (Report Program Generator), introduced in 1959 for the IBM 1401 and then ported to the IBM/360 in the mid-1960s.

If you paid your dues as a machine operator and showed the suits the promise they were looking for, you were eventually recognized and given an opportunity to advance. For me it came unexpectedly one fine afternoon in late May of 1970 - my second summer stint with the same company. While my boss, then titled a Data Processing Manager, and I were noodling through a machine problem our company’s Comptroller walked into the IBM Room and said to my boss: “The president wants the physical inventory computerized this year. He wants it done by the end of July, and he wants you to do it.” Well, the facts were that: (1) the physical inventory was a huge deal to this company with many thousands of different pieces of structural steel in 5 locations to be counted over a two-week period, with the results of the inventory having a significant financial impact on the company, (2) we didn’t have a computer, and we would likely have to rent third-shift time somewhere, (3) my boss didn’t have any real programming experience to speak of. Hell, none of us did, and (4) he was pretty much working to capacity just getting our normal workload out the door every day. Oh, and (5) the schedule was unrealistic. So my boss said: “Can’t be done.” and I said “I can do it.” I learned diplomacy later in life. (Remember: now age 20 and totally bulletproof.)

I worked brutal hours for the next two months, starting from a personal knowledge base near zero and teaching myself all about RPG II and the IBM System/3, both of which had been introduced the previous summer. My employer took me off all my other duties, leased second and third shift machine time at the IBM Datacenter, gave me free rein and good support, and then stepped back and watched…and waited. It was an enlightening, invigorating period for me where I first learned about my own capacity for absorbing tech materials and my own threshold of endurance, neither of which had ever been pushed to the limit, both of which showed a lot of promise as I embarked on my new career where it was becoming apparent that I would need to rely heavily on these traits early and often.

Not unlike today’s methodology which I recently saw on our first Apple Watch development, a lot of my work was trial and error. Try, fail, pick yourself up, dust yourself off and try something different. Repeat until it works the way you want. But I was getting stuff done. I was making solid measurable progress every day. I was learning tons of new things. I felt like I was beating the machine at its own game. I was enjoying myself immensely and looking forward to the challenges and lessons each new day would bring. There weren’t enough hours in a day; not enough days in a week. I was meeting new people and making new friends - programmers. People who thought like me, who talked the same strange language known only to few, and who fought the same battles I did every day. We were all working on green field projects because back then all projects were green fields. It was rare, heady stuff.

By the end of July of that year I delivered my employer a fully documented physical inventory valuation system which they immediately put to good use. They were thrilled with my performance and with the outcome of the job and the physical inventory itself. I was exhausted - but personally satisfied and strangely fulfilled in a way I never expected a job could satisfy and fulfill.

To that point in my life I had always thought I would gravitate toward a career more steeped in academia. I was going to a liberal arts college majoring in Psychology and learning about classics and poetry and history. I was headed to Rome for my junior year abroad to study art history and romance languages. But after my first summer stint as a machine operator I began leaning toward the the math and statistics end of Psychology and took a course in FORTRAN so I could program all my inferential statistics tests. Very unexpectedly I found myself being drawn more and more into programming. I loved it, and owing to some unknown force or gene or twist of fate it was becoming apparent that I was very good at it. Skill begets attitude which begets more skill. I was living in a feedback loop of positive reinforcement.

So I leveraged that first programming opportunity in 1970 into an offer of summer employment when I returned from Rome and an offer of full-time employment when I graduated. My employer was confident that I could grasp the essence of their business requirements and translate them into working business applications. They sent me off to Rome in September of 1970 with a long list of To-Dos, a thick stack of RPG II coding pads and a box of No. 2 pencils.

And thus began my first one-year stretch as a remote worker and my first 20-year stretch as a business application designer and coder. But there were a lot more peak experiences on my horizon.