Incompetence in the Workplace

I mentioned in one of my earlier posts (http://ronaldjbrown.blogspot.com/2011/05/how-i-stole-multi-million-dollar.html  May, 2011) a systems manager from Digital Equipment Corporation who sat at a customer’s site for a year and yet didn’t make any effort to tackle the severe performance problems they were having—problems that could have been solved, as I had demonstrated, with minimal knowledge and effort on her part. She, and her employer, DEC, lost the contract, worth several millions of dollars, with client as a result. As fate would have it, I wound up working with her a few years later.

We were part of a team of system managers supporting remote clients from one central location. Her specific client was a small life insurance company. Once a week I would overhear her in a conference call with the client. She seemed to spend the entire 20 minutes or so that the call took talking about her family, sharing details that interested no one except herself. She had a list of items that the client wanted addressed and, every week she would report that she was working on them. Working in such close quarters with her, I knew better. She spent all her time at work, when she wasn’t going on about her family, playing silly computer games and reading some sort of online novel, though she seemed to always be on the same page whenever I passed behind her and could see what was on her monitor.

I heard later from the project manager of the contract that the clients had been begging him to find someone to replace her. Things moved slowly. First DEC was bought out by Compaq which was itself bought out by Hewlett-Packard and still the babble about family dominated the weekly conference calls with the insurance company. One evening my manager said that he wanted to meet with me at 10:00 the next morning. I was coming down with the flu and asked if he could telephone me instead. I had a premonition of what was happening and waited by the phone anxiously the next morning. He phoned at about 11:00 and said that he just wanted to let me know that he had let the failing system manager go. I was relieved. I had suspected that this was coming, but, I couldn’t be certain that I wasn’t the one who was going to be shown the door. I asked who was taking over her clients and he told me he hadn’t decided yet. I knew, though, that I was the most likely candidate.

Sure enough a few days later I was introduced to the client in the scheduled weekly conference. I asked for, and received by email, a list of the items my predecessor had been working on. I shook my head in disbelief as I looked it over. She had been “working” on some “problems” for more than a year. In fact she had “been searching for a license” for printer that the client had purchased almost two years earlier. There was no such license; all that the printer needed was to be initialized with the correct binary code that I looked up in the printer manual. What had to be done was go to the client’s site and send the printer the documented instructions to get it working. When I visited the client a few weeks later that is exactly what I did; it took me approximately two minutes to type the string of characters that the printer had been waiting for (this was long before “plug and play” had become standard).

Her other outstanding projects were similarly extremely simple and could have been done by anyone with the minimal training required for her position. For example, creating a batch queue would have taken about two minutes of her time; there it sat on the list for some 18 months while she “investigated.”  Creating batch and printer queues was a job I usually assigned to the most junior members of any team I worked with. So, within a week I had cleared all the outstanding issues, except for the printer which required me to make an overnight trip to the client’s location. The project manager had a habit of showing up unexpectedly and quietly coming up behind his system manager to see what she, or now I, was working on. As luck would have it, he always caught me in the midst of doing some minor task for the client, something, he told me with some bitterness, he had never caught my predecessor doing.

I have never understood why some businesses keep employees who obviously cannot perform the tasks required by their position. When I was in a position to I fired such employees with no delay or fuss. They were given a month to clean up their act; everything they were assigned and produced (or not) was documented; and at the end of the month I’d meet with them and the personnel director and have them escorted off the premises. If I didn’t have firing privileges I would document the person’s failings, what attempts had been made to help them, and the outcome and forward it to the appropriate manager. In every case that I can recall, my advice was followed. I never felt badly about that because it created the opportunity to offer the position to someone who had the talent and ability to do the job. It amazes me that, despite the poorly-performing economy, there are so many incompetent people holding down positions that could be filled by people who know what they are doing.

I guess I was just a cold-hearted bastard in the working world, but I do believe that what I did was the best for everyone concerned. The company would get rid of someone not producing and replace them with someone who could deliver; someone with skills would be given an opportunity to work; and the person let go would no longer have to kill time at work doing boring, irrelevant, and soul-destroying tasks.

Getting People Out of the Computer Rooms

I remember seeing, in the 1970’s, computer tape drives in store front windows. Operators would have to go into the window display area to change tapes, making the entire thing a show (and they were wearing white shirts and ties, which is not a particularly good idea when working with equipment that has rapidly spinning parts). That’s what most people thought of when they thought of computers in those days. In fact, a drawing of an old-fashioned tape drive is still used to represent computers in cartoons today. Eventually IBM figured out that sunlight is very hard on plastic tape—in fact, leave it in the sun long enough and it will disintegrate—and so they moved the tape drives into air conditioned computer rooms where they belonged.

But those computer rooms, though nominally clean, were not the best place for disk drives and other highly sensitive equipment. The main problem with the old computer rooms is that they contained people—and people are, and were, the dirtiest things in such rooms. In the early days it took fairly large teams of people to keep computer systems functioning. Contrary to popular belief, most of the people in the computer rooms were not scientists or mathematicians; they were more likely to be high school grads with no particular skills other than a willingness to follow instructions and work through the night and on weekends. Being out of public view they dressed pretty much as they pleased under the lab coats that they wore (in order to protect them from ink in the printers and plotters, not because they were scientists).

When I began there were employees in the computer room who had been there for several years. They were full-fledged government employees protected by unions and a hierarchical system that rated seniority above ability. But, new employees did not receive that benefit; instead, they were hired as “term” employees, meaning they were not protected by the unions and their term of employment was limited (usually to six months, though such terms were regularly renewed.) It took me about a year to win full-time permanent status, but, most employees continued as terms for many years. I once remarked to my boss that I thought the reason that new employees were permanently on term (a slight contradiction in terms) was to prepare for the day when computers would not need so many humans attending on them. He agreed.

I was one of the ones working on the process to get people out of the noisy air-conditioned rooms, to leave the computers to look after themselves. I wrote a series of programs that did some of the routine monitoring that people used to do. Where the huge CDC Cybers and the midrange IBM system required dozens of people in constant attendance, my VAX VMS machines required only an operator to change tapes now and then. Everything else I set up as automated self-regulating systems. My purpose was never to put people out of work, but to free them from boring repetitive tasks that computers could handle on their own at far greater accuracy. People, I figured, would get more interesting jobs; for one, there was a shortage of programmers and software engineers.

Contracting-out expanded rapidly throughout the Mulroney years. Permanent employees are expensive. Besides medical benefits, long term disability, employer taxes, most employers then paid for pension plans. Unionized employees were even more expensive because you had to give them a severance package far better than what the law required—and you had to lay people off in order of seniority leaving you with a skeleton crew of the highest paid group of employees. By contracting-out services you avoid all that overhead. Companies bid to supply the services and you pay a predictable amount for the contract. Who the people are who are doing the actual work and what they are paid does not matter to you as long as they don’t screw up.

Another benefit was that the government could claim it had slashed so many jobs from the public service (always a popular move in the rest of the country). The fact that often those very same people would be back at the same jobs under a contracting arrangement was not mentioned. That accounts for the contradiction of fewer public employees but higher government expenditures. Every political party claims it intends to, or has, let thousands of people go, but, the numbers actually working in the public service keep growing. It’s just that most of them are not “employees;” they are “contractors”—and we don’t count those.

When the axe fell and almost two hundred people employed at the centre and in its support systems were let go, I moved on to a consulting firm. Because the firm I joined had won the contract to supply personnel to keep the computer-room going, I was asked for recommendations by my new private-business employers. For each of the former employees at the centre who I recommended they hire, I was paid $1,000. Not a bad deal from my point of view. (I think that my total was $7,000 in such “bonuses.”)

Because privately-owned companies are in the business of making money, the fewer people they have to pay to meet the terms of a contract the better. And so the squeeze began in earnest. Where once you needed two people: one monitoring the system and the other standing by waiting for a computer to ask for a tape to be mounted, now you could ask the person monitoring the system to do that. In fact, I was once asked to design a system so that the monitoring equipment and tape drives could be kept at the contractor’s site, just leaving the computer and main communications gear at the client site. That way many systems could be monitored and attended to by a much smaller crew. Remote communication simply was not fast enough and reliable enough at the time to set up such a system though it is certainly feasible today. The point is that people were becoming redundant.

“Lights out” technology became a buzz-word for a while, especially as the huge old people-dependant machines were phased out. The advantages of having no humans at all in computer rooms were obvious. At the time, people still had to enter the rooms to change tapes, but, otherwise, all monitoring and software support tasks could be done from outside the room. As communications improved, those monitoring and otherwise supporting did not have to be in the same building that the systems were located. They could be anywhere in the country (or the world, as it is today). In fact, I did a lot of remote support of systems from one coast to the other, often from my office at home. I could nurse a sick server in Kamloops, BC, oversee a disk-drive replacement in Halifax, NS, and talk to someone in New York about a software licence, and then “attend” a conference call with my country-wide clients in the morning, all without leaving the house. So, instead of one of me in every city across the country, there was just one living in a remote forest. And all those computers were running smoothly in cool darkened and people-free rooms.

Data and Disaster

In my first year or two in the computing world I saw a lot of card decks. No, not the playing kind—the computer kind. Hollerith cards were originally created by Herman Hollerith (1860-1929) as tools to be used in analyzing statistics. By punching holes in standard-size cards at predetermined locations, one could use mechanical methods to sort data quickly. His technique was used to tabulate the 1890 American census results. Eventually his company, through mergers, became one of the foundations of IBM (founded in 1924).

The standard cards in use in the computing industry throughout the later part of the 20ieth century had 80 columns of 12 rows each. The rows were numbered 0 through 9, with two more rows reserved, originally for plus and minus signs, but later used to expand the vocabulary of a card to allow for upper and lower case letters and other special marks. Sometimes the holes were used to represent binary numbers (which, you will recall, are symbolized by digits of only 0 and 1). As computing spread through the business world in the 1970’s and early 1980’s key-punch operators were in demand. Financial records, medical records, inventory-tracking systems, scientific data were all being recorded on punch cards.

I often handled card decks in my early years. In fact, my first programs were written on punch cards. I would write the program out by hand, then sit at a huge card punch machine to enter the code that would be punched onto cards. The cards were then taken to the computer room where they were fed through another huge machine to be read and executed by the computer. Output was printed onto fan-fold paper. Cards in-paper out was the way we operated then. In my role as operator at the computer centre where I first worked, users would bring me boxes of cards that I would accept through a submission window. I’d put the cards through the card reader when I had time. The job wouldn’t actually execute until a senior operator gave it the go-ahead—and that might not be until 2:00 am the following day, depending on how busy the system was. After it did run, I’d fetch the paper output from the printer that was about the size of a small car then wrap the paper around the original card box and secure it with an elastic band. The package was kept in pigeon holes to await the return of the user.

I’ve gone into some detail here in order to stress the fact that “data” was something tangible that users could hold in their hands. I sometimes tried to convince users that their data was safe if stored on disk—and much more convenient to access. Some wouldn’t buy it. They had spent a career gathering the data vital to their research and didn’t trust it being turned into electronic signals. Cards they could keep secure in their offices—and if the computer centre burned to the ground, their data was safe and could be processed on another computer. Eventually, of course, card decks disappeared except as curiosity items.

But, what about the data they represented? First, while 12 rows of 80 columns can hold a tremendous amount of data, sometimes that simply wasn’t enough space. Many simple computer code instructions, for example, could not be fit into 80 character spaces—to give a mundane example. One of the science groups I worked with recorded data that had to be precise to 29 decimal places. That doesn’t leave much room for anything else. You might recall, if your name was longer than, say, 12 characters, receiving mail with your name truncated. That’s because a programmer was trying to fit your name and full address, along with other relevant information into 80 spaces. So, cards were already unreliable because of the limitations on how much data each card could contain. It is one thing to truncate a name, but quite another to truncate medical information.

Secondly, cards were not as physically secure as many users believed. They were made of very light cardboard and so could get caught in card readers and torn to shreds. They could get dropped and slide unnoticed under a file cabinet. They burned readily—and sometimes they showered out of a university’s computer room to the streets below. Computer disks, which at that time were the size of a standard home dryer, didn’t suffer from those limitations—though a particle of cigarette smoke could get between the disk surface and the read-write head, dislodging the head causing it to crash onto the disk’s surface. Hence: a head-crash. Usually unrecoverable because, even with a new head assembly, the disk surface, where the data was stored, was scratched and computers could no longer make sense of the signals they were reading.

Because of the limitations of physical devices computer rooms everywhere established procedures to protect the data in the event of a head crash. The standard method was to copy the data, in a compressed format, onto tapes. At first the tapes were stored in the computer room but eventually it occurred to someone that this, perhaps, wasn’t the best idea. The tapes should be stored at some other location so that, even if the computer room did burn down, the vital information was secure. At the same time, the data needed to be readily accessible, so compromises were made, like one copy on-site, one off-site.

But that’s not the end of the story. Tapes, made of ferrous oxide on a plastic strip, had limited lifetimes. If the tape was left unused for long enough, eventually data would “bleed” from one location on the tape to an adjacent strip pressed firmly against it. Oxide eventually disintegrated and fell off the surface. Plastic would get brittle given enough time and break when it was stretched by a tape drive. The half-life (the time at which 50% of the tapes became unusable) was usually about ten years. Not good enough. Businesses, government offices, research facilities, medical centres, etc. could not afford to lose half of their data every ten years.

To preserve the data on tapes for as long as possible, tape librarians—if they knew what they were doing—would “exercise” the tapes at regular intervals by mounting, unreeling them, then rewinding. Tape formats changed over the years in order to get more data into physically smaller space, but, the basic limitations of tape never changed. Still, large computer centres relied on tape, sometimes in robotic-controlled “silos” capable of storing thousands of tapes, usually in cartridge format.

In the mid 1980’s to early 1990’s a new approach was developed. Disk drives were now fast enough that data could be written to two disks simultaneously—thus providing a real-time very accessible backup. RAID sets, as groups of linked disks were called, came in different configurations depending on how vital immediate access to backed up data was (and the pocket book of the owner). A popular configuration was a three-disk unit where the data was written to three disks, and could be reconstructed, based on the parity information on the surviving two disks, in the event that one of them crashed. This doesn’t get around the limitation of storing data in one place, so it was often combined with off-site tape storage. An even better solution, when immediate access to data no matter what disaster occurred, was the development of remote clusters.

A system cluster was a group of computers linked together in such a way that they could perform, as far as the user was concerned, as one system much larger than any individual one. Not only was performance, as a whole, enhanced, but immediate access to redundant data was possible. Once it became possible to have a cluster that functioned as a unit even though components were at different locations, live off-site backup was a reality. Such setups are expensive, but absolutely necessary in some situations (like banking information). In these setups usually both sites are accessed as if they were one unit, but the data is kept at both locations. If one site goes down, the other can continue to function, though at a reduced performance rate. Users could possibly notice no more than a temporary glitch in their sessions.

Not every company can afford such a setup. Depending on the urgency of access to data (and the amount of money available) there are different strategies in place to enable a business to recover from the disaster of a computer-room fire. There are companies that specialize in disaster recovery who offer different levels of service. One method that I worked on with two different clients involved a contract commitment to a 24-hour recovery. This meant that the recovery company guaranteed that the business could be functional within 24 hours of a disaster. It involved having equipment available that could mirror the setup of the target system quickly and provide the delivery of off-site backup tapes. As well, rented equipment, such as personal computers, servers, desks, telephones, could be delivered to a pre-arranged location. The tapes would restore the data to the mirror system while the new “office” was being set up.

You might think, on reading this, that every business is now protected by data redundancy. Such, however, is not the case. After I left the field and worked for non-computer companies I was surprised to find no backup strategies in place at all. At one small company, I started a system of backing-up the key data every night to a writable CD and then doing a full backup once a week. The full backup I would hand to the company owner and tell him, “This is your business. Keep it at home in a safe place.”

At another company, we experienced a disk crash. No one at the company seemed to have a clue what was going on as the disk failed over the course of a few hours. A general feeling panic developed as people with no background or experience guessed at what was happening and how long recovery would take. When the disk finally failed completely and a new disk installed by a technician, I was stunned to find out that the company had no backups of the data. When I asked why not, I was told that they had never experienced a problem with that software package before. No one understood when I tried to explain that the failure had absolutely nothing to do with the software application. It was a hardware failure, pure and simple, and, eventually, all hardware will fail.

Fortunately, I was able to rebuild the lost data using information stored on another disk and in the paper files. It took several weeks at 4-8 hours a day—and the only reason I could do it was because I was intimately familiar with the two software packages involved, as well as general computing basics. No one else at that office could have accomplished what I did. They now backup their data nightly.

Working at the PMO

Most government departments appear to be housed in office towers if they are not in the Tunney’s Pasture Complex of buildings. A notable exception is the Prime Minister’s Office which is located in a group of connected buildings between Wellington and Sparks, running from Elgin to Melcalfe Streets. The buildings themselves date back to the 1920’s or so when architecture still included gargoyles and carved friezes depicting historic or fanciful themes.

The employee entrance to the PMO is through an otherwise nondescript door on Sparks Street. One enters a dark narrow hallway with a commissionaire seated at a simple wooden desk. After he checks your ID you can pass to the small elevator lobby. The elevators are old and start and stop with abrupt jerks. Often they contain CSIS agents. You can always tell who they are by their size. There must be a minimum height requirement of six and a half feet to join that service.

The building is aged. Hardwood floors are worn and many offices are encased in glass while others have heavy wooden doors. The computer room is enclosed a box made of three-inch thick steel. No, that’s not to make it bomb-proof; it is supposed to be spy-proof. Apparently the Russians had sophisticated equipment that could reconstruct the monitor of a computer or a computer keyboard just from the electronic signals it generated. The prime minister’s computer were the most “secure” I had ever seen in my government career—though I am sure they must be others even more highly protected that I would never have gotten near.

The “secrets” that the PMO’s computers housed were the day’s daily wire-service reports. Most of the world’s wire services fed into the machines that used elaborate search-engine techniques to sort out what might be of interest to the leader of the country. Humans, located at another location, sifted through the selected reports, further refining the search, cutting and editing. All this to produce briefing notes on whatever the Prime Minister might be called upon to respond to.

The operators in the computer room were the same as you will find in any other computer room. High school grads with no particular skills except for the ability to sit up all night staring at computer screens and being able to follow directions if an event occurred. Jeans and casual shirts were the standard uniform. Some wild hair was tolerated. The standard vocabulary and speech patterns were working-class Ottawa valley. I was told that Trudeau used to sometimes drop by the computer room late at night and chat with the guys, asking what they were up to. He had a genuine curiosity about what people around him did for a living and about their lives. I was there during the Mulroney era and was told that “King Brian,” as the staff referred to him, never deigned to slum.

The offices were generally very large, as befitting those close to the PM. Many had large television sets and VCR machines housed in cabinets—and their desks were cluttered with computer equipment. The rooms weren’t designed for modern electronics and so cables tended to snake everywhere, clashing with the general décor. On one brief contract I upgraded the computers, replacing the 4 Gb RAM chips with 8 Gb RAM, and the amber monitors with colour ones. At the same time I upgraded the operating systems. No one was ever in an office when I entered with my screw driver and bag of computer chips. I studiously ignored the files and booklets stamped “Secret” that lay on many of the desks. I paranoid-ly assumed that I was being watched and, in any case, the “secret” stuff was probably boring and meaningless to me.

I was required to return the machines to the same start-up state they were in before I made my modifications. I was somewhat surprised to find some booted directly into “The Search for Red October,” a popular game at the time. One time I took a wrong turn and wound up in the Wellington Street lobby of the Prime Minister’s office. It was a huge open space like the lobby of an expensive hotel. The deep blue carpet was being vacuumed by a uniformed maid. Another time I wound up in the basement of the building—a long room, almost the length of the entire complex, filled with traveling trunks and cases. I was told this was what traveled with the PM whenever he left Ottawa. It must have taken a fleet of tractor trailers to get all that stuff just to the airport.

When President Clinton was visiting Ottawa a fellow employee took me up to the top floor overlooking Wellington Street and Parliament Hill. I was surprised, though I probably shouldn’t have been, to see sharp-shooters and spotters in positions on the roofs and terraces on our building and the buildings around us. I would guess that it’s about a kilometer from where we were to the main front doors of parliament—and these guys never missed.

One evening when Clinton was visiting a police officer stepped out in front of our car, holding us up for over an hour while we waited for Clinton’s motorcade to appear and race past. Such is life in a capital city.

Sex and the workplace? What do we really know?

This story is a bit difficult to tell because when it comes to the private relationships between sales representatives and clients obviously no one else was there to witness what went on in intimate moments. People in the workplace make statements like: “She’s fucking him,” or “He’s doing her regularly” in an authoritative insider-knowledge tone, but, how do they know? Really? We do observe other people’s interactions and draw inferences, but how accurate are our interpretations? Everything we experience is filtered through the sieve of our prior experiences and expectations so can we trust anything we think we see?

At the same time, when I was a student I knew a young woman who went to work for a large corporation. I had a drink with her one evening after work and my jaw nearly hit the floor when she told me that her intention was to fuck her way to the top. Other than uttering that one sentence she presented herself as a nice young woman from the suburbs. Of course I was young and still somewhat naïve, not realizing at that time that nice girls do and that women can be just as cold-blooded and manipulative as men when it comes to sex. More so, in some cases, as the male usually is satisfied with the act while females can use the act in order to achieve some other end. Still I was thunderstruck by the rawness of her statement.

During my career I have worked with about a half-dozen women who made no secret of the fact that they were using their sexuality as a tool in the workplace. A few admitted it openly to me. I can think of four different women, in different jobs at different times, whose standard daily work outfit included a micro-skirt that rode up to their hips, when viewed from the side, when they sat down. I am fully aware that one of the reasons for wearing so little covering that one’s underwear is exposed as a matter of course is to assert a woman’s right to wear whatever she wishes without being subject to harassment or unwanted attention. That’s what they say, anyhow.

I met one such woman when I was working on a contract where she was the sales representative for Digital Equipment (DEC). She was, by any standard, a stunningly beautiful woman in her early 30’s, and she dressed the part. Every male eye was on her when she entered a room and she exuded an attitude of secure and infallible sexuality, apparently aware that she could turn any man in the room into a gibbering idiot. Of course, she was not interested in gibbering idiots. She was attracted to the men apparently immune to her charms, the men with power to control others and to face her with serene equanimity.

She was supposed to teach me how to use a new product that Digital was promoting. She did so disdainfully and unwillingly. I worked for a competitive company and she was not keen to share any advantage. I let her go through her condescending dismissive demonstration without comment, then, afterwards, set about teaching myself how to use the product.

I then moved on to the Prime Minister’s Office. I was there for about three months as a consultant to the operations group, helping them to get their procedures developed and documented. As a matter of course I installed the system monitoring tools I had developed over the years. These tools kept track of performance and usage metrics and automatically produced reports on the system’s workloads. When I finished that contract, I went to another computer site for three or four months, but then returned to the Prime Minister’s Office in order to study and make recommendations for facilities management. In other words, produce a report indicated what kind of hardware upgrades they could expect to make during the next two or three years.

I already had my tools running, so, by this point, I had about six months’ worth of data to work with. I would have preferred data spanning a year or more, but, I had to work with what I had. I painstakingly analyzed the data, identifying trend-lines and projecting them, accounting for the interactions between different hardware. For example, if disk space requirements expanded by 50%, are their sufficient tape drives to back up this data within the constraints of the backup windows? That sort of thing. Being the Prime Minister’s Office I had all the latest toys to work with, including a four-color plotter. This was long before color printers and color photocopiers. A plotter consisted of four computer-controlled pens that could be used to draw charts and graphs. I made full use of it.

My report was a masterpiece. Beautiful four-color charts gave immediate visual confirmation of what my words communicated. I had solid lines where there was solid data and dashed lines where it was projected data. Relationships were all clearly identified and illustrated. I had projected the future of the Prime Minister’s computing centre for two years out with indications of what was to come beyond that. I handed in my report.

I was at home nursing the flu a few days later when I got a call that I had a meeting scheduled with the ADM that afternoon. An ADM (Assistant Deputy Minister) is the highest position in the civil service. The Minister of a department is the front-line political appointee and his deputy ministers are his staff, each responsible for a certain aspect or operation of the department. An ADM is as close to god as any human can get without entering the rarefied atmosphere of the political top dogs. You do not say no to an ADM. I showered, hoping that the sweat and sickness would wash away, and dressed in my suit (I did have one suit reserved for just such occasions), which was too hot considering my fever, and drove to the centre of downtown Ottawa.

I was escorted by security to the ADM’s office where a group of half a dozen were seated around a table. They were mainly elderly men with one stunning exception: the Digital Sales Rep who was sitting next to the ADM himself. The ADM was a friendly older man obviously used to wielding power. He congratulated me on my skilful use of colour in my report, then ruefully lamented that it didn’t survive photocopying. (There was no such thing as a colour copier then.) He asked me to summarize the report for the assembled.

I did my best. When I finished the ADM turned to the DEC Sales Rep and asked her for comments. She began by saying, “As we discussed previously…” and then she went on to present her analysis of what hardware would be required, completely ignoring my data and what I had said. It was as if I didn’t exist. The ADM then smiled at me and said, “Do you think you can revise your report before five o’clock today? We’d like to get the RFP out as soon as possible.” (The RFP is the procedure the government follows when seeking tenders for goods and services.)

What choice did I have? I stood at my desk for a long time considering what had just occurred. My report had been honest. I did not agree with the sales rep’s analysis, yet it was clear that the ADM and his team had already bought it. What would I gain by refusing the ADM’s orders? Nothing. I’d probably never work in a government department again. But, if I followed them my integrity would be compromised. We like to think of ourselves as heroes standing for what is right no matter what the cost, but, there are times when you have to weight the consequences. I sighed, and sat down to revise my charts to support the decisions that had already been made.

Later, when telling this story to a colleague he said without hesitation, “Everyone knows she was fucking him.” It made sense. I had picked up a hint of intimacy between them during the meeting. One thing was very clear: they knew each other fairly well before that meeting. But I don’t know the truth and neither did my colleague. “Everyone knows” is proof of nothing. One thing was clear to me: I did not exist in her world; she saw only power—and I had none. I’m okay with that. I am comfortable with the fact that I don’t exist for many people. There is one advantage I have: I can observe them.

Something to think about on 9/11.

I was going to write on what I was working on September 11, 2001, but that seems somewhat trivial compared to the events of that day. However, like many folks, I was confused and my initial thought was that I must have done something wrong. When I dialed the number of a software manufacturer in Islandia, New York I received a busy signal before I got past the area code. After a few more tries my next thought was that my long distance privileges had been disallowed, though I had nothing to base that on and it would have been extremely unreasonable of my client. Still, to confirm, I called home, which was long distance at the time.

Ann answered, so that wasn’t it. “I can’t get through to New York,” I told her. “The whole area code is busy.”

A few minutes later she phoned me back and said that a plane had hit the World Trade Center, probably a Cessna or other small privately-owned plane. At about the same time people on my floor starting muttering about New York, the Trade Center, and a plane. Many of us headed to the operations room where there was a small TV set for use on the midnight shift. We watched in stunned silence as the events unfolded.

What can I say? I am sure many people felt the way I did: slightly nauseous and disorientated, as though coming down with the flu. My brain could hardly take it all in. I left early that day, wanting to be home with my family. The images of people falling from 90 floors or more, the roiling cloud of white dust boiling down streets, an airliner disappearing into a building are all still clear in my mind.

Being in the high tech industry, that’s where my thoughts turned over the next few days. With distributed computing, clustering, hot backup sites, the requirement to house hundreds or thousands of employees in one place was disappearing. Companies would realize this and wake up to the new reality that insanity makes everyone a target; the bigger the target the more likely it will be attacked. I envisioned large companies spread out into small computer-connected offices located far apart in small towns and rural areas. That hasn’t happened as far as I know, but it is entirely feasible. It no longer makes sense to me to herd people into congested inner-cities where they become, not only targets, but contributors to the stresses on our selves and on our planet.

But, I also considered other things. Few realize what the name “Al-Queda” means and where it comes from. It is an Arabic translation of the name of the science fiction seven-volume series of novels called The Foundation by Isaac Asimov. The books encompass the story, covering several thousand years, of the predictions and timely interventions in history by Hari Seldon, a psychohistorian. This one person triggers the collapse of the current corrupt empire and then guides humanity’s creation of a new galactic empire built upon the ruins of the old. The series was published between 1951 and 1986, with the original trilogy produced between 1951 and 1953. There have been several articles published that claim a link between Asimov’s books and the basic premises and modus operandi of the terrorist group. If you Google “al-queda Asimov” a number of the articles and speculative pieces are listed. But, whether you buy the premise that bin Laden read the series and that some of the ideas presented shaped his thinking or not, there are striking similarities. Bin Laden and Hari Seldon had a lot in common. Without a doubt, bin Laden was the hero of his own story.

The idea that society, or the world as a whole, is corrupt and beyond redemption is not new. The idea that a single individual, or a small group of individuals, can bring down the corrupt and build a new utopia based upon whatever bias they have, is not new. We have seen this played out repeatedly in movies like the James Bond series, the classic western, or any of the fantasy-driven franchises that dominate. None of this is new. The Crusades, for example, were based upon the premise that an evil empire had control of the Holy Land which had to be liberated by Christian heroes. Beowulf fought and killed the monstrous Grendel. Moses confronted the Pharaoh and led his people out of slavery. This idea is in Gilgamesh’s battles with the monsters Humbaba and the Bull of Heaven. The story of the hero standing up to evil, destroying it, thus making possible the new utopia goes back into prehistory. In that regard there was nothing original about bin Laden.

…and everyone is the hero of his own story. It’s the others who are the bad guys. Some have difficulty imagining that they are the bad guys in someone else’s story. The certainty that we are right and they are wrong never really leaves us. We simply cannot be the bad guys in someone else’s view because we know, beyond a doubt, that it is they who are the bad guys, so whatever they believe must be wrong. We can write up lists as long as required about their shortcomings and failures, about how they betrayed us and let us down. We can write even longer lists about all the wonderful things we offered and gave them, that they ungraciously threw back at us.

I was sixteen in the fall of 1962 when the world stood on the brink of disaster. For several hours we did not know if this was the end of humans and most of all life on this planet. I recall the distain I felt when the Toronto Board of Education ordered all of its students to assemble in school basements to crouch and cover their heads. How on earth was that going to protect us from an atomic blast? The math and the reality didn’t add up. There really are powers bigger than we are; bigger even than our heroes. Nuclear explosions are one of them.

And it occurred to me as I walked back to the boarding house that day that there was probably someone in Russia, my age, who realized the same thing as I did, and was wondering what do they get out of killing me and everyone else? What’s in it for the Russians? And he was wondering what was in it for the Americans. The image of the average Russian, a farmer or factory worker with no greater aim than to nurture and protect his family, flashed into my mind. What do we have against him? And I have asked myself that question during every conflict since. What did we gain by destroying villages in Vietnam and killing the rice farmers and tradesmen? What good does it do any of us to fire missiles at the homes of accountants and teachers and day laborers? What does it benefit anyone to hijack an airliner and fly it into an office building?

The power of myth is a force difficult to see past. Not only does it blind us, but it directs our actions along paths we would never otherwise consider taking. Nietzsche’s “superman” was not amoral as some believe, but he simply has risen above the divisive power of the myth of good and evil, of us versus them. And that is a genuinely noble pursuit.

But as long as we don’t know the answers and are locked into this mythic struggle, we are in a state of high anxiety. Watch a zoo animal in a cage: it paces back and forth, back and forth because it doesn’t know the answers about where it is; something is wrong but the animal doesn’t know what. I’ve seen confused and frightened people do the same thing. The same movements. The same expressions. Which are you? Which are all of us? Do we control our visions or do they control us?

Common Sense and Security

In the early 1990’s I was sent to a military research station to see if I could help out with a performance issue they were having. The site consisted of several buildings surrounded by a very high steel-link fence (fifteen feet?) and you entered by stopping at a barrier; a commissionair (the government’s standard security; actually retired members of the military) in a glassed-in cage would ask to see your identity card. After my first few days I just held my ID card up to the car window and the guard waved me through. I quickly learned that the base was off-limits to all non-security personnel between the hours of 6:00 pm and 6:00 am. No overtime there.

After I settled in I took a look at the system—which was running very slowly indeed. It didn’t take long to spot a batch job running at an elevated priority; high enough that it was blocking interactive users from accessing the system. The batch job was the daily backup procedure. Two questions: 1) why was the backup running during prime time? and 2) why was its priority raised?

