Writing code is rarely an act of support.
Most of the time when someone needs support (i.e. help with a problem) what they need is to understand what they’re doing, where they’re coming from, and what they want. Once they have that, they can apply their knowledge and define their goals and achieve them. I know, I know, that sounds all new age of me, but that’s really what’s going on.
Patching is ‘This code is broken, I should fix it.’ However patching is not support! This sounds weird to the unfamiliar, but there is a big difference between fixing the broken and helping people.
The conflict comes up when someone using software has a problem. When a user has a problem, most of the time they feel it’s a bug. Trying to explain the difference between a bug and a missing feature is complicated, but to boil it down I say ‘If it’s a bug, it’s supposed to work an it doesn’t. If it’s a missing feature, it’s documented as working differently.’ (We often say ‘it’s not a bug unless it’s documented, but that’s used to mean that if someone didn’t report the error, it’s not real. Schrodinger’s bug reports, as it were.) When it’s a missing feature you have a ‘feature request’ or an ‘enhancement.’
Thus I’m not surprised at all when someone makes a complaint ‘This enhancement is a bug, fix it now!’ and then ‘Why can’t I get support on this?’
Your’e asking the wrong people. Support doesn’t go out and fix everything. Support sits down with you, sorts out what really happened, how to fix it, how to work around it, and is trained to think. A good support person makes a note every time a weird error pops up, who has it, how they fixed it, and when there’s a pattern, reports it up the chain. “You’re right, sir, that’s a problem.” If they know it’s a problem, they give you a ticket number to follow, or some way for you to know what the over all status is.
So if the support people are being good and reporting things as they should, why don’t the bugs get fixed right away? Well, if they were that easy, they wouldn’t be bugs in the first place. Okay, that’s not true all the time. Sometimes it’s just that it’s a small bug and no one cares enough to fix it. Other times it’s waiting on other fixes, and finally the devs may just have more important things to do.
The thing you don’t do in these situations is say “I don’t know how to code, but this must be simple!”
That Dilbert will send the developers into a frothing fit of ‘You idiot…’
I’ve said it before, and I’ll say it again. It’s okay not to know something. Look, I barely know SQL. I don’t know AJAX at all. But what I do know is how to think and how to ask for help. And I know how not to ask for help too. The point is, I know my abilities and I know how to network and research. And I know when I don’t know something. Do not for the love of anything ask me to help you with Excel and pivot tables.
The point of that is if you start a sentence with “I know nothing about code but…” you better be very, very thoughtful about things. I recently suggested to someone “I don’t know this code, but here’s what I did on this other one… Would it be possible to leverage X to do something similar?” I don’t presume that I’m right, but having some related experience, I shared what we did in the hopes it will help or inspire someone.
And inspiration is the magic that fixes code.
Code is part art. You are creating something that has never been seen before, never conceived of, and never written. If that’s not art, I don’t know what it. And art, like all creative things, requires inspiration. We do not just pluck ideas out of the air, that were left there by the idea fairy. We see something in a puddle that makes us think ‘What if uploading images was as easy as a droplet of water…’ We have to invent, create and imagine. We have to dream. (Sidebar, this is exactly why my office’s draconian laws upset me. They stifle our creativeness and we make worse products.)
When you tell someone that something is ‘wrong’ there’s a reason you may get push-back like ‘Well what would you like it to do?’ or even ‘Why do you want to do that?’ It’s clear you have had that moment of clairvoyance where you can see a perfect future, and we want to see it too! That will help us either follow your vision and make it happen, or tell you that’s not going to happen right now. Your ‘bug report’ helps create better things.
At the same end, we have to remember that just because something isn’t working right, doesn’t mean it’s broken.
‘Right’ is surprisingly suggestive, and has a lot to do with use-cases. No two people use a product the same way. I open Skype when I want to talk to someone, my friends keep it open all day. I keep a word processing app open all day, others don’t. And consider email applications. My coworker has his open on schedule every 2 hours, and never alerts him to new email. I have a metric ton of filters that alert me when important emails are in, or when I haven’t checked in 90 minutes. We all push tools to fit our use.
Why, then, is it surprising that when something doesn’t work the way I want it to, this might be because of me, and not the tool? I’ve been telling people a lot that using WP Optimize (a very cool DB optimization tool) on a large site (or a Multisite Network) is akin to using a hammer to drive in a screw. You know you should use a screwdriver, but the hammer’s right there. Now, the plugin has some features that are annoying to have to roll on your own (removing post revisions and auto-drafts, and some scheduling), but the reality is that when a site is large, you’re using an inefficient tool for the job. PhpMyAdmin is a far better tool, though it’s more complicated and requires more knowledge, so people use this plugin. For a time, that’s fine, but when you grow and change, you have to learn and adapt.
Is it the plugins fault that it can run out of memory while working on a large DB? Of course not. It’s not even a bug, and the plugin isn’t broken. What the plugin is, is limited. And limitations aren’t bad. You have to limit software (otherwise it runs forever, and that, children, is what we call an endless loop), you have to give it an end point. Marking these and saying ‘Yes, today that’s a limitation’ doesn’t mean it’ll never get fixed, but just that today you can’t do everything.
Some takeaways for you.
- Make thoughtful suggestions and recommendations.
- Remember your needs may not be the same as everyone else’s.
- Reflect on if you’re using the right tool for the job.
- Try to understand the problem from as many angles as possible.
- Never, ever, ever say ‘This is easy code to fix!’ unless you’ve written it, and it was.
- Remember that genius is born of innovation and perspiration.
What do you think helps keep that balance between support and new code?
You’ve heard people say that if you’re not paying for something, then you’re the product? That’s never more true than with Tumblr. On this site, my content is generated by me, and the additional UGC (User Generated Content) comes in the form of comments. I can see my ‘value’ based on retweets, +1s and likes, but it’s in communicating with you commenters (and I try to talk to everyone) that I find out what’s engaging in my posts, what’s important, and what I get wrong. Oh yes, I get things wrong.
And now we’re at the crux of why Tumblr is so cumbersome.
