The 10 most INHUMAN bosses you'll encounter: A Reg reader's guide

A BOFH's guide to debugging the Anti-Managers from hell

Your boss could well be a barely restrained psychopath. Indeed, it is probable that he is the living incarnation of Cthulhu himself. Or he may be a bumbling incompetent who'll sink your career along with his. You, the downtrodden techie, need to learn how to deal with him - and fast.

First, stop thinking of him as a person because it is making you too soft and disabling the parts of your brain that can effectively change his behaviour.

You are an IT pro: it is time to start acting like one. Forget emotional intelligence or touchy-feely “IT pros are from Mars, Bosses are from Uranus” rubbish. He is a defective component in your system – and you know how to deal with them.

What matters here is the output. When we talk of a corrupt index we aren’t passing a moral judgement any more than we believe that when you delete a file that the File Manager judges whether it has complied with ISO standards and either sends it to the Recycle Bin or to ascend to SkyDrive where it will be eternally stored on Steve Jobs' personal USB stick.

The defect removal mindset frees you from getting angry. Yes I know you’re angry, but that is a motivation, not a methodology. For this to work we must agree that what should happen is irrelevant when we know what will happen. If a file API should take both Windows \’s and Unix /’s but only takes the Unix kind, we put the /’s in since griping about it in the pub won’t get the job done. Same with your boss.

You already know that most of the effort in fixing a system is finding out what is wrong. My bitter experience is that randomly changing code or configs rarely makes things better, but by focusing your efforts on correcting a small part of his behaviour, you have a better chance than saying “Oracle performance is shit” - which is not useful, no matter how good it makes you feel. You need to sort out the indexes and buy yet more memory, but only after you’ve identified what sort of problem you face.

So let’s look at some AntiManager types.

1: The Visible Man

This is such a common bug that it is almost a feature caused by the fact that managers must multitask far beyond their capacity to do it properly. They stop thinking and start reacting to stimuli in the form of things they see and come to believe that things they can’t see don’t exist. This is, of course, a regression to babyhood where psychologists recognise a distinct part of your development when you realise that the person playing peek-a-boo isn’t being created by your observation of them. (and then at university discover that physics says it is)

This is one of the simplest to fix. You pander to their bug, in the same way that a buggy function that you haven’t the source code for can be fixed by a wrapper that takes input and makes it wrong in the right way. You make things more visible, stop planning your work by dependencies, delivery or tests, but instead by maximising observables and minimising the gaps between observable progress. The beauty of this fix is that not only will it make your boss like you better, you can tell him what you’re doing and he many well make the rest of the team follow your good example, helping you on your way to becoming an AntiManager of your own creation.

2: The VB 6 Expert

I liked VB6, despite being a C++ programmer at heart. It did what I told it and it made me look more productive. VB6 was such a classic that some thought it the perfection of its kind and there is a good chance that a former VB6 programmer of my generation is now your boss, though he will resent the “former” tag, so don’t use it.

As a C++ hacker who’s done multithreading you may notice that the personality bugs I describe come from that domain, because to become a real programmer you have to immerse so deeply that you think in terms of the system itself, not merely translate your thoughts into it.

The bugs come when he tries to apply VB6 or C++ style thinking to SQL or CUDA. Having got good at one thing, he doesn’t want the effort of changing and instead tries to make SQL code too procedural, or chafes at the patronising inadequacy of Java memory management, and ends up making you reinvent a square wheel memory manager to block Java’s round hole.

This sounds at first like old people not keeping up with new tech, but having recently come up to speed on mobile development, I feel like I’ve been fallen back in time to the 1980s where APIs were secret or barely documented and where swathes of functionality I’ve come to expect are missing. (or secret, who knows?)

Wrappers aren’t a good fix for this. The sheer size of the mapping defeats any gain you make; instead you join in him in hating the way this environment gets in the way. Perfection in this is researching limitations of the system or language and finding new things to bitch about. This will help you both get a better appreciation of what you’re dealing with.

3: The Busy Waiter

Evolution tells us that the urge to repeatedly ask “are we nearly there yet ?” must have some strong survival utility in later life to balance the number of kids who don’t make it through childhood for asking too many times. This applies equally in the case of project managers, though I’ve not worked out what that utility might be.

All of us, when first writing systems that talk to each other, try to code them as tight loops that bug the hell out of the target system. Sometimes we do this to the point where it never gets the chance to actually do the thing we’re waiting for. Just like you and your boss, isn’t it?

One answer is our old friend binary exponential backoff, making sure of the above scenario each time your stated delivery time goes up and not down, since despite all evidence many managers believe putting pressure on you to deliver always makes you get the job done more quickly. Yes, they do, just like the five year old stuck near me on a yet another broken BA plane. Don’t do this as confrontation. Instead talk to this prat and “discover” a new problem that takes longer each time he asks. Or you can actively tell him how things are going, using the message passing design pattern to mediate his non-maskable interruptions.

Biting the hand that feeds IT © 1998–2017