My first "real" computer? Are we counting only computers we've owned personally, or should we include computers we've used that belonged to others (e.g., employers)? The first computer I ever owned was a laboratory-surplus ADDS MultiVision prototype: an Intel 8085-based machine that ran a CP/M-80-compatible O/S that I designed. It had 64 KiloBytes of RAM, two 5.25-inch floppy disk drives, interfaced to an external RS-232 terminal, and was patched together with clip wires and faith. I managed to snarf a 30 MegaByte Seagate Winchester disk drive prototype for it, but as the thing required more electrical power than my home could supply it -- it weighed 60 pounds and had 14 inch platters -- I never got it to work properly. The first computer I ever worked on was an IBM 1800 "minicomputer" that took up a room the size of a small cafeteria. It had 6.2 KiloWords of 16-bit-wide core memory, 256 KiloBytes of disk storage, and a single 9-track tape drive. It was originally intended for the control of laboratory equipment, but was never used for that purpose...possibly because it would crash at a harsh look and took approximately 20 minutes to bootstrap. Feeling a little younger now?

(This message is programming you in ways you cannot detect. Be afraid.)

“Ya remember...when we were kids...how good the jellied bugs used to taste? And there were those long rolls of paper with food stains on them. (You could get two thousand yards for a nickel!) And then there were those little round hard things that would explode in your mouth and blow your lips off... Oh! And the cold pork fat bars with the carpet tacks! Boy, they don’t make stuff like that any more... These days it’s all goddamn chemicals!”

(In remembrance of Bernard Kliban)

(This message is programming you in ways you cannot detect. Be afraid.)

For you, sir, a short story written many years ago:

MS FND IN A LBRY

Enjoy!

(This message is programming you in ways you cannot detect. Be afraid.)

You have my deepest sympathies.

Some years back, my department was afflicted with a manager who thought he could and should "fix the inefficiencies" in other people's code. The responsibility for dealing with problems he created invariably wound up on those hapless "other people's" desks...mine included. The ill will he generated that way was thick enough to be carved into entrée portions and served with hollandaise sauce.

Needless to say, the manager was never taken to task by his superiors for his arrogant interference in things he knew next to nothing about. However, the problem went away when he met an untimely demise: run over by an SUV, right in our very own parking lot. And they say there's no justice in this world!

(This message is programming you in ways you cannot detect. Be afraid.)

Alternately, we have the following two rules, first propounded by anarchist theorist Mikhail Bakunin:

1. There are no rules.
2. Rule #1 is not binding.

I observe those rules scrupulously.

(This message is programming you in ways you cannot detect. Be afraid.)

Ask rather how one will react to the news that he has been made a plural.

This fear of he, him, and his as the standard generic singular pronouns has gone far enough. Men, find your balls. Women, get over yourselves.

(This message is programming you in ways you cannot detect. Be afraid.)

Don't feel bad. I have a private library of nearly 13,000 volumes -- yes, I've read them all; I'm a novelist as well as a software engineer, and reading widely is a novelist's occupational requirement -- and of the 100 books on the Telegraph's list I've read only 23. But the list contains quite a number of novels I consider garbage, having read snatches of them and tossed them aside with a snort.

What comes to mind in this connection is Ambrose Bierce's definition of a classic: "A book everyone wants to have read, but no one wants to read." That applies to quite a number of the most frequently cited "classics," and sometimes for very good reasons!

(This message is programming you in ways you cannot detect. Be afraid.)

All very irritating and unnecessary stuff, particularly as she works downstairs from me, but between the website and the image are two more lines; Team Name - Winner Best Technical Team 2010 Team Name - Winner Best Overall Team 2010

(chuckle) As irritating as that is, you might want to spend a little time in my alternate universe -- independently published fiction -- for comparative purposes. You know, to establish a baseline.

Indie writers are forever touting "awards" they've won, or claiming "best-selling" status, with absolutely no substantiation. Ask one about it and he'll either slather you with vituperation, change the subject, or clam up completely.

I suppose the desire to be praised is so strong in some people that, in the absence of preferable alternative sources, they'll simply heap praise upon themselves. It comes as no surprise that it happens among engineers, too.

(This message is programming you in ways you cannot detect. Be afraid.)

Oh, I was tempted. But I wasn't at all sure whether I could replace him, and I was short-staffed already.

(This message is programming you in ways you cannot detect. Be afraid.)

Allow me to submit something a bit off-axis: a habit of thought.

In more than one place where I've worked, I've encountered persons so confident in their skills that they didn't bother to test "trivial changes." Such "trivial changes" caused major crashes in important products, more often than I (or they) would care to remember. Inasmuch as for many years it's been a large part of my responsibilities to train young software engineers, it's been the very first thing I've pounded on: there is no such thing as a change too small to test.