The operator responsible told me it took two 9-track reel-to-reel tapes to perform a complete backup. He arrived at work at 6:00 am to start it, but, as each tape took about two hours, backup time ran into work time. He raised the priority of the job so that it would execute faster.

My first response: it should not take a 9-track tape two hours to fill with backed-up files. Raising the priority of that job was counter-productive because a job cannot run faster than the device it is writing to. Tape drives are slow, but not that slow. Lowering the priority of the job to a more reasonable level and increasing the buffer size, so that it wrote more data at a single time, cut the execution time down closer to an hour per tape.

My second response: why are you waiting until 6:00 am to start the backup? Why not mount a tape before leaving the previous day and have the job start executing at, say, 4:00 am. That way, by the time humans were allowed on-site, at 6:00 am, the job would be waiting for its second tape mount—and that should take less than an hour, thus finishing the daily backups by 7:00 am well before any scientists arrived to start their daily shift.

Both steps were simple common-sense solutions. I sometimes irritated people I worked with by asking: “why are you doing it that way? Why not…” It didn’t matter where I worked or in what field, I usually saw a more efficient way of doing something and ran into defensiveness and resentment when I pointed it out. The only way I was ever truly happy at work was when I was either the “expert” who they had to listen to, or the boss (who they also had to listen to). That way I could implement what, to me, looked like obvious improvements that apparently weren’t so obvious to others. The times when I was in the kind of position where I could make improvements in the work-flow without running into snarling and snapping mother wolves protecting the old ways, I always received praise and complements from higher ups, the reason being that my improvements were genuine improvements: just like resetting job parameters to speed up writing to tape and starting the job before humans arrived to mount the second tape.

