« How to make Acrobat 7 stop dinking with Office | Main | Don't assume caches are unimportant »

So, in a rather spirited encounter with someone less than pleased with some things I've said here, (no, it wasn't surprising at all, but in a way, it was the highlight of the week), I was reminded, both by the encounter and some of my friends who witnessed it, that there still exists a rather fundamental communications gap between sysadmins and programmers. This leads to misunderstandings that are exacerbated by the paradox that in a conflict between a programmer and a sysadmin, both can be, simultaneously completely right and absolutely wrong. If you mix in various non-technical political issues, like marketing people who understand nothing but shrinking the time between them and their next Audi, well, it gets bad quickly. After this encounter, we all agreed that a "guide for talking to sysadmins" might not be a bad idea. This post is an attempt at that.

However, to have even a chance of improving communications, I'm going to delve into a bit of Communications 101, and deal with some facts that I see not a lot of people getting. First:

It is the receiver, not the communicator that determines the meaning of the message

Everyone, and I do mean everyone has had those moments where they say something, and the person they're talking to so completely misinterprets what was said as to make the speaker doubt their sanity for a moment. It's bad enough when you are dealing with fact to face communications, but in the case of textual mediums, like email, or say, this web site, it's far, far worse. We all like to think we're clear and explicit, but in fact, even the best of us are quite frequently relying on "Oh you know what I mean" to get the meaning across. If you want to know a primary reason behind my pedanticism and tendency to beat something into the ground, well, that's a huge part of it. When you are sending out a message, regardless of verbally or textually, think about how someone else could possibly take it. Look at the tone of it. Read it out loud. Are their loaded words in it, or words that could be taken in a different way than you intend? If the answer to that question even approaches yes, then find a different word.

Think about your audience, or the receiver. What's their background? If it's identical, or even similar to yours, then you can reasonably assume they'll see what you're saying the way you do. If their background or job is not the same or similar, then you need to put yourself in their head. If you can't, find someone with a similar background and talk to them about it. It can be a real eye opener. Please note that by similar, I don't mean, "He's a programmer, she's a sysadmin, they both work on computers, therefore they're similar". That would of course be incorrect. By similar, I mean, "He prefers Java, she prefers C#, they're similar". Remember, this is the computer business. We have religious wars about free text editors. We have religious wars about versions of the same text editor. You're probably better off assuming, unless you know the other person, that they have a background utterly different than yours. So you really do have to pay a lot of attention not just to the meaning of what you're saying as you see it, but all the ways that meaning can change or be perverted, and go with that. Perfect example: At the last Macworld Expo in New York, aka "Creative Pro", there was a sign with the word "Rimmer" on it. Me, and all the people I know at Macworld, to this day, can't remember what the hell they were selling. But we erupt in an orgy of "Beavis and Butt-Head" every time it comes up. I'm sure it was a fine product, but like George Carlin said about Kumquats, "I don't even buy them anymore, I just sit there laughing and they go to waste". (Note to marketing people...hire a smartass with a dirty mind. You'd be amazed at the problems you'll avoid.)

So we've established that it's the receiver that determines what the meaning of the message really is, but with that comes a corollary; well, two actually:

1. It is the responsibility of the transmitter to ensure the proper level of clarity is present in the message


2. In the lack of clear information, people will attach their own meanings to silence or create their own information to fill the void. Neither will be what you want them to be.

