I.
Officially, he was not a programmer, though programming the IBM mainframes was all he did. There was no contract money for hiring a programmer, but there was money to hire something else. What that else was, he never found out. But he was hired.
The programming staff that supported the DoD (Department of Defense) Anti-Ballistic Missile development project took orders from the engineers and scientists who analyzed the data. He was not part of that programming staff. The individuals on the staff wrote FORTRAN programs mostly from scratch in response to the analysts’ orders. It worked but it was costly. There was a time lag between generation of the missile test data and its analysis, due almost entirely to the time it took to write and debug the programs.
What was needed was a software tool that would allow the analysts to massage the data themselves, without the aid of the FORTRAN programmers.
A big meeting was held that brought in IT professionals and management from system support, the FORTRAN programming staff, and the data analysis section. The purpose: could such a tool be developed in a reasonable timeframe at an affordable price? The answer: No. It would take programmers — plural — with the ability to write a specialized compiler, and such people were both rare and expensive. And even if complier writers were available at an affordable price, it would take far too long to create a tool that would serve a broad range of analytical requirements.
The program they wanted was a program that couldn’t be written.
II.
So the great minds that left the meeting — and a few truly were great — found themselves with no better solution than the one they had been using all along. The PhD analysts would continue feeding data reduction requirements to the FORTRAN staff and wait for the results.
Some people were quite unsettled about this and couldn’t leave it alone. Several weeks later, two managers approached the programmer-who-wasn’t and asked him to think about the possibility of a software tool for non-programmers — the analysts — that would give them the power of a programmer but without the excruciating delays inherent in developing and debugging a program.
In other words, could the programmer-who-wasn’t write the program that couldn’t be written?
III.
He thought about it in his noisy cubicle and came up with a design. He and the two managers plus a crack programmer deeply familiar with the project met for three hours examining his proposal. He had the right approach but the wrong specifics. Every part of it was changed, on paper. And on paper, they now had the specifics they needed. The only thing missing was the impossible part, the program to make it all work.
The programmer-who-wasn’t went back to his noisy cubicle and thought about how he might implement the specifics into an easy-to-use program that didn’t gobble up expensive computer resources such as execution time and memory. He had been programming for over four years, much of it spent writing programs for transonic wind tunnel tests. Writing a program that couldn’t be written was his first major challenge since changing departments.
After two weeks of working on little else, he reported to one of the managers, his supervisor, that he saw no way to do it, short of writing a compiler, a task he was wholly unqualified to undertake.
The supervisor was at least sympathetic. How could he not be? The best brains in the company had not found a solution either.
IV.
One afternoon after the close of business he talked with a friend who was working on his PhD in electrical engineering. The programmer-who-wasn’t explained the wall he had run into, and his friend offered him encouragement along with two thick textbooks on compiler design to study.
He thanked him and took the books back to his cubicle which was no longer noisy at this late hour. He understood only a smattering of what he read, but something about it opened up his thinking. A compiler was a new approach to programming for him. A compiler took a series of statements a programmer wrote in a language the programmer understood and translated it into machine executable code. A compiler was a program that ran in stages, passing its results from one stage to the other, before producing the final product the computer could execute, what smartphone users today call an app.
But was it not possible for any program to compute in stages, not just compilers? The answer was obviously yes, provided the programmer knew how to design and use data structures. A program that did this was usually called an interpreter, not a compiler. Unlike compilers, interpreters didn’t generate stand-alone executable code. A program that ran under an interpreter needed the interpreter in memory during execution, which in this case was perfectly acceptable.
He saw an opening he hadn’t seen before. That apparently no one in the company had seen. He went for it.
V.
Almost immediately he saw the impossibility of his task. His work area was almost never quiet. He needed quiet. He found it impossible to concentrate. How was he to write this program that couldn’t be written if the noise around him interrupted his thinking?
An unusual task needed an unusual approach.
He walked cold turkey into the office of the project engineer, a short-bearded man in his early 40s with sparkly blue eyes and a sense of humor. The engineer listened carefully while the programmer-who-wasn’t spoke. He said there was too much noise in his office but if he could do his designing and coding at home and come in during the evenings to test his program he could get the job done. Coming into the data center after hours meant he would be testing his program at reduced computer rates while getting almost immediate turnaround.
On the face of it, his proposal was outrageous. It had never been done before, not at this company. People came to work in the morning, spent the day in their offices, then went home to be with their families. Your cubicle is too noisy? Get used to it, pal. Who are you to get away with something like this?
But the project engineer dearly wanted the job done. At this point it was not a nice-to-have. It was essential for getting follow-up work on the DoD contract. He had a prestigious office with a window, with little or no noise infiltrating its sanctum. He could sympathize.
It took him little more than two seconds to reach a decision.
Saying nothing, the project engineer raised his hand and waved him godspeed.
The programmer-who-wasn’t drove home and got to work.
VI.
He spent the next three months without a day off doing what he promised, working at home during the day and testing his progress on the mainframe in the evening — sometimes the late evening that carried over into the late morning. His desk was a corner of a wrap-around counter in the bedroom of a mobile home he shared with his wife. They had no kids, though this programming project might be considered an attempt to produce an offspring. It had become a labor of love.
Snow fell frequently during this period. It made his bedroom work area peaceful because it kept neighbors inside. And most people were driving home from work when he drove into work in the evening, making traffic a light burden.
Co-workers wondered about him. What was this special program he was working on? Was he really working or just goofing off? Suspicion about his work life grew stronger the more he worked at home. One morning, just before leaving the office after a 24-hour stint, he fell into conversation with a friend, a research physicist. He was an older man named Jack.
“People are worried about you. They think you’d be better off working normal hours,” Jack told him with a faint note of warning in his tone.
What Jack left unsaid ordinarily would’ve bothered him. He wasn’t worried. He knew the hand he was holding.
The day soon arrived when he could show the project engineer the results, and they far exceeded expectations. The project engineer was blown away.
He installed the program and trained users at several locations, including a coral island in the remote western Pacific ocean. He presented a detailed explanation of its design to the five-person committee that judged such matters. The project engineer was on the committee. So was the PhD candidate in electrical engineering. The committee members liked it. Most analysts loved it, even if it didn’t solve every problem they had. There was always version 2.0. They loved it because it allowed them to process their data themselves almost immediately after a mission. That feature alone made it a godsend.
VII.
So how could the programmer-who-wasn’t write the program that couldn’t be written?
Was he smarter than the rest? Wouldn’t it be logical that he was? He had solved a problem they couldn’t. Didn't that prove it?
There was no question who was smarter. His success did not reflect a superior IQ, and no one thought it did. So what was the answer? How was he able to turn out a program the smart guys said couldn’t be written?
VIII.
To the project engineer the answer was obvious and he announced it thusly:
He succeeded because he was too dumb to know it couldn’t be done.
To the extent anyone cared, this became the accepted explanation. It felt right.
He was also too dumb to finish his formal education.
Lacking a degree, he was paid considerably less than those who had one, even though most of the degree holders thought the program he had written had been only a pipe dream — even though, had he taken the time to finish his degree, the program would have remained only a pipe dream.
The FORTRAN programmers mostly ignored his achievement. Managers, from supervisors to executives, loved it and praised him for it publicly, to the point of making him feel uneasy. Lavish praise — but little else.
On the day raises were handed out his increase was token. Reason given: no degree. The FORTRAN programmers could take comfort in knowing his salary was well beneath theirs.
On the day raises were handed out his increase was token. Reason given: no degree. The FORTRAN programmers could take comfort in knowing his salary was well beneath theirs.
His dream of moving to a real house, funded by a real job, had been shattered.
So he picked up the pieces of his broken dream and went home.
IX.
A day later he did what any dumb guy would do: He quit. The programmer-who-wasn’t, was no more. He had passed voluntarily from employed hero to unemployed bum.
But the bum had a problem. He had to earn a living. What could a burned-out programmer do to make a buck? He had no skills other than programming.
Meanwhile, the project engineer received a big promotion. Other degreed individuals received generous raises, if not promotions themselves.
The bum tried different things. He wrote ad copy for ad agencies. He wrote a Hollywood screenplay that didn’t sell and a film script about the life-cycle of utility poles that did. He went back to school and got a meaningless degree. Money trickled in.
2 comments:
George, Some time ago I had this article printed and then read it. I set it aside and had a chance recently to re-read it. It sounds like a true story, and I suspect it had a great deal of influence on your future endeavors. Is that correct?
I am wondering what you think was the motivation by the employer to reward those who had failed to perform (at least in this instance) and not reward you proportionately.
Art, Thanks for your comment. Yes, the story is true. As for the employer's motivation, I can only guess and surmise. The reason given of course was lack of a degree, but within the company there were a few exceptions. I had worked under one of the them programming the wind tunnel. Why not one more? (He was the sharpest programmer I ever knew.)
The organization was funded by Bell Labs which in turn was funded by the DoD which was funded by the taxpayers. The taxpayers had no say in the matter, but the DoD did. It had strict rules about personnel and the assignments they could work on -- and how much they could be paid. It's possible I suppose that giving me a proportionate raise would have been outside the guidelines for the official title I held, whatever that was.
It's also possible an exception could've been made in my case but they chose not to. As to why, well, they had their program. Why bother keeping me around? Certainly I couldn't get sympathy from the official programmers. My work had to be an embarrassment to them. I recall the project engineer describing them as short-order cooks. They initiated nothing in the way of innovation. They just took orders. But I had come up with something generally perceived as innovative and useful. If the company stiffed me, it had to be gratifying two some of them, at least.
There's also the possibility that the manner in which I got the program finished embarrassed or irritated certain managers. As I mentioned in the narrative I could never have done it working at the office. I needed full focus, and for me at least that was impossible in a cubicle environment. If they had rewarded me proportionately that would've been a blow to those managers who insisted that employees couldn't be trusted to work at home. The project engineer was sticking his neck out letting me work as I did.
It was a painful experience in many ways, but it was also very encouraging to me. I developed a confidence in my programming abilities that a year earlier I couldn't even imagine. And that confidence has stayed with me to this day, not just in programming but in every endeavor.
Thanks again for your comment, Art.
Post a Comment