They kept me around at the research facility for a while; first, writing documentation, then, when that was done, writing a program that would automatically take the data stored on old 9-track tapes and write it to cassette tapes. Three 9-tracks could fit onto one cassette and cassettes required a lot less storage space. That was fun. I got to explore the actual physical and logical structures that controlled tapes because I had to over-ride them to write three tapes onto one. Of course the program kept track of everything and printed out labels to put on the cassette covers listing the contents.

While I was working on that the system suddenly slowed down one afternoon. What the? I identified an interactive session that was running at an elevated priority. Even though I could do anything I wanted to on a system, having full access to everything, I would never consider raising the priority of my session except in a few exceptional emergency situations. I knocked the priority of the run-away session back to where it was supposed to be. Ten minutes later, there it was, running at a high priority again. Time for a closer look. The account in question was assigned all system privileges. Impossible: I was the only one who was supposed to have such access. Even operators were restricted in what they could do. I fixed the account by stripping away all the privileges that a common user had no right to. End of problem.

Until a few days later. There was that same account running at an elevated priority, locking everyone else out of the system. And, the account once again had full system access. There were only two ways this could have happened: either my—or the system account that was reserved for upgrades—had been broken into; or, someone had unauthorized access to the computer room. It was the latter. In those primitive days of computing we did not have monitors and keyboards connected directly to the computer in the computer room, we had teletype machines. In other words, every command and response was printed on fan-fold paper. That system solved a few mysteries during my career.