The first corollary is simple. If you are talking to someone, especially in a terse medium like email or a web site post, you absolutely must accept full responsibility for ensuring that your message is clear, and explicit enough to not be misinterpreted. You can't guarantee misinterpretation won't happen, but there is a lot you can do to prevent it. For example, recently, an Apple rep told the Chicago Tribune that "...iPods were designed to last for years...". Somewhere along the way this became "...iPods are designed to last four years..." Both statements read the same, but have very different meanings and implications. The first is an open ended time frame that can change based on many factors, such as usage patterns, device treatment, etc. The other is a static period of time, that could be taken by the somewhat paranoid, to mean that there's a time bomb in the iPod. Please note that we are talking about a group of people with many Mac users in them. Paranoid is a way of life here. But even more than assuming paranoia, there's a much simpler issue here. It is not the job of the receiver to read the transmitter's mind. If you cannot be bothered to create a clear, explicit message, if you cannot take the effort to use the right words, to say the correct things, then why should anyone bother to "know what you mean"? The only thing they have to do is listen to or read your message and apply their own knowledge base, (and hopefully, some knowledge of yours) to that message and create a meaning for it. If it's not the one you intended, and your first reaction is to say, "Well, you know what I mean", then stop. No, they don't. You know what you mean, but that's it. Everyone else only knows what you say. If that's not what you meant, that's really not their problem. If you want people to know what you mean, then make sure your message is absolutely clear about it.

The second corollary is the trickier one. We would like to think that in a lack of clear information, that all assumption will be withheld until we get some word. That's not ever going to happen. The truth is, silence is not a lack of information. It's simply a lack of clear information. Make no mistake, silence speaks volumes. Again, if you decide to make your answer be one of silence, then any misapprehensions, incorrect assumptions, mistaken conclusions are your fault. For example, in my article about the problems with the Flip4Mac installer, I pointed out that I had reported the error around January, and that when I saw it again, 6-7 months later, that I took the absolute silence from Telestream to mean they had blown me off and weren't doing squat about it. As it turns out, there had been a lot of looking at it, but it was still left in the universal release. They have their reasons, which I still absolutely disagree with, although when they finally do change that behavior, I'll be a most happy scooter. But there was a bit of work done to deal with it. However, I didn't see any of that. I saw...nothing. Based on my experience, which is the only thing I can ever really go on, (just like everyone else. We're all trapped in our heads), I saw that as being blown off. Which is why my article on it was as harsh as it was. Note that I'm not apologizing for that harshness, nor shall I. Had there been any communication at all, the harshness would not have been there. I still would have disagreed, but I also would have not been blown off on what is a pretty damned serious problem from the sysadmin POV. By the way, this is evidently a Mac OS X 10.4 - only behavior. If you have Mac OS X 10.3 running, you shouldn't see it.

The point is, when all I was presented with was silence, well, truth be told, I more or less forgot about it. It was such a stunningly obvious problem, one an intern would spot, that I didn't think it would carry over. When I realized that silence was followed by the bug still being present, well, let's follow it from my version of the timeline:

1. Report the bug


2. Get standard boilerplate answer


3. Silence


4. Bug still there

Looking at that, what exactly am I supposed to think? I've no information to indicate anything other than I was blown off. Hence the article. If you want people to see what's going on, then for the love of dog, tell them. I'm busy as hell, I don't have the time to read my own mind some days, much less the minds of a company I've never met. Note that if anyone at Telestream is still wondering why the sysadmin community uniformly thinks this is bad, dudes, email me. I'd be happy to tell you. I'll even forgo my daily baby. (Note that while some folks may disagree with my wording, I've yet to find a sysadmin who didn't agree with my basic point.)

Silence is still information, only it's the worst kind. It's nebulous, and completely moldable by other related events. Even if you work at it, it's pretty hard to correctly interpret silence.

So let's review so far:

• The receiver determines the meaning


• Clarity is the responsibility of the transmitter


• If you don't provide a clear meaning, others will do that for you and it will probably be wrong

Now that we've covered the basics, let's move on to the "joys" of talking to sysadmins. To do so, you have to remember one, critical thing:

Sysadmins are pretty damned crazy

