By way of the esteemed Charles Hill we have some commentary on developments in engineering that have displeased many:
Once upon a time, software was written by people who knew what they were doing, like Mel and his descendants. They were generally solitary, socially awkward fellows with strong awareness of TSR gaming. They were hugely effective at doing things like getting an Atari 2600 to run Pac-Man or writing operating system kernels that never crashed, but they weren’t terribly manageable and they could be real pricks when you got in their way. I once worked with a fellow who had been at the company in question for twenty-three years and had personally written a nontrivial percentage of the nine million lines of code that, when compiled, became our primary product. He was un-fire-able and everybody knew it. There were things that only he knew.
This kind of situation might work out well for designing bridges or building guitars (not that Paul Reed Smith appears to miss Joe Knaggs all that much, to use an inside-baseball example) but it’s hell on your average dipshit thirty-five-year-old middle manager, who has effectively zero leverage on the wizard in the basement. Therefore, a movement started in the software business about fifteen years ago to ensure that no more wizards were ever created. It works like this: Instead of hiring five guys who really know their job at seventy bucks an hour each, you hire a team of fifty drooling morons at seven bucks an hour each. You make them program in pairs, with one typing and the other once watching him type (yes! This is a real thing! It’s called “extreme programming”!) or you use a piece of software to give them each a tiny bit of the big project.
This is what you get from a management perspective: fifty reports who are all pathetically grateful for the work instead of five arrogant wizards, the ability to fire anybody you like at any time without consequence, the ability to demand outrageous work hours and/or conditions, (I was just told that a major American corporation is introducing “bench seating” for its programmers, to save space) and a product that nominally fulfills the spec. This is what you get from a user perspective: the kind of crapware that requires updates twice a week to fix bugs introduced with the previous updates. Remember the days when you could buy software that simply worked, on a floppy disk or cartridge, with no updates required? Those were the wizards at work. Today, you get diverse teams of interchangeable, agile, open-office, skill-compatible resources that produce steaming piles of garbage.
And indeed, it is so. But the travails of the hapless, helpless users are well known; what deserves a closer look is the pair of dynamics that has produced today's state of affairs, which is not...quite...as "wizard-free" as Jack Baruth, the author of the above, might think.
It's a subject on which I can speak with a certain authority.
One powerful reason I've resisted being elevated above my current position as a hands-on or "front line" supervisor is that management above my level is so easy as to be boring. Those who occupy those levels, of course, would disagree, but that's in the nature of the personalities one finds in management. In a healthy company, a manager of any level has only four responsibilities:
- He must apportion his section's work load rationally among his subordinates;
- He must find out what they need to get their work done and get it for them;
- He must hold them to their promises;
- He must protect them from interference from above.
This extremely simple breakdown of the responsibilities of a manager applies to any non-hands-on manager or supervisor at any company. Yet the typical manager reacts to that breakdown much as a vampire would react to a crucifix: "No, no! My job is much more complex and difficult than that. Why do you suppose I have a private office, wood furniture, and this schedule of meetings with other very important people?"
It's natural. We all want to believe we're important: if possible, more important than anyone else in the company. But it's not so. Managers are far easier to replace than line engineers. The generality of managerial skills makes managers of a particular level almost interchangeable, if individual energy and "connections" are omitted from consideration.
Line engineers are a completely different subject. We're not interchangeable; some of us are far more intelligent and insightful than others. Also, the longer an engineer labors at his trade, the more expertise he acquires. His exposure grants him a working knowledge of what can be done, what can't be done, and what shouldn't be done. That's not something one can acquire from a textbook; it takes actual conversance with the development, debugging, and maintenance of the sorts of systems in his demesne.
But the typical manager is determined to "manage," by which he really means to control what's going on beneath him. It's the core of his self-image: the guy whose laying-on-of-hands is the final, irreplaceable blessing that renders the product "good."
That puts manager Smith directly at odds with senior engineer Jones. Jones resents being told how to do his job, or with what tools and under what conditions. Jones can usually resist Smith's interference effectively, because Smith seldom has the slightest idea what Jones is really doing, or why. If Jones should remain in his trade for sufficiently long, then despite whatever Smith might do, Jones will become an element critical to any engineering shop: the "Old Man In The Back."
In A Shortage Of Engineers, Robert Grossbach's wonderfully funny and poignant novel about the travails of Zack Zaremba, a young engineer at a typical middle-of-the-road company, Zack soon encounters the notation OMITB, which is stippled liberally over several important circuit designs. It takes a while for him to decode that acronym, which stands for "Old Man In The Back:" an extremely senior engineer who has become the go-to guy for severely challenging technical problems his colleagues cannot solve. He's so important that he's protected from excess attention by his colleagues. Management never dares to intrude upon him. Without him, the company might not be able to function at all.
A gifted engineer who remains in love with his trade long enough, and who resists the seductions of management, can become an Old Man In The Back: a senior figure who knows how, why, and why not when less gifted or less well traveled technologists are at a loss. Moreover, his persistence at his work will engage management in a dynamic it cannot resist, for it is prior and superior to all else: the need to get the work done. He will become indispensable by management's own decision to keep him at it.
This happens in every company that employs technological expertise. It gives rise to a culture of whispered legends about persons who, visible or not, are regarded as "above the rest," to be approached only at great need. It produces half-concealed avenues to product fruition, seldom openly discussed, with which management dare not interfere. And it produces resentment by management that this wizard, this unmanageable maverick, should find it so easy to flout corporate policy without penalty.
But he who is "above the rest," who has been deemed a "wizard," is inherently hostile to control by management. It would pollute the thing he's put at the core of his soul, which he loves above all else: his work. And management, if it possesses a shred of good sense, will bend to the realities and leave him alone.
Even so, the two opposed dynamics -- the manager's drive to control "his" section versus the objective need to get the work done -- will remain in operation. The people involved, both the managers and the engineers, are simply like that. And whoever has the upper hand at any given time will determine whether the company releases functional and reliable products, or, in Jack Baruth's words, " steaming piles of garbage."