Because the console was wired directly into the machine it had access to everything. That was intentional so that a technician could work on a failed machine. Someone, presumably the owner of the account, had entered the computer room and typed the commands necessary to give his account full system access. Now most computer rooms were locked with a card-scanner or a cipher lock so that only those who needed to be there could actually enter the room. You would think that at a secure military research site that this basic security feature would be in place. It was not. The computer room door was left wide-open at all hours.

I reported the incident to the security team who immediately had the computer room locked. The employee was given a stern dressing-down and warned. I heard from the people working at the site a few months after I had moved on that the culprit had been caught trying his old trick again and had been fired on the spot. So, what had he gained at the expense of his career? a few minutes of uninterrupted access to a CPU. It wasn’t as if he was doing important work at the time; he had been playing a computer game.

The Commodore-64 and contemporary programming.

I was just starting out in my high tech career in 1982 when the Commodore-64, the first commercially successful home computer, was introduced. It was cheap, at under $600, and a large number of applications and games were produced for it. Though I wanted one, I couldn’t afford it with a young family while transitioning careers. However, the schools were anxious for programs that could be used as teaching aids and were generous about lending them to anyone who could write a few lines of code. I took full advantage of that opportunity and wrote many little games that could be used in the classroom. Eventually, I was given a retired Commodore-PET—a much more limited version of the C-64—and so happily wrote little programs for my boys to play with.

Like the Apple II, released about the same time, the Commodore did not have an operating system as we know the term today. It came with a BASIC interpreter and, by using low-level “poke” and “peek” commands, programmers could access the very limited monitor and sound chip. Magazines, like Byte, regularly printed the hex codes for accessing various functions of the C-64, and printed out entire programs for users to type into their computers. The C-64 did not come with a disk drive; Programs had to be stored on cassette tapes. If you were a fast typist you could input most of an entire program in the time it took for the tape drive to load its contents into RAM.

Though there was a huge gap between the home computer and the serious mainframe computers I used at work, I did learn some valuable programming lessons on the C-64 and PET. Because it was such a primitive and limiting interface programmers had to be constantly aware of what they were putting into RAM. A program would simply run out of room at about 32 KB as the rest of RAM was given over to the BASIC interpreter and some low level functions, such as communicating with the keyboard. In other words, from the programmer’s point of view, every bit counted.