First off, we get yelled at. A lot. In fact, I think part of the interview for a sysadmin would, in a more realistic world, include some good yelling and whining. If you can't take it then, well, you shouldn't be one. So yelling at a sysadmin really doesn't affect us. We get yelled at for saying no, we get yelled at for saying yes, we get yelled at for everything. We're the cops of the computer world. Trust me, if you want to communicate with a sysadmin, don't yell. It's not that we get hurt, it's that we don't care, and we assume that if you're yelling at us, you're probably in some nimrod fuge, and we're just going to nod and smile, and ignore everything you say. Or, if we can, we'll yell back. We're quite good at yelling. #$%& you Bill/Steve! is a favorite.

You want to get our attention? Be polite. Even be nice if you can. We see either so rarely that it gets our attention right away. A calm, well-worded email will always get my attention, because I don't usually see them. Even if you think the sysadmin in question is the biggest douche since the beginning of time, set that aside, and write them calmly. You get great results from this. If you don't get good results, or you're just too mad, meh, go ahead and yell. It's not like that will hurt our feelings. Just don't expect our response to be terribly nice. Sometimes we aren't nice people.

Secondly, we don't care if you like us. Oh sure, it's nice when it happens, but face it, we spend a lot of our time saying "no", and dude, even if we had a letter from the Almighty himself as to why we had to say "no", it won't matter. People hate us. It's what they do. So if you think that reminding us that our attitude isn't going to get us any friends will make us say anything other than "Oh good, it's working then", well, you're wrong. If we wanted people to like us, we wouldn't be sysadmins.

Actually, we're so inured to vituperation and hatred, that when presented with, well, niceness and professionalism, we don't really know how to react. A sincere "thank you" and maybe some doughnuts will make us love you with as much sincerity as our blackened, blasted hearts will allow.

So again: Abusing sysadmins? Not such a great tactic, will be met by apathy, amusement, sharing with our peers, or if we're in a mood, a lesson in just how abusive we can REALLY be. (Note to non-sysadmins: We're REAL good with the profanity. Unless you're (ex-)military, you're gonna lose with that.) Being nice, polite, dare I say, kind even? Great tactic. Astoundingly good. Really.

If you think of us as the lion in Aesop's fable about the Lion with the thorn in his paw, you're not far from wrong. Be the mouse, even if you hate it.

Secondly, we don't care how brilliant your code is. We don't care how you pushed programming ahead a hundred years, or how fast it is, or any of that. UI brilliance? Bah, save it for the fanboys. You know what we care about? Will your program make our lives suck more, or less. If it's the former, then well, we hate you. If it's the latter, you rule man.

Pro Tools is not a program we have historically loved. Mostly because it's written as if to make it as hard as possible to use in a lab situation. If sysadmins had a military force, the Pro Tools people would be free radicals over radioactive glass. Don't be Pro Tools.

Okay, okay, we don't really want to kill anyone. That would just make us support a new product, which would probably suck just as much.