Some took the advice to heart, but not all -- and when the bills came due, the incredulity of the sinner at issue was often thick enough to slice: "But all I did was...!"

We're fallible, each and every one of us, from the dunces to the geniuses, and from the brand-new graduates to the fifty-year veterans. But an engineer's ego can be resistant to that homily...until he's experienced the consequences on his own hide.

My "favorite" case of excessive confidence involves a young turk -- let's call him Andy, as that was his name -- who was assigned a component in a large monolithic application intended to run on a VAX under VMS. Andy was excessively fond of assembly language, and was eager to write his piece in VAX assembler. I counseled him against it -- the rest of the application was written in C -- but couldn't dissuade him. To shorten the story a bit, some weeks later Andy presented me with his component, which I added to the build without comment. The resulting application ran for approximately twenty seconds before it crashed -- and it didn't just bring down the app; it crashed VMS with a "bug check" error.

The problem was, of course, in Andy's module. I pointed it out to him at once. The subsequent exchange ran roughly as follows:

FWP: Did you test it?
Andy: Well...
FWP: This instruction [I pointed it out] is out of sequence. You have to allocate and enable mapping registers before it will be valid.
Andy: Well...
FWP: I expected you to test this before you brought it to the link.
Andy: But it assembled without errors, so I figured it was right!

Words fail me, friends.

(This message is programming you in ways you cannot detect. Be afraid.)

Indeed! One of my favorite variations on that theme is the "studies show" shibboleth.

In a discussion of public policy, whenever someone tries to bolster his argument with the "studies show" gambit, I immediately ask, "What studies, conducted how and by whom? Can you provide references?" Inasmuch as these days, for every study there's an equal but opposite study, the countermeasure is quite effective.

"They want" and "they say," and all their variations, are ways of asserting a nebulous, un-checkable authority. Like many other such phrases, they should be buried face down with stakes through their hearts -- and the way to make that happen is never to let them pass unchallenged.

(This message is programming you in ways you cannot detect. Be afraid.)

Sir Edward Grey, the Foreign Secretary of England during World War I, wrote in his memoirs that "Happiness consists of having all that one wants and none of what one does not want." This applies to one's work environment as well as anywhere else. Accordingly, the key to happiness at work has three components:

1. Work at something you enjoy for its own sake;
2. Establish adequately comfortable conditions in which to do it;
3. Contrive to screen out irrelevancies, distractions, and intrusions.

In a corporate-employment setting, items 2 and 3 can be a challenge. Item 2 can sometimes be partially covered out of one's own pocket, but there are limits; few of us are willing (or able) to purchase our own cubicle furniture or computers. Item 3 is the toughest of the nuts by far.

Most dissatisfaction among software people arises from managerial and supervisory sources. It's not just schedule and deadline pressure, either. Managers and supervisors sometimes seem incapable of letting an engineer do his work without sticking all their appendages into it. They're "above" the lowly practitioner, they "think," and therefore have a right and a duty to perform frequent layings-on of their sacred hands to "ensure quality." That can drive just about anyone to despair, drink, or on occasion, violence.

I've come to regard the front-line supervisor -- i.e., he who directly supervises working engineers, and might well still be technically hands-on himself -- as the optimal spot for the solution to this problem. If he can be persuaded to fulfill three functions:

• Give his people clear and specific tasks to perform;
• Stay away from them as much as possible while they're working;
• Rigidly exclude all "higher-level" management from their work environment, except for "ceremonial" occasions scheduled well in advance;

...his engineers' working conditions can be brought as near to optimal as capital budgets permit.

Finding such a supervisor is not easy. He must be smart, humane, results-oriented, and very tough. For his engineers to retrain one who possesses the "raw material" but is not yet enlightened can be just as hard. But the alternatives are all unsatisfactory.

I try to be such a supervisor. It often demands more humility than I naturally possess. That highly unappreciated and increasingly rare virtue might well be the critical factor -- and can anyone sincerely say he's sufficiently humble?

Don't all answer -- or laugh -- at o

Bah! Go for the gusto. Here's my favorite -- from either side of the interview:

"Assume there are Plutonians. Assume there are elves. If the elves attacked Pluto without warning, tomorrow at 9 AM local time, which side would you be on?"

Note that there are three answers to that question, not two -- and perceiving the third is almost as important as choosing it.

Of course, if you think the above question would make you "look silly," the old fallback "Are your stools black and tarry?" is always available.

(This message is programming you in ways you cannot detect. Be afraid.)

You young folks don't know how lucky you are. Why, when I was your age, a byte only had two bits -- and they were both 1s! Do you have any idea how hard it is to do floating-point arithmetic in Roman numerals? Ah, but the men were men in those days...

(This message is programming you in ways you cannot detect. Be afraid.)

Long, long ago (1973), at a company that's blessedly vanished from this mortal plane.