This meant that one had to learn how to write efficient code. However, it reinforced another bad programmer habit: it discouraged the imbedding of comments in the code to explain what was going on because comments took up valuable RAM. There was an entire class of programmers who could write dense complex code that was unintelligible to anyone else. If it broke, you were stuck because chances were good that you would not be able to unravel its secrets without a lot of help from the original programmer.

The monitor was wide enough to display 40 characters and characters were generally 8 by 8 bits. So, we never had reason to count pixels. But, within the limitations of the chunky slow graphics all sorts of small applications could be written. Most of the games I wrote involved a moving graphic, either under control of the user through keyboard commands, or control of inner logic. Given the type of programming limitations, the most effective way to discover where the graphic was in relation to other “objects” on the screen was to “peek” ahead to the next character position. If you had planned correctly you could figure out which was the bat or paddle and which was the edge of the screen. Movement was controlled by incremented or decrementing simple x and y coordinates.

It didn’t take very much code at all to replicate some of the commercially-available games. A “pong” program (bouncing ball with two paddles) could be written in less than 20 lines of code. I wrote a successful copy of the “Breakout” game (a bouncing ball smashes its way through a brick wall of differently-coloured and -valued bricks.) It was fun. But here’s something important that I learned.

I mentioned that to determine where one object on the screen was in relation to other objects on the screen, I could use a “peek” command to see what was coming next. As long as I was “peeking” ahead only one character position at a time, there was no problem. I would “collide” with another object or the screen border and reverse my coordinates to move the ball, or other object, away from the “barrier.” No problem.

But, something odd would happen if, in order to speed up my moving object, I were to increment or decrement by twos—or even some larger number. The program would “work” for a few moments and then the ball would disappear from the screen. After another few moments, the program would freeze, usually with an annoying whiny sound.

The only way out was to “break” into the code and go looking for the problem. The first few times I did this, without really understanding what was going on, I was annoyed to discover that my code had been changed. Sections of lines had been erased and some characters had been turned into unrecognizable junk. I fixed the code, ran it again, same result, same changes in the code.

Hum….

I eventually figured out what was happening. The Commodore, in its primitive state, did no error-checking on its own. Whatever you wrote, it would do—or die trying (which it often did). When I started peeking ahead by more than one character position at a time, there was a good chance that I would miss the actual screen boundary—and my “ball” would keep moving in the direction it had been going. No, the virtual ball would not emerge from the side of the monitor, but it would leave the area of code that described the monitor to the system. There wasn’t a heck of a lot more in RAM in those days, so the ball would “move” through the area of RAM where the program code resided. As it bashed into areas it had no business being, it made changes until the program could no longer function.

Modern programs cannot behave like that. The operating system makes sure that code instructions do not access areas in RAM where they shouldn’t be. The operating system itself is protected. The areas allotted to other users or applications are out of bounds. The program code itself is out of bounds. If a program does increment or decrement outside of the area it is supposed to be confined to, an immediate fatal error is issued bringing the program to a halt. That’s why programmers are supposed to always know where their program is operating and what, exactly, it is doing inside of RAM.

Of course, they usually don’t have a clue. Programming has become automated and the layers of complexity between the program code and the underlying machinery have become so thick that no one can really know. “Code generation” programs abound so that the programmer doesn’t need to know anything about the physical nature of the computer. “Drivers” (which seem to be permanently out-of-date) wrap every piece of hardware in nice thick mushy layers of code so that no metal is seen by the programmer—or user. A result: users aren’t the only ones with no understanding of the physical processes that make their computers function.

Teaching Programming; Part 5: RAMing an F?

Now we get to the fun part of what I had to teach my Algonquin college students about the C programming language. In the last couple of talks I laid out some of the basic principles. I pointed out that we can store a list of names by using symbols to stand in place of the data—and that these symbols act like containers. We used name(x) to get the individual entries in the list, where x is a number describing where in the list the data we want is located.

What are we actually talking about when we talk about data and symbols? Simply this: everything a computer does or works on is located in Random Access Memory (RAM). When we tell a program to start running (by double-clicking on its icon in Windows), the computer has to locate the code for the program on a disk-drive and copy it into RAM. From then on, everything that the program references is an address in RAM. For example, your program is loaded into memory starting at address 435A6B7E. All the symbols in your program can now be interpreted in relation to that first address. When your program needs to read some data, it fetches it from the disk drive and loads it into RAM starting at a different address and tells your program what that address is so that it can find and use it. So, your symbol “name” might be at address 345A6C89 in your program code, but the data it is referencing could begin at address 4563EE12. When we tell our program to work on the data in name(x) we are actually telling it to go to the memory address that name(x) has calculated and start working on the data found there.

Clear as mud, right?

That’s how my student felt, too.

The point is: data and the place (address) in RAM where it is temporarily stored are two different things. It is like telling a window-cleaner to go to 546 Main Street and clean the windows there. Whatever he finds there is not the same thing as the address and he will clean the windows found at that address, not clean the address itself.

We have to keep that straight when programming or else we might inadvertently tell our window-cleaner to go to “windows” and clean the “546 Main Street”—whatever that is. And, this is a very common programming error. We see it whenever a Windows program “crashes” (i.e. stops working abruptly and returns control to the operating system). It has either run into data that it is not prepared to handle (for example, a window-less building where the window-cleaner has been ordered to clean the windows); or it is trying to locate an address in RAM that it has no business accessing (such as where the operating system instructions are stored, or, more commonly, address “0”). Competent programmers are not supposed to mix up what is data and what is an address, but they do. I got caught by that once after I had been writing programs professionally for many years; they can be nasty—and sometimes very subtle—errors to track down and fix.

My students had to know the syntax for fetching an address and the syntax for fetching the data at that address. Sometimes, to further complicate things, we might find another address at the address where we are looking for data—and we have to know the difference so we can instruct our program to go to the second address instead of treating it like ordinary data.

I know it’s difficult to understand when you first run into it. But we worked at it and most students managed to pass the course.

However, one young woman had a rather unique way of handling the situation. I gave a review quiz every second week of class. I would take them home to grade, then return them and go over the answers in the next class. This young woman was consistently sick whenever we had a quiz, but always showed up for the next class where I’d be going over the answers. She would ask for a copy of the quiz so she could follow along. Fair enough. After we had finished our review of the test, she would bring her paper to me, asking me to grade it so she could make sure she had gotten all the information correctly so she could study from it. So, I did. She usually still had a few errors even though we had just discussed the answers.

I thought nothing of it and gave her an F for the course on the grounds that she had not completed any of the course work. (I believe she was also sick for the final exam—a terrible, unpredictable disease that always struck at quiz or exam time.) In any case, after the students had received their grades she phoned me at home to complain. How could I have given her a failing grade? She had all the tests and had “passed” them all. I tried to explain that writing down the answers during the review was not the same thing at all as writing the exams when they were scheduled. She was adamant and phoned me several times, making a pest of herself. Finally I gave her the phone number for the college ombudsman, asked her to take her case to him and said I could not discuss it any further with her.

The ombudsman called and asked me for the story. “Okay, I get it,” he said when I finished. I never heard any more about the case, but I am confident that my F had stood.

Need to Know

In computer programming letters or words are used as symbols standing for information. For example: the symbol “name” can stand for “Mary Jones,” “Jack Smith,” or “Thomas Mann.” The symbol is “name;” the data is “Mary Jones,” “Jack Smith,” or “Thomas Mann.” Don’t worry yet about how we get there: just think of “name” as a container that can hold any one of the given and family names of our individuals. If I arrange my people in a list then I can refer to them as name(1), name(2), name(3).

Alternatively, the symbol “x” can stand for any number. If I want to count from 1 to 10, I can increment (raise by step) the value of a symbol that stands for a number. A common way of notating that in many languages is: x = x + 1. In other words, you take the number that is represented by “x,” add 1 to it, then store the result back in the symbol “x.”

Putting these two ideas together we can tell the computer to fetch all the names in our list by using the two symbols “name” and “x” as in “name(x)”. We don’t know—or even care—the content of any of our containers. We just know that if we tell the computer to print whatever is in container “name” in row number “x” it will print out one of our names—depending on what the value of x is.

Now you know everything there is to know about computers. Almost.

In the two examples above, our symbols represented actual data, whether it be names or numbers. If you tell the computer “print name(2)” it will not print out literally “name(2)” but will, instead, print out the data represented by those symbols. In other words, it will print “Jack Smith.” A computer can do thousands or even millions of these kinds of data retrievals in a second (though it will take much longer to actually print the list). If you had a list of the name of every person in Canada you could have a computer fetch any name, sort the list by any key you wished, find all the people named “Smith,”—or whatever you can think of doing with such a list—in the blink of an eye.

But, what if you wanted to manipulate the data in another section of a program? For example, you might want to reverse given and family names. So, you would write a routine that would parse (split into parts) the contents of name(x), then put the parts back together in reverse order. Such commands might look something like this:

first, last = parse(name(x),” “);
name(x) = last & first;

(We are assuming that the computer language has some sort of “parse” command built in that will split a string of characters using whatever delimiter (in this case a blank space) you tell it to use. And we are also assuming the language uses the symbol “&” to concatenate two individual pieces data.)

Did you notice what we did? We changed the data stored in our symbols “name,” row “x”. I mentioned that our procedure that did the name reversal was “in another section of a program.” We do this so that we have to write the commands to reverse the names only once. If we call our name swapping section “switch,” for example, then, in the main part of our program all we need to do is tell the computer to go to section “switch” and execute its operations on the data we have selected. And, because we are fetching our data by using a symbol called “name” and the information in “name” is in rows called “x,” we can write a compact little program. Sort of like this:

x = 0;
while (x <= 10)
x = x + 1;
print name(x);
switch (name(x));
print name(x);
end while;

The section we have called “switch” would be along the lines of the two lines of code that we wrote above. (Here we are assuming that the characters “<=” would mean “less than or equal to” in the language we are using.)

When we passed our data to the section called “switch” we were telling it to use the data that is represented by the symbols “name” and “x”. The “switch” routine then did its thing and changed the data stored at that location. So when x equals one, our program would print:

Mary Jones
Jones Mary

As the value of x is incremented it will do the same thing with the other names in our list.

But now, what if another program wanted to use our little “switch” procedure and, instead of using the symbols “name” and “x” to stand for data, it uses the symbols “person” and “number”? It will make no difference to our “switch” routine. It would still split the data into two parts then reverse them. The data represented by the symbols person(number) in the new program would be exactly the same as the data represented by name(x)in our procedure.

So, do you get it?

When I worked at Corrections Canada I wrote programs that fetched the data about their clients. I did not care what the actual data was—nor did I want to know it—all I had to worry about was the format that the data was stored in so that I could extract whatever part of the entire information field I needed. For example, if my manager told me that a senior official wanted to know how many persons are in federal prisons who were convicted of non-violent crimes and have less than six months left in their sentence, I could write program that would get the data based on that information (non-violent; less than 6 months) and count them. Bingo! Zip! As fast as that I would get an answer that I could email to my manager (who would pass it to his supervisor, who would pass it to his department head, who would send it to the department head where the senior official worked, who would send it …on and on until the information reached its destination.) My job would be in serious jeopardy if I had emailed the answer to the senior official directly.

In any case, the distance I had from the data about our government’s long-term guests was called “Need to Know.” The only thing I needed to know about was the format of the information about the prisoners. I didn’t need to know their names or any of the myriad of personal details that the government stores about its guests. No matter what projects I worked on, whether at a military research lab, a national library, or the prime minister’s office, the format of the data was all I ever needed to know. I really didn’t want to know more than that.

Teaching Programming; Part Four: Finding Things the Computer's Way

There are a few basic concepts one has to get across if students are ever going to understand and work with computer languages. I’ll get to one of the most difficult in another story, but, first, an easy one.

Databases, indexed files, and the like, keep track of where everything is by using indexes, sort of like the index in a book. Keywords are stored separately from the actual data and stored with each keyword is a number; that number being the address of where the complete record is stored. Make sense? You want to find out something about “blogs” so, you look up the word “blog” in the index of a book which lists the numbers of the pages in the book where you will find information about blogs. Computers handle information pretty much the same way. I want the record for “Smith, John” who lives on “King Street” so the computer will look those terms up in its index and come up with the address of the memory location where the complete record that matches those two criteria resides.

Every location in computer memory has an address associated with it. A typical address might look like: 1A78C4DF. If you’ve been following these entries, you should recognize that as a hexadecimal number where each digit represents four bits of information. In other words, 1A78C4DF represents a group of 32 1’s and 0’s, and 32 bits can represent 4,294,967,296 integer numbers—which is why Windows computers based on 32-bit architecture can address a maximum of four Gigabytes of RAM (actually about 3.6 GB). Folks running computers with XP, for example, waste their money if they buy more than 4GB RAM because their machines simply can not address the excess storage.

The point of all this being: each 32-bit piece of information has a unique number associated with it so that the processor can find it when needed. (In reality it has an "offset" number rather than a fixed one.) Having said that: what is the fastest way to locate a number from a list where you know the end points (the lowest and highest numbers)? That’s what a computer has to do when it looks up data for you. It could start at the lowest address and work its way through the list one at a time: is it location 11111111? No? How about location 11111112? And so on. It can take a very long time to find a specific number (or address) using that method. Starting at the other end won’t help. Theoretically if you start at the lowest or highest number and work your way one at a time through the list you might have to actually look at every number in the list. If your list comprises the numbers 1 through 100 and you start at 1, if your target number is 100 you will have to look at 100 numbers to find it. There’s got to be a faster way—and there is.

I would ask a student to write a number from 1 to 100 on a piece of paper and then say I was going to tell her what the number is in seven guesses or less. All she had to do was answer “higher” or “lower” until I got the number. I started at 50. (Let’s assume all her answers were “lower” to make this description easier.) 50, 25, 12, 6, 3, 2, 1: yes. As you can probably tell, all I did was split the difference between the guess number and the closest known number in the direction (higher or lower) that the student told me to go. Let’s say I’m trying to find 36. Here’s how it would go: 50: lower; 25: higher; 37: lower; 31 higher; 34: higher; 35: higher ;36! Seven guesses maximum (less if I had picked 36 instead of 35 as the difference between 34 and 37).

This called a binary search (binary meaning two: you divide the difference between your guess number and the closest known number in the given direction by two.) Computers might be fast but when you compare seven guesses to find a number to potentially one hundred guesses out of a list with 100 items, a binary search comes out ahead almost every time—and computers usually have a lot more than 100 numbers to search when looking for information. A binary search will not always be the fastest way, but, if you do thousands of searches through thousands of numbers, overall, statistically, a binary search is the winner.

Students were usually delighted to discover this trick and I’d give them time to play with it between themselves. Like most tricks, it’s not really a trick at all: it’s applied logic. Data often has implied information associated with it and if you can figure out how to identify that implied information and apply it to your problem you’ve gone a long ways towards becoming a programmer. In this case, each number in our list has a relationship with our target number: It is the target number itself, or it is either higher or lower than it, and by exploiting that information we can make our search for it much quicker and more efficient.

By learning how to teach computers how to solve problems we are sometimes teaching ourselves how to solve our problems in other ways. It’s all in how you look at it.

Teaching Programming; Part Three: A Colossal Blunder

After the Christmas break, I was to teach my class the basics of the C language. Now this was more like it; I had spent the previous three years as a full-time C programmer so I was very comfortable with the language. However, in the first class of the New Year I made my first mistake.

I announced that we were going to teach a computer how to play Poker. I thought this might generate some excitement; instead, I got a number of puzzled looks. No one said anything, so I began by explaining that we first had to break the program down into discrete data and procedures. The logical place to start was to define what a deck of cards is to the computer. So, I wrote the playing card sequence on the board in four columns, each column headed by an initial to indicate the suit. Already I sensed that I had lost some of the class.

A group of women wearing dark clothing were whispering together, so I thought this a logical place to step in and clarify what was going on. I asked them if they had any questions. They shook their heads no and giggled.

I sketched out a two-dimensional array where we would store the deck of cards. I assigned the “2” cards to row 1 and worked my way up to the Aces, which was in row 13. I then wrote the numbers 1 to 4 at the tops of the columns (which I had cleverly arranged in the suit hierarchy of Clubs, Diamonds, Hearts, then Spades, so that Clubs was in the lowest numbered column and Spades the highest.) I now had all the cards in a deck arranged in a two dimensional pattern that happened (by design) to mirror the relative value of the cards and suits. The two of Clubs, the lowest ranking card in a full deck, was in position 1,1. The Ace of Spades occupied the highest value box: 13,4.

I explained that with this array, not only did we know what a deck of cards looked like, from a computer’s point of view, but we had, at the same time, established the relative values of each card in the deck simply by its position in the array (by concatenating the two numbers that made up the array coordinates. So, the two of Clubs would be worth 11 (from position 1,1) and the Ace of Spaces comes out to 134. The values of the cards with face values of 7 would be 61, 62, 63, 64; while the cards with a face value of 9 would be 81, 82, 83, 84 respectively. Thus any card with a face value of 9 was worth more than any card with a face value of 7, but a 9 of spades was worth more than a 9 of diamonds.)

Before going on to define the relative value of different combinations of five cards by assigning values to different configurations, it was time to ensure that they got the concept. So, I asked them to evaluate different pairs of cards and determine which had the higher value. I thought this was pretty straight-forward. All they had to do was find the card by its numeric order and suit on the array, create its “value” by concatenating the coordinates and compare the result to the value of another card. For example: which is worth more: the Ace of Hearts (133) or the Jack of Diamonds (112)? They were hopelessly lost.

I gave them a number of such questions and asked them to work in groups while I went around to see what was going on. I was startled to get questions like, “What’s a J?” and “What’s the difference between spades and clubs?” The light slowly turned on in my head: Arabs do not play cards. Most of them had probably never seen a deck of cards before, let alone become familiar with the values and suits.

Realizing my god-awful mistake and knowing that I had just wasted a good hour of class time as well as probably offended the students who I hadn’t simply baffled, I sent them on a break while I tried to gather my thoughts and figure out a different approach to teaching them the purpose and some of the applications of arrays. I was thankful that the curriculum covered only two-dimensional arrays and not 3-, 4-, 5-, or x-dimensional ones.

Teaching Programming, Part Two: Y2K

Amazing how disappointed people appeared to be when planes did not start dropping out of the skies and governments didn't stop functioning. The Y2K crisis was then dismissed as a big hoax, a fuss about nothing. However, if they had any idea of what was going on in the computer-world world-wide for the previous 18-24 months people wouldn't have been so blasé about it. The reason we averted a major disaster was that computer programmers had been working their butts off to identify and fix as many Y2K bugs as they could uncover. That Windows and its applications were not affected was a matter of good planning, at best, or dumb luck, at worst. And, that's what most people think of when they think of computers. Didn't affect my computer games, so why should I bother? Also, large companies do not admit publicly that they have computer difficulties; it makes clients nervous. Rumors were that at least one major bank had serious problems. Other failures, such as some American slot machines, were regarded as trivial and so were not reported widely in the press.

At Algonquin I had to get across the reason for the bug and how to identify and fix it to a group of students who had virtually no computer experience. To do this I had to teach them the rudiments of an obsolete computer language that was meant to handle applications of a sort they probably had not seen before. COBOL was a business-oriented language. It was good for adding up expenses and tracking inventory and sales. It was a major job in itself to show someone who did not know how to operate a cash register how businesses calculate profit-loss and capital depreciation, let alone how to do it in a language they had never seen before that ran on computers they had almost no experience with. Add to that language and cultural barriers and you have a task almost impossible to complete in about 25 3-hour classes.

But, I tried.

The Y2K bug was really quite simple. Generally speaking, computers track time by incrementing a counter beginning at a given start time. Unix systems start counting seconds beginning at 1 January 1970 00:00:00 UT. Windows NT counts the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT. (One nanosecond equals one billionth--or .000000001--of a second. For example, light takes 3.33564095 nanoseconds to travel one meter in a vacuum). These numbers are stored in a group of 128 bits--sometimes 256 bits depending on the accuracy needed. There is no problem inherit in that. Where the problem comes in is that programs get the date, or time, from that group of bits and then manipulate it. Different computer languages have different degrees of accuracy. For example, COBOL can get time from the internal clock to the second while Java Script can fetch time to the nanosecond.

Often programmers want to display the year as a two-digit number. This works okay when you are in mid-century, but, when you get to both ends of a century you are going to run into dates that in are another century--and that is going to cause problems. To make matter worse, sometimes those 2-digit numbers are used mathematically to calculate things like the number of days between events or to forecast a future date (eg., what's the date 90 days from now?) As a result, some computers could not tell the difference between 1900 and 2000; others insisted that the year after 1999 was 19100. Some programs calculated that the year two years before the year "01" is a negative number(01 - 2 = -01). Where these kinds of errors occur, systems crash, or display bizarre results in place of the year. (For example, instead of “00” for 2000 you might see “A&” or some other random collections of characters.)

There were two main methods that programmers used to reduce the year to a two-digit number. One way was simple to subtract 1900 from the date so that
1998 - 1900 = 98. However, if you subtract 1900 from 2001 you get 101 which takes us right back to the original problem. The computer might display this as “10” (taking the first two digits) or as random characters.

Another way was to turn the year into a character string and simply chop off the first two characters. However, you can’t do arithmetic with characters, so this method was not very popular. The solution I used for one Y2K contract I had was to do the arithmetic needed using a four-digit year and, only as the final step when the year was to be displayed, did I switch it into four characters then truncate the first two characters.

These were generally the kinds of solutions employed. To make the field reserved for the year four places could easily be done in new programs as it was just a policy decision. Older programs required a great deal more effort and programmer hours. An ingenious solution was to change six-digit dates (11/31/87) from three two-digit fields to two three-digit fields by converting the month and day to a three digit ordinal number (so 02/28 (February 28th) became 059) and the year could expand to three places, sometimes by dropping the second digit (making 1998 into “198” and 2001 into “201”). Another way of fixing it was to retain the year as two digits and include the century as a separate piece of information that could be fetched when arithmetic calculations were required.

If your head is spinning by now imagine that you are hearing this in a language you barely comprehend, from someone who looks and acts oddly to you (he expects females to address him directly and he wears pants instead of robes). Add to that the unfamiliar setting, unfamiliar weather, strange foods and customs, and you might be able to comprehend what my students were struggling with.

However, we stuck with it and most of them passed the course, though I wouldn’t have hired any of them to actually do any work on the problem.

Teaching Programming, Part One

In 1998-99 I took on teaching an evening course at Algonquin Community College. Algonquin has a huge campus; it grants diplomas in a very wide variety of fields, mostly work-related. In other words, it's not where you would go if you want to study the humanities. In the fall term I was to teach an introduction to programming in COBOL, with emphasis on the Y2K problem. COBOL was obsolete, but a lot of businesses were still dependent on code written in that language so there was a perceived need for people who could read and fix COBOL programs. In the spring term I taught an introduction to C.

My students were mainly in their 20's. Very many were fairly recent immigrants. I had a largish group from Latin America who worked together, but the overwhelming majority were from mid-eastern countries. The women wore heavy multi-layered dark clothing, and some wore hijabs. The men wore western dress, usually jeans and open-necked buttoned shirts. Almost all sported mustaches.

My previous teaching experience had been in secondary school teaching adolescents. Though many were Algonquin, they were all western (Christianized) in attitude. I had also taught seminars and short courses to people in the high tech field. No culture clash there. But, I was totally unprepared for some of the issues I faced with adults from the mid-East.

First, many regarded it as rude for me to address a female directly. If I did direct a question at a woman, she would hide her face and her companions would start giggling. I would not get an answer. Males, on the other hand, were hyper sensitive about perceived challenges to their masculinity. I had to tread as carefully with them as I had to with 14-year-old boys when I taught in high school.

Generally, we got along. I tried to adjust to their expectations and eventually most seemed to realize that I was not there to convert or harass them in any way. But, I did have a serious problem: none of them were prepared for the concepts that I had to impart. Computer languages are not just sets of keywords and rules; they have a syntax and a style unique to each language. When approaching problems in programming you need to be able to see the solution broken down into a step-by-step process with nothing taken for granted.

How computers recognize data is another problem. Bits are either on (set) or off (clear). Bits are grouped together so that eight of them in a row make up a byte; bytes make up words, longwords, integers, boolean expressions, floating point numbers, and so on. Early personal computers could process four or eight bits simultaneously. Then 16-bit computers reigned for a long time before 32-bit processors became standard. Now personal computers that can process 64 bits at a time are available. Every increase like this represents an exponential increase in computer power and speed. You have to know this and understand it so that your programs will make sense and work.

Getting people to see the difference between the number 1234 and the characters 1234 is often difficult. Numbers can be manipulated mathematically; characters cannot. Human don't care whether an integer they see on a page is a character or a number because they can treat it either way as needed. Computers cannot do this. It has to be a number or a character and the computer cannot simply switch from viewing it one way to another as needed. We have to do it for them. To complicate matters the basic operations of computers are done in powers of 2, as pointed out above. The most efficient way to treat numbers, then, from the computer's point of view, is as hexadecimal numbers. What this means is that a number that can be represented in four bits can be precessed as a unit. Two four-bit units can make up a two-digit number and can be expressed in a byte--which a computer can process in one step.

Look at it this way: we can use only 0's and 1's to represent all data. So, when we count, using only 1's and 0's we get: 0, 1, 10, 11, 100, 101, 110, 111, and so on. We call this series, binary numbers ("binary" meaning two, because we have only two digits to work with.) By "counting" in the numbers we usually use (decimals), we can determine that binary 10 equals decimal 2, and binary 111 equals decimal 7. (It helps avoid confusion if we do not name binary numbers as if they were decimal. We name them: one, one-zero, one-one, and so on.) If we use four bits the highest number we can make is 1111, or 15, (in decimal counting.) So, with four bits we can make numbers from 0 to 15. If we go above 15 we are going to have to start adding more bits. So, 16 = 10000 (made up of five bits). As said above, the most efficient way for the computer is to see numbers as groups of 4-bits.

Here's how we count in hexadecimal: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.
"F," as we should be able to figure out by now, is the same as our decimal number 15. What happens when we want to represent 16 as a hexadecimal number? We do the same thing as we do with decimal numbers: we increment the "10" position. So, decimal 16 in hex is 10. Now we can count using the same method: 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F. 1F (which in binary is: 11111) is equivalent to the decimal number 31. The next number after 1F would be 20, and so on. Now, by using two groups of four bits, we can make an 8-bit number which is 11111111 in binary, FF in hex, and 255 in decimal.

Now we have arrived at a situation where any combination of two hexadecimal "digits" can be used to represent 256 possibilities (counting 0). All characters of the alphabet, upper and lower case, as well as digits and punctuation can easily be represented by 256 2-digit numbers (from 00 to FF). Or, we can use 2-digit hexadecimal numbers to represent 256 colours. We can use a pair of such numbers to represent coordinates on a screen (giving us 65536 unique points, from 0,0 to FF,FF). If you worked with early personal computers you probably saw a lot of 2-place hexadecimal numbers.

This is just one example of the kinds of changes I had to make in the students' thinking and processing. When they saw something like A1, they had to see it as a number (decimal 161). If they saw 1554 they had to determine whether it was a group of characters or a decimal number (or, possibly, a hexadecimal number). They had to recognize immediately that a set bit (value 1) always represents on, yes, true; while a clear bit (value 0) represents off, no, false. They had to get used to ideas like "flipping bits" (changing a 1 to a 0 or a 0 to a 1). They had to understand basic logic sentences like "If a then b else c." and "If not a then b = c."

I had thirteen weeks, two evenings a week, to not only get all this firmly in their minds, but to teach them enough COBOL that they would be able to recognize dates that were going to cause problems when the clocks went from 1999 to 2000 and how to fix them.

What Does an Analyst Do All Day?

When I first took over the position of project manager with a team of programmers answering to me, there was a "Bring Your Kid to Work Day." So, I took my eldest with me thinking, erroneously, that he might see first-hand what his old man did for a living. At the end of the day he concluded that I did "nothing" at work and he wasn't shy about letting everyone he knew know that.

Well, I received a pretty good salary for "doing nothing." In a sense, "doing nothing" was a sign of success; it meant I had no crises to attend to and it happened there were no client or status meetings scheduled for that day. However, I was "working;" it's just that he didn't see my seemingly casual conversations with different folks around the office, both with my employees and with other analysts, as "work." He didn't notice that we were discussing programming strategies, working out solutions to non-urgent problems, and the way that all the various parts of application development fit together. There is a lot more involved than someone sitting at a computer writing lines of code.

First, there's a needs analysis. There's no point in spending hundreds of hours developing something if it already exists, or, if it is not commercially viable. "Commercially viable" does not mean a top seller. What we did was business-to-business sales. In other words, we had to have a client or two who was willing to pay for the product before a single line of code was written. Cost-benefits calculations also worked into the development plan. You could not afford to take on a project that would involve potentially thousands of man-hours if the potential revenues did not at least cover your salaries and other expenses.

Preliminary technical outlines of the final solution were needed by the sales folks because they would have to sell something that did not yet exist. They would also need comparisons to similar products, or products in a related field, to demonstrate where your proposal was superior and worth the effort. Analysts were required for all this work. In theory nothing should be done in the area of development until a signed contract was in hand, but, in reality the preliminary work had to be well underway by that point.

Both general and specific goals of the product were needed as they would get turned into, or were driven by, "deliverables." That is, the description of the end-result that the buyer would have to "accept" before the project could be called complete and final payment was due. The deliverables were also worked into the quality acceptance plan that would be developed. Quality acceptance meant careful definitions of what, exactly, the program was to produce and within what guidelines or parameters. Tests would be developed to measure this. This is called "scoping" the project. One thing you wanted to avoid was some programmer getting a bright idea and spending time on a feature that the purchaser did not ask for.

The actual plan of approach to the writing of the code needed to have a general outline with delivery dates (that is, when various parts were supposed to be done to the purchaser's satisfaction) and detailed plans so that the various programmers assigned to the job knew precisely what was expected of them. Someone had to oversee their work and keep them on track, making adjustments to assignments and personnel as required. That was my job in this case. So, chats with the head of quality control, with the database designers, with the writers responsible for delivering documentation, with project directors, with sales folks, with client liaison, with networking and operations (the back-room folks), and with senior management were all part of the job. Just keeping in touch to insure that everything was in sync and on schedule.

I got my position by default. I had quickly become the top C programmer on the project as well as a specialist in other odd parts, such as a routine that had to be written in LISP (an obscure and difficult language to work with). However, the original project manager proved to be not up to the job and he was demoted to managing the programming team. He couldn't handle that job either. There was no one left in the organization who was specifically qualified, so I just started doing the job. Then the president made my position official and I was given hiring and firing rights. The first person I fired was my former boss. I then set about building a team of highly skilled programmers.

I had a scheduled meeting with my entire team once a week. That's where I'd pass on any news from higher up in the company, discuss points of company policy, and go over any topics of general interest to the team. We'd then go around the table and each member would describe what they had accomplished in the past week and were encouraged to bring any problems they had encountered to the table so the rest of us could make suggestions or offer solutions. I'd also go over the plans for the next week and lay out what was expected from each member. I would make sure that they agreed with their job assignments. I did not want an unhappy, grumbling, and backstabbing team. I think I succeeded in that regard.

I would meet with the company president once a week to bring him up to speed on what was going on in my area. Also at that meeting was the fellow responsible for co-ordinating everything with the client. However, outside of that meeting he never had anything to pass on to me. He spent almost his entire day, every day, on the phone with client reps going over their requirements. It would have been very helpful if he had delivered information from the client to me, but, he never did. So, in the meeting with the president he would go over the charts he had prepared, and then I would report on what was actually going on. It might as well have been two different meetings, as his charts had nothing to do with what we actually did. I did not deliver charts--I verbally reported on what was happening in a conversational mode.

So, that's what I did in one "analyst" position. I also worked as a performance and capacity planning analyst for clients during my career and that had very different job requirements. Ironically, I spent my last five years in a "support" role, which, in a sense, was a demotion for me, but, it was also the job that made the least demands on me and paid the highest income I'd received during my career. I had started in the field as an operator in 1983 making $11,000 a year and wound up in 2004 with a fairly good reputation and an annual income of well over $120,000--in other words, more than 10 times what I had started out with. Not bad for a job where I did "nothing."

Morning Prayers

My first contract as a self-employed consultant was to begin when the Ice Storm of 1998 struck. It was just as well I hadn't had my contract approved yet and so could not begin work until the proper committee met because I needed to be home during the next two weeks during long periods with no power, no telephone, and three children unable to attend school. My wife, meanwhile, braved the bizarre weather and highly dangerous road conditions to drive to work, combined to and fro, up to four hours each day. She did not miss a day at the office, unlike probably hundreds of thousands of others.

After two weeks, the worst of the storm damage cleaned up, I was due to start at Transport Canada at 7:30 on the Monday morning. Despite my best efforts, I did not arrive at the downtown office tower until 7:35. The meeting I was to attend was already in progress and I was told that I could not interrupt it. I waited. The meeting ended some twenty minutes later and the attendees filtered out. My contract manager was a ferocious-looking fellow with blazing red hair and huge mustache. He always seemed to be angry about something. When he saw me he said, "Perhaps I didn't make myself clear. You are to be here at 7:30, not 7:31."

I mumbled apologies and set about learning about my new position. Being self-employed I had a lot of overhead expenses that employees do not have. For example, I had to pay both the employee contribution and the employer contribution to the federal CPP plan. I had to pay the Goods and Service Tax (GST) on any money I made. The really expensive part that employees probably never think about was that I had to buy my own medical and dental coverage. Individual plans are far more expensive than the group plans that companies get. After income taxes (which I also had to pay out of my income--I had no such thing as a kindly employer holding back funds to cover that sort of thing), medical insurance was my biggest expense. Though Canada has Medicare, it does not cover subscription drugs, eye glasses, dental work, and other expensive procedures. I also paid for long-term disability insurance (which resulted in a long legal battle a few years later that I sort-of won. In other words, I never got the coverage I paid for, but I did get a sizable settlement from the insurance company.)

For the rest of my self-employed career I heard grumblings from regular employees that I worked alongside about how much money I was making. But, when you got right down to it, after all my expenses, I had about the same after-tax income that they did. Add to that that I was not entitled to Employment Insurance which meant that when my contract ended I had no government-backed income to depend on. And, self-employment contracts were much, much easier to break than employment contracts. At any moment I could be told, "Sorry, Ron, but we don't need your services any more. Please clear out your desk." I had no union or government regulations to protect me from arbitrary decisions. Oh, and I had to be very careful about how I ran my business so that Revenue Canada never got the idea in their heads that I was really an employee in disguise (which it did in a major crackdown after I was out of the business--a move that cost both sides of the contracts a lot of money.)

So, the title of this piece Morning Prayers could refer to the insecurity of being self-employed, but it really refers to the meetings at 7:30 at Transport Canada. At that meeting representatives from the department across Eastern Canada "met" in a conference call to discuss any technical problems encountered the day before. It was called "Morning Prayers" because one (especially me) had to be prepared to discuss any event in detail covering a multitude of related issues. If you weren't fully versed in all aspects of the problem, you had better have said your prayers.

That, in a nutshell, was my job: to know in detail about any technical problems and issues and what was being done to rectify them and ensure that they did not repeat. I spent my day getting ready for the next morning's meeting. To do this, I was to monitor two independent IBM systems watching for new problems, and, progress on existing problems. One system was for the (contracted out) engineers who filled a warehouse on King Edward Avenue; and the other system was for Transport Canada's employees. I had to ensure the two systems were in sync--except I could not make entries in the King Edward system. I had to get the engineers to make the appropriate entries in their system first so that I could then update the Transport Canada system. (I was told that someone previously in my position had been fired on the spot for violating that protocol.)

In other words, my job was to nag. Engineers generally hate having to put things down in writing--and, fair enough--sometimes they are just too busy. Though I became friendly with many of them, they still did not look forward to hearing my voice on the phone because it meant that they would have to do something they hated to do. I tried to keep everything light and casual, but I had enormous pressure behind me. Transport Canada was one of those government departments that ran on rules and procedures. I rarely heard a friendly word on the floor I worked on; employees were overly-stressed from watching their backs and worrying about inadvertently crossing a line somewhere. An old friend of mine worked in the same floor in a different section. I was told firmly that I was to have nothing to do with him during working hours because his section somehow rivaled the section I was in. (There were other issues with my friend, but they aren't relevant to this story.)

However, once the Prayer meeting was over and the problem-tracking systems were up-to-date no one cared what I did (unless it was to chat with my friend). By 3:00 in the afternoon, a lot of employees had disappeared for the day. Fair enough, as they had to be at work before 7:30 am. I soon learned that I had time to join the gym in the hotel next door and work out for an hour in the early afternoon (by calling it my "lunch break"), and, after showering and changing, return to my desk to check the postings on the two tracking systems. If everything was okay, bugger off.

I hated the job. First, I do not like the kind of pressure I faced where I was responsible for what someone else was doing but I had no control over them. Secondly, I had to use IBM systems which I had never been comfortable with. Everything to do with IBM was overly-complex and obscure and intuition simply did not work. Third, I missed programming. In my previous position I had been a full-time C programmer for almost two years before being appointed Project Manager (with programmers reporting to me) for six wonderful months before the company self-destructed. I kept in touch with my team and held meetings with them in a coffee shop, listening sympathetically and giving them advice as if I were still their boss. I guess you could say that I was grieving after finally making it to a dream position.

So, when an opportunity to came along for a contracted systems analyst with programming skills in a non-IBM environment, I jumped at it. Six weeks had been more than enough Morning Prayer Meetings for me.