But think about some things when you are writing your program, (and in a very real sense, when you write a program, you're talking to us via that code):

1. For the love of god, don't make assumptions about your installer. They're probably going to be wrong. Talk to sysadmins who don't work for or with you. Find out about the vagaries of installing in a lab, in a corporate environment, in a higher ed environment. If you can't test, then ask for testers. We'll help you out. We tend to be assholes, but if we think we can help someone to not make our life suck, well, Booyah! Seriously, a badly written installer is just infuriating. One that does things that make it harder to use via Apple Remote Desktop or SSH make us want to find any other program but yours to use. When you're talking about installers, remember, less is more. Chances are, we're only ever going to double click install your work of art once. On our machine. Something that's popping dialogs, and borking the install with stupid questions, (by "Stupid", I mean "Any"), or any other behavior that hoses our ability to blast it on to 300 or 3000 machines at once will earn you our ire in great amounts. If you don't think this is a real issue, then please, install your software manually. 3000 times. While people are yelling at you about other random crap. Let me know how that works out for you. If you can't test the installer on a wide range of systems, ask for help. We would much rather spend time we don't have making our lives easier down the road than spend time we don't have dealing with crap that shouldn't be there. Oh yes, one other thing. Stop using VISE and InstallerMaker. They suck on the Mac if you're a sysadmin. If you must, i.e. gun at your head, whatever, then do one of two things: Create a way to remotely install your stuff, i.e. the "silent" install for Adobe CS 2, or create detailed log files so we can repackage your lame installer in something we can actually use, i.e. Microsoft updates. Don't just leave us with those nasty piles du feces, and expect us to be happy with them.


2. That brings us to our second thing: Log files. I cannot tell you how annoying a program that either never writes to either system.log or console.log when something goes wrong is. "Infuriating" comes close. Look, with a lot of programs, well, for most programs, we don't have a really good way to tell what's going on. Oh sure, there're tools like lsof and fs_usage but that's from the outside looking in. Logs are what your application is seeing, and a program that makes good use of logs is a real help to a sysadmin. Remember, you're talking about a person or persons dealing with all sorts of setups, from the very basic to the hideously complex, and large numbers of computers. We see interaction issues you simply won't, because you can't duplicate our environment. When we start having problems, the logs are the first place we look, and if your application is unhappy, it better be writing logs. Logs make us happy. Configurable logs make us ecstatic, because that means we can adjust the log level according to need. This is A Good Thing. It tells us that you understand that we're going to see strange things that you won't, or even can't, and that you want to make sure we have good information from your application when things go sideways. Note that logs are critical for installation issues. Bad, or no logs show us hate. Good logs show us love. Don't you want to show us love?


3. Thirdly, just because you think of it as a "server" doesn't make it one. To a sysadmin, a "server", at least in the software sense, is a pretty specific thing that meets a pretty clear set of criteria. The biggest one is no UI ever needed to run. Want to piss off a sysadmin, create a server and make us install a bunch of UI crud with it. Poweron Software, I'm so talking to you and your "must install menu bar widgets with Now Server" silliness. Just stop it, okay? Another way to annoy us? Make us be unable to administrator your server other than on the machine the server runs on. (Again, Now is a prime offender here.) Yes, we have VNC and Apple Remote Desktop, but using those through low-bandwidth VPN connections...um...sucks. We don't mind remote UIs, although for most server products, if you can use HTML/AJAX/etc, that's a better choice. We have enough applications as it is, and most server administrator applications don't really need a full on fat client. Give us a simple, lightweight, (in terms of connection and UI) way to administrate your server, and we'll love you. Even better, give us a way to plug your UI into other things like Nagios, and we'll love you even more. Can you feel the love? I know I can.


4. If you're going to include an automatic software update check, please, please, PLEASE make it not grind the application to a halt when you're off the Internet, ESPECIALLY if it's an application with offline uses. (My favorite blog editor, Ecto, is rather annoying this way.) Yes, auto-updates can be handy. However, when they don't let us use the application until they time out, then they kind of suck. If it's just unavoidable, give us better notification than a beachball. Again, communication is key. Along with making autoupdate not suck, make sure it's easy to turn off, and make it stay turned off, i.e. via a plist. If we can select the port it uses, that makes us even happier. Happy sysadmins don't complain.


5. Make your application scriptable, both via a proper AppleScript dictionary, and by using well-named standard UI widgets in your application. I don't care if you can't imagine why automation is important, there's someone, or a lot of someones out there who can. Adobe didn't think there was a need to script Photoshop until Cal Simone showed them just how wrong they were with Photoscripter. Now everything in CS Suite is scriptable. If you are a developer for Apple and your application isn't scriptable, I can guarantee you'll get lambasted. That's just inexcusable. Seriously, sysadmins deal with production environments as well as creative ones, and automation is critical to efficient production. It also means that more people will use your product. They may not use it the way you intended, but they'll use it. People using your product is good. Trust me here. (If nothing else, a good AppleScript dictionary is a heck of a way for you to test your own application yourself. Just ask the Microsoft Mac BU.)

There, five things you can do in your code to give us the correct message.

However, sometimes things go sideways, or for reasons out of your control, you have to do things that are going to be viewed as "dumb" by the sysadmin community. This will then require you to actually talk to the sysadmin(s). Oh damn. First, we do feel your pain, and we are sysadmins. We get that we're not always easy to talk to. But there are some tips that can help you when talking, and more importantly listening to a sysadmin. (Credit where credit is due. The following is based on a really solid email from Dave "Puker" Pooser.)

1. First and foremost—if I’m complaining about your product, that means I care about it. Really. It’s been years since I last complained about Quark Xpress, or Windows Media Player, or Internet Explorer, because anymore, I just don't care about them. If I’m complaining about a feature it’s because I want to use your product, but there's something that's making the experience less than thrilling. I may not mention the fact that I want to use your product – it may seem completely obvious to me, or I may be in a hurry, or my social skills may have taken off for a long weekend - but it’s still the case. If I tell you your installer sucks, it’s because I want to install your product. I am a customer or a prospective customer helping you make the sale to me. More importantly, I'm the person that's going to test your product before it is used by potentially thousands of customers. My delight, or lack thereof with your installer is a rather important data point in your sales figures. You should be nigh-ecstatic that I cared enough to kvetch.


2. Second, I may be brusque and/or rude. In fact, I almost guarantee the brusque. All sysadmins are busy. Many are jerks. Some will be as brief as possible in a misguided effort to save you time, or most likely save themselves time. Whatever the situation, your response should be the same: I am trying to get you information to improve your product. Don’t get defensive or take offense. Think of it as an academic exercise; pretend you’re trying to parse a poorly-formatted block of text. Take Your crappy installer is a security hole gaping wider than the Grand Canyon and read the meat of it: I wish to report an escalation-of-privileges bug with your installer. It’s what I meant, and the rest is just frustration, lack of social skills and personality defects. For goodness’ sake, don’t try to flame back; I deal with hundreds of bitter and crusty old sysadmins on mailing lists. I can flame you to a tiny charcoal briquette, and I may lose interest in helping you improve your app. The first shouldn’t matter to you but the second is a problem. You don’t have to like me; I don’t have to like you - we can still collaborate on making your program better for my environment. As well, there's no better PR among sysadmins than "Dude, if you're having a problem with that application, email the devs. I did and they were really helpful in tweaking some things that were causing me problems and helping me find workarounds for the things they couldn't change." That's PR gold on a sysadmin list.


3. Third, understand that my burning issues are often going to have no relation to the complaints of end users. If you have a FUBAR installation process, most users suffer through it once and then savor the coolness of Virtual Zamfir 3.02 for months. I may have to deal with getting it installed on 378 faculty machines and 800 lab computers. If you make it a gigantic pain in the rear, it won’t get installed, (or that install will be slow leaked to hell and gone) and you won’t get the fat purchase order that after 180 days and two threatened lawsuits finally gets turned into a check from the university’s Accounts Payable weenie. (Note: even if all we're talking about is the free version, it still counts. If the installation process sucks when it's free, do you think that I'm going to be excited to pay for that pain? Sysadmins may be maso, but we aren't that into paying for a beating.) Word to the wise: Drag-and-drop installers are best and .pkg are next-best; VISE is a pain for those of us who don’t own NetOctopus. Proprietary crap is just begging for deletion. On a similar note, write to ~/Library where possible instead of /Library, support your app in ~/Applications and /Network/Applications. (If you even THINK about making any changes to /System/Library please step around the corner and beat yourself to death with a warm haddock.) In the same vein make sure your product can be run by a standard (non-admin) user, and make sure it doesn’t break when multiple users share a computer. If you really want to make us happy, let your application be installed in ~/Applications when needed, and if it doesn't have to have an administrator password, don't ask for one, especially for home directory installs.


4. Fourth, you want my abuse (see the first point); make it easy for me to get you feedback. Forums are not easy. I have to register; I have to remember a password; I have to remember to check up on that. I am already annoyed with some aspect of your product; don’t make me annoyed with you. Put an email link in the documentation, in the product’s help menu, and on your Web page. I should get an autoreply telling me my bug has been assigned a temporary tracking number, and then an email as you update the status. I should NOT get any other email from you to that address unless I provided it to your marketing weenies separately; if you spam me while I’m trying to help you I will quickly lose interest in helping you and your product in general. I'll also warn people that sending you email is a bad idea. I should hear back from you as soon as you reproduce the bug or as soon as you realize you can’t. Ignoring me will NOT make me go away; if you think I’m mistaken let me know. (Remember that whole "Silence speaks volumes thing? Yeah. See, it's true.) If I think I’ve found a security bug an you’re ignoring it, soon the world will hear that you don't care about security, and thanks to the magic of mailing lists and Google, it will propagate far faster than you think. Nobody wants that, especially you.


5. Fifth; if it’s a bug, FIX IT. There are several wrong answers you can give:
   • That’s Apple’s bug.
   Maybe it is, and maybe it isn’t. Even if it IS their bug, it’s a whole lot easier for me to dump you than them (unless you are Microsoft or Adobe, anyway); It behooves you to find a workaround.
   • That doesn’t happen if you upgrade to Mac OS X 10.4.q.
   Slightly better, but if I haven’t upgraded yet there’s probably a reason: I haven’t finished testing the update, there’s a conflict with another app/process I need, or evil voices in my head are telling me that the letter Q causes cancer. Whatever the situation, if it’s at all possible, fix your app to work with earlier versions of 10.4. (This is only a hard-and-fast rule with the current OS version; I’m much more understanding if you only want to support the last point release of Panther and/or Jaguar). Even more appalling is:
   • That doesn’t happen if you don’t install Security Update 2006-087
   – again, I can fire you more easily than Apple.
   
   • We don’t support network homes/remote installs/case-sensitive boot volumes/SMB home directories/220-volt power supplies/people who mispronounce the word ‘cache.’
   So you think I’m gonna redesign my environment for your software? Installer, meet ~/.Trash – I’m sure you’ll have plenty to discuss. I understand you may not have tested your program with my weird environment; that’s understandable. But try to resolve the issue instead of just blaming my environment and walking away. Adobe is big
   enough to get away with that; you’re not. I’ll help you troubleshoot it within reason—while I’m busy, I also want your app to work—but you need to be willing to work with me.