Managements typically don't want to admit to certain facts:

• That engineers are not interchangeable modules;
• That engineers require conditions conducive to concentration;
• That engineers' work cannot be (and therefore must not be) scheduled;
• That engineers are habitually appreciation-deprived, and over time will come to resent it;
• That a dress code for engineers who never face a customer is patent idiocy that impedes productivity;
• That an engineer whose head is lolling back and whose feet are up on his desk is probably hard at work and should not be disturbed.

In short, managements tend to assume that what we do is indistinguishable from the day laborers Frederick Taylor observed for his time-and-motion studies. Those that learn better sometimes survive their earlier follies; the rest have sown the wind and reap the whirlwind.

Indeed, it sometimes gets infinitely worse. A true story: I happen to be a practicing Catholic. One fine day about thirty years ago, during my company-designated lunch hour, I was silently praying the Rosary, beads in my hand, when a manager came to my cubicle and loudly demanded that I "quit that nonsense" and attend to something he had thought up a few minutes earlier.

I'm still not certain why I let him live.

Why so many engineers yearn to enter management is something I'll never understand.

(This message is programming you in ways you cannot detect. Be afraid.)

The situation is complex, mainly because so many broadband providers have special privileges under the law. The most obvious such privilege is "monopoly provider" status, which still holds in a large number of localities. However, there are others -- and some of them even affect "dish-based" services that require no hard-link connection to the service provider.

Were all such privileges to be withdrawn, the market in Internet service would be truly free, and I'd be utterly against net neutrality. It would be a "camel's nose under the tent" which would endanger the freedom of this way to communicate. As matters stand, it's harder to argue against net neutrality, though there are still strong arguments against it as an innovation-suppressant.

As a rule, when a government decrees that it will provide, compel, regulate, restrict, or prohibit something "for the common good," I'm automatically against it. At least, that's been my immediate reaction, most of my life. I've been trying to think these things through at greater length in these latter years, because...well, just because.

(This message is programming you in ways you cannot detect. Be afraid.)

That's an unusual and unpleasant parting. In the cases I've seen, a company will tell an employee who's given his two-week notice to "get out today" only if:

• There's bad blood between management and the employee, or:
• Management fears some sort of wrongdoing, whether the departing employee is motivated by profit or by vindictiveness.

Defense contractors will sometimes decree "get out today" for security reasons, but in such cases they usually pay the employee the two weeks' salary he would have earned.

If none of the above applies, then it's likely to be pique on the part of some higher-up -- basically "hurt feelings" over the employee's decision to move on. Managers are human and can be as petty as anyone else.

(This message is programming you in ways you cannot detect. Be afraid.)

My technique isn't too far from that:

• Take a wild-ass guess at the time it would take if I were certain the requirements were firm and that there would be no interruptions while I'm working on it;
• Double the number;
• Promote the unit to the next higher value.

So if I figure I could knock it out in an hour under "ideal" conditions, I estimate "2 days." If my wild-ass guess is two weeks, I submit an estimate of "4 months." And so forth.

The remarkable thing about this approach, which I first suggested as a gag of sorts, is that it's proved to be pretty reliable in practice -- seldom more than about 10% from the actual time required, and never more than 25% off. Somehow it accounts flexibly for requirements changes, imposition of unanticipated constraints, distractions and interruptions, and acts of God. There's a lesson in there, somewhere...

(This message is programming you in ways you cannot detect. Be afraid.)

No, not all programming jobs are like that. Some are worse:

• Revising an undocumented 250,000 line FORTRAN 66 program (it analyzed neutron scattering patterns) that arrived on your desk without documentation;
• Finding the deadlock that causes an MVME-147 SBC and an obsolete vector processor to spin in place, each waiting for the other to release its hold on shared memory;
• Finding the error in a large microcode program for a proprietary device (whose author isn't just unavailable; he's dead) that causes the VAX it's installed in to machine-check and halt hard.

(Yes, I've had to do all those things.)

There's always something worse, and Murphy's Law as applied to the programming trade -- it's a trade, not a profession, but that's a tirade for another time and place -- guarantees that if you moan that "nothing could be worse than this," you'll learn better on your own hide.

Software can be fun, but it can also be pretty dreary. Maintenance and obsolescence being inexorable facts of the deal, the dreary parts can outweigh the fun ones for long stretches of time. That's one of the reasons why most software people do their best to escape the "hands-on" part of their occupation by age forty. Those who succeed find, to their sorrow, that there are even worse things than the worst of software jobs: for example, wearing a suit and tie and spending forty hours a week attending meetings and reading and writing reports.

(This message is programming you in ways you cannot detect. Be afraid.)

(chuckle) Feel free. It was spontaneous, but the more I ponder it, the more accurate it seems!

(This message is programming you in ways you cannot detect. Be afraid.)