BOFH

Bryan Lott published on
4 min, 686 words

(bastard operator from hell) What a term. It used to only apply to curmudgeonly sysadmins and the neckbeard elite but I've noticed lately that it can be applied to a large number of other IT professionals. Specifically, I'm talking about developers.

I know you have to sit in your cube staring at page after page of incomprehensible piles of crap code written by someone else that clearly didn't know what they were doing. I know that you have to spend hours with a debugger to find a misspelling in a string variable's value. I know that it can take a day and a half to find the missing semicolon that's been causing compiler errors. I know that it makes you want to defenestrate your laptop, cubicle, mouse, keyboard, and anything else within arm's reach.

How do I know this? I do it all day too and it drives me up the wall probably just as much if not more than it does you.

Here's the thing my fellow developers. Users, sysadmins, managers, and other devs are NOT out to get you. They are not out to make your life a living hell, nor are they trying to get your job. In fact, most of them probably wouldn't want your job if you offered it to them on a silver platter. Remember, you make things happen. That's a huge power and a huge responsibility and most people don't want either. But, I digress. Users, sysadmins, managers, and other devs are people, just like you. They have just as hard of a time understanding the meatbag sitting in a cubicle staring at "gibberish" (and occasionally writing some) as you do understanding the meatbag that seems to have a job consisting of nothing but meeting people. A smile, friendly hello, or 30 seconds taken to listen to a problem can go a long way toward building common understanding and a good working relationship.

So, here's my personal guide to working well with others:

  • Be nice to people, you'd be amazed at how you can get along if you follow a potentially negatively misinterpretable comment with a smiley face :) (but the thing is, you actually have to mean the smiley face)
  • You are not your code. Sure, you wrote it, does it define you as a person? I sure hope not because I know I've written some really crappy code and I don't want it defining me! If someone wants to throw it out in favor of something better, let me grab the trashcan and hold it for 'em.
  • Condescension kills. Do not, under any circumstances, no matter what the situation (even if they're a drooling idiot) act in a condescending manner to anyone. Basically you wouldn't want someone else treating you like you're an idiot for not knowing that rm -rf / will blow up your linux box. Remember, at some point, you. did. not. know. what. you. know. now!
  • If you're not in person, over communicate. Most communication mediums have a way of ignoring someone if they're too communicative. But, as a dev, chances are you're on the under-communication end of the spectrum.
  • If you're absolutely right, there's a good chance you missed something. Basically, you're never right all the time, and if you are, your career is over because you've stopped learning. Never stop learning and never stop being wrong. (this also helps when debugging... "print" rarely breaks, but the code you just introduced breaks more often than you think ;) )
  • Listen to people. And when I say listen I don't mean "wait for your turn to speak." I mean really listen, understand what they're saying and try to figure out their motivation for saying it.
  • Ask questions more than make statements. It's much easier to hear "Was there a reason you left a debug print statement in?" than "Don't leave debug print statements in!" It's giving them the benefit of the doubt, but make sure you don't sound condescending when you ask.

In closing, don't be a BOFH. Nobody likes them and while being the outcast was cool in high school, it doesn't work as a career.