6. Sixth (extra bonus tip): proactively communicate. Look at http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/ for a great example of this. Instead of waiting and responding to each complaining Mac user; he’s addressing all of us with a wealth of technical detail. That is GREAT move. Sure, I’m still unhappy about the impending end of VB macros, and I may have bought my last copy of Office for a while—but I’m now angry at fate instead of at the Microsoft Mac BU, and that greatly improves their chances of selling me the next cool thing. It may be that technical issues prevent your app working for me in my environment; you still have the chance to leave me impressed with you instead of depressed by you. Even if the answer isn't one we like, it's still a clear, direct answer. We like that aspect, even if we hate the content. We're quite capable of living with that paradox. Again, this is how to turn failure into success. Sure, you told us "no". But you told us "no" in a straightforward, adult manner. You respected us, our knowledge and our concerns. We remember that. In fact, it leads to us defending you. When someone starts calling you high-handed or pompous, you get some voices going, "No way dude. Did you read his blog post? There's a host of technical reasons why they can't do that right now. RTFB man." Sysadmins have looooong memories. You really, REALLY want every entry in that database to be as happy as possible.

Holy crap, but that's long. Look, I'm not saying it's easy to talk to us, or even pleasant. But it is necessary, and since we are quite often, in a position to make your application's life suck, it behooves you to communicate with us effectively. it saves you a lot of headaches in the long run.

Technorati Tags: Communications, Relationships

Comments

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comments: