Category Archives: Dev

How to not fail at support

Support is a really neglected part of a lot of development jobs. You want to just keep writing code and making releases. It’s easy to get into the code and forget that the users are the reason you get paid to write it! If you find you’re doing your best and solving problems, but don’t seem to get the credit or positive results to show it, this might help you. Also, the title is “How to not fail at support” – because this is not about solving the problem or techniques for doing the fix – this is about how to not lose the encounter even when you solve the problem.

All Code has Bugs

You’re going to have them. Nothing is perfect. Your plan for any software has to include support or you’re gonna have a bad day.

Why people get angry at you when you are trying to help them

People need help and when people need help they are vulnerable. They are trying to do something and it is important to their ability to succeed at their job. If they don’t need it to succeed at their job, they won’t bother you about it. If they do need help, they want it as soon as possible and they want to get back to doing their work.

H.A.R.E.M solves the problem

The best way method I’ve found to keep sane and make sure every user is happy with support is to follow the H.A.R.E.M method. There is no silver bullet for software development, but there is definitely a silver bullet for handling human beings who need support without them getting angry about it. I didn’t come up with this, but I evangelize it like crazy.

It sounds stupid simple, because it is. Doing it is harder than understanding it.

  • Hear the request
  • Acknowledge the request
  • Restate the request
  • Estimate how long until you will get back to them.
  • Meet or beat your estimate.

That’s it! It handles the customer service part perfectly. Do this and all you have to do is go find that race condition that disappears when a debugger is running!

Hear the Request

You need to have someone actually monitoring incoming support requests. This is harder than it sounds. Not hearing the request is a terrible problem – because they’ve reported an issue and no one is actually working on it.

If you don’t have a clear, easy dedicated, and monitored pipe for users to tell you about their problems, you need to fix that immediately. When someone doesn’t know where to go for help or when they go for support and no one looks at the queue, you have a big problem. Your users will hate you, and you’ll deserve it. If you’ve ever called for help and it hasn’t arrived, you understand the feeling of betrayal and hopelessness that you are associating with your labor.

Poor software with excellent support is a better deal for users than good software with no support. We know, because they actually use poor software with excellent support more.

Think through the experience of asking for help. You are trying to get help. It’s bad enough so that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. If you don’t know where to go to reliably get help, you will feel despair and anger.

Acknowledge the request

If someone tries to get support but they feel like they are shouting into the darkness, that’s the same as if they aren’t getting support. One of the big reasons people call instead of entering a ticket is that people don’t know if the ticket is getting looked at. If someone is calling, they know that a person has heard them.

Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear nothing. You will feel anxiety until you know that someone has heard you. You’ll “check in on them.” You’ll call to follow-up. You’ll do anything to make sure that someone is actually going to work on your problem.

When you acknowledge the request – you just say “I heard you and I’m working on the problem.” That is such a soothing thing to hear. Someone knows the house is on fire and help is coming!

This is super important!

  1. Users can chill out and go work on other things until you solve the problem
  2. If people know that submitting an email or ticket online gets acknowledged, then they can do that without tying up someone on the phone.

A script

“Hi Allie, I saw your ticket and we’re re-imprinting Asimov’s three rules on the floor robot’s positronic brain.”

“Hi Bob, I saw your message. I’ve unlocked your account for you and you can reset your password at the help portal. Happy to help, let me know if you’ve got any more issues with it.”

“Hi Carla, I saw your request. You’ve hit the hard drive limits under our policy.  I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”

Restate the request

Support requests are difficult. Don’t work on the wrong one. I’ve spent hours troubleshooting the wrong problem because I didn’t understand what they were trying to tell me. This waste is a waste of your time and the poor person who is waiting for you to fix their problem. They don’t care about the time you just spent and how hard you worked. No one benefits.

Always. Restate. The. Requests.

It sounds stupid. It sounds awkward. Do it anyway. It’s a “check for understanding“. In conversation you can just say “I want to make sure I’ve got this right, so let me restate what you’ve told me.” That language usually helps them understand why you insist on saying back to them what they said to you.

Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear that someone will help. Relief.. Then they tell you the house isn’t on fire – but you are seeing the flames! Or they say they’ve fixed the water leak, but you are seeing a waterfall in your bedroom. Are they insane or incompetent or lazy or lying? You will feel angry, frustrated or betrayed.

A script

“Hi Allie, I saw your request – I just to make sure I understand. You’re saying the floor robots are ignoring Asimov’s 3rd Law – that they are killing themselves out of boredom?”

“OH MY. Sorry, you’re saying that they are ignoring Asimov’s 1st Law and killing everyone on the floor out of boredom! I’ll send Will Smith over immediately. Please shelter somewhere safe.”

“Hi Carla, I saw your request to increase your hard drive size – you’re telling me that you have to use a program that only works with large files on your primary drive. You’ve hit the hard drive limits under our policy.  I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”

Estimate how long until you will get back to them.

A key metric for user satisfaction is “First Call Resolution”. FCR makes people happy. For phone calls that means getting solved during a conversation. For emails and tickets, that means someone resolves the issue within 1 hour of the request coming in and while in the first response to the request. Yay – those are automatic wins!

But there are plenty of issues that are bigger than a single call or take more time. This is where real rancor and unhappiness can develop even if you are solving problems and doing everything else right.

Tell people how long until you will get back to them. This isn’t a guarantee that you’ll have the problem fixed – just a message of how long they should expect until you can update them. This is very important because it gives them a chance to make decisions and be empowered. Just telling them this lets them be less helpless.

If you think this reporting issue will take 1 hour, and someone has to be on the phone with a client in the next 20 minutes, they can decide to calculate the numbers themselves or to postpone the call. Letting someone know enough to seek other solutions is good for them.

An estimate is basically a promise to the user: You can bug me if I don’t come back to you before this time. If that isn’t soon enough you can seek other solutions. If it is ok, just relax and work on something else until I call you – I’ve got this.

A script

“Hi Zelda, I’m not sure why the delivery drones are returning to the warehouse without releasing the payload. Just to be clear – the address is correct, the payment is fulfilled and they order hasn’t been cancelled, but the drone just goes to the address, circles, and comes back with the package? This is tricky. I know you are under a time crunch. I’ll start looking at this and I’ll get back to you by 2pm with either a solution or I’ll let you know how much longer it will take me.”

Meet or beat your estimate.

When you make an estimate, you’ve made a promise. Keep your promises.

Don’t break your promises. Do what you say. Be clear. Meet or beat your estimate. That’s why your estimate includes a statement saying you might come back with another estimate. Do that if you think it might take longer than your original estimate. Better to keep the user in the loop and up to date than to have them know that they can’t trust you.

A script

“Hi Zelda – Just calling to check in with you. This is trickier than we thought. The GPS system connected to the drones doesn’t show the address! That’s something we are working with a vendor to correct, but it won’t be fixed by 2pm. I’ve asked them to keep us up to date and I’ll chase them. I’ll get back to you by 4pm with either good news or I’ll get you a better estimate.”


The reason this works is simple: it’s humane, it respects the needs of the person asking for help and it treats them with good manners. It won’t solve problems for you – you’ve still got to do that, but it will get rid of feedback that your people feel abandoned by your support team or that they don’t want to bother reporting issues.

Backing up a SalesForce instance

SalesForce is an interesting beast. You gotta work within its limits, and it is great within them. As soon as you want to venture outside of the normal flow, things get complicated.

They suck  into SalesForce, but never out – it’s designed as a lobster trap for your information.

Weirdly, there’s not much on the SalesForce AppExchange that helps you easily back up your data on site. There are some tools that help you easily back up to another cloud, but little that helps you get your data back within your own walls.

Still, there’s a little layer over the SalesForce API in Python called simple-salesforce. Here’s a quick script I threw together to help put all your data into csv files.

I love PETL

When I started at my current job I noticed we we had lots of room for improvement about how we imported and exported data.  Folks had been using the MicroSoft SSIS platform as a way to Extract, Transform and Load data in and out of our database to various files.

SSIS is great for lots of things and has a lot of upsides. It is very drag and drop, folks don’t have to know a lot of programming to get it to do things, and it has lots of functions built in. If you need more programming power, you can execute C# or VB scripts to do the fiddly bits.

But I hate it. ( Don’t worry, we’ll get to the love soon.)

My biggest problems with SSIS:

  • It is unversionable. Try reading a git diff of an SSIS change. The xml is designed for a machine to read, not a human. If you want to know what has changed over time in your world, it’s a problem.
  • You can only use Visual Studio to edit it. Many of our SSIS packages include VB or C# scripts. That sounds fine – but apparently these compile to an undiffable, uneditable blob in the xml that is only recompiled if you save using visual studio. So if you want to change something across many SSIS package scripts, you have to open and resave each one.
  • It hides options under rocks. Finding out how something works requires lots of delving into lotsa windows and dialogues.
  • It changes things unexpectedly. Click in the wrong dialogue and it helpfully re-infers datatypes from a file for you. You don’t know until you go to execute.
  • It slapped my momma. Etc.

I wanted to move my team to something that was better for people.

We need something:

  • That we can diff
  • That we can do code reviews and pull requests on
  • That is simple, expressive and clear.
  • That is powerful.

To me that sounds like a programming language.  I encouraged folks on the team to try accomplishing a couple of tasks that might use an SSIS package instead to use Python. Immediately, things got better. Our code reviews made sense. Code quality improved with every single pull request.

We used pymssql to connect to SqlServer and inserted records as needed after processing them. Navigating and transforming XML docs was easy, CSV files were eaten up by the native DictReader.

And then Derrick found PETL. It’s beautiful. You point it at data and make simple moves to completely transform it. I’m smitten.

I had dozens of files to read from, each a quarterly file for a year – only noted in the file name. Each had a crappy heading line that preceded column headers. I needed to put them into 1 file for loading into SalesForce Wave. Whacking together a solution with PETL was effortless. Line 36 is where the PETL starts, and it’s so small and good that it is nice to see how much it encapsulates.

Quick Project Names Demo

At work, I’m trying to convince people that we should auto-generate at least a suggested code name for our project names. It’s an important thing for compliance and secrecy. You’d rather someone is overheard talking in the elevator about “Project Icy Gneiss” than about “the restructuring of Acme Corp”.

I wanted to make the point that if you just have a small list of adjectives and nouns you quickly get a vast space of possible names – more than we’ll exhaust.  But a working demo is more persuasive than logic.

I knocked this together last night: Projects-a-Plenty.


Used bootstrap & angular which is kind of overkill on something this tiny.

Mistakes were made, tears were shed

Orbital 0.2.2 – Mistakes Were Made


This is a tweak to fix some problems people told me about on the Orbital Feed Reader GitHub Issues page.

Some folks were getting a very bad experience during the install – everything goes blank – or they were able to install and then couldn’t add feeds or read feeds. Not good for a feed reader!  I traced down a problem where if you had a specific new default collation on your database, the way I initialized the database tables made everything go boom.  It’s fixed now, but it’s part of the problem of supporting a lot of different configurations without a giant automated test lab.

The other was that someone pointed out there is an improved PressThis page in the latest version of WordPress.  Everything was working, but you’d get a nudge message saying that there was a new way to use PressThis and why are you going this old way?  Updated and I think it’s a really good experience now!

I also did some cleanup and logging improvements so that I can work with folks who have problems in a better way.

From Jekyll to Hugo

Sometimes simpler is better.

After being away from Orbital for a bit, I started revving my engines a bit by trying a new project on the subway and hacknight. Project Munchausen is about doing some writing and exploring some ideas – so I tried to get myself away from doing too much programming on it. Since it is just writing, I wanted to avoid falling into the trap of using a big content management system like WordPress.

I started exploring with the first Static Site Generator I know of: Jekyll. Jekyll powers the Pages feature on GitHub. I got really far, but felt really constrained. It felt like Jekyll was trying to push me to turn my site into a blog, like the downhill path of Jekyll was to create a blog.

I didn’t want to create a blog – I want to make something that’s an exploration of a subject. It will change over time, so it should have an RSS feed generated, but I didn’t want to only have a timeline view of things.

I don’t know how I happened on Hugo but it seemed perfect. The templates are simple, Go is a pretty simple language to use, and the organization of the content is really easy to understand.

In Hugo, you have a directory named content. Under that directory, any other directories are Sections.  Content goes in a section as a Markdown file. Templates can iterate over those sections and their contents.  Easy peasy.

So far, I’ve gotten farther with Hugo in a few subway rides than I have with long sessions wrangling Jekyll. My goal is to put something up on the web in a month.

Orbital Feed Reader 0.1.9 Codenamed “BORN FREE” is out!

Last night I pushed out the final changes to uncage version 0.1.9 and get it out in the wild.
MAX LAZER tears off on his own  to explore Oregon

This version is mostly about giving you freedom. You should be able to easily import your stuff from other platforms into Orbital Feed Reader to use it. If you decide that you don’t want to use Orbital Feed Reader any more, you should have an easy way to leave. Any software that doesn’t tell you how to leave it is something you should be suspicious of.

Get Feeds IN

Share your OPML

For Feed Readers, the standard way to exchange lists of subscriptions is a standard called OPML. It’s an old format, but it’s how they all exchange lists of feeds. I’ve buffed up the OPML import to handle larger numbers of feeds. After you import the file you have a chance to look over the feeds and edit them, tag them or exclude them entirely. Hit save and they’ll all flow into the backend.


Get Feeds OUT

But we also don’t want Orbital to be a lobster trap for you. If you import that kind of data I also want you to be able to export that kind of data. Now Orbital is good at exporting your feeds. If you are logged in – we’ll export a file with all your public and private subscriptions and let you take that wherever you want. Some folks want to share their OPML publicly – if you aren’t logged in, hitting the same URL gives you only the public feeds. All your private stuff should stay safe!

Read Lotsa Feeds

Now that Orbital can handle tons of feeds coming in I wanted it to be easy to actually sort through them. Feed Tags now start off collapsed and you can expand them anytime by using the little twiddlers next to each. That’s a technical term. The twiddlers make it much more manageable to see 200 feeds over many subject areas.

Orbital Feed Reader 0.1.8 Codenamed “BEAUTY TREATMENT” is out!


The most common feedback I’ve heard from folks on Orbital is that it’s not very good looking.  It does the job, but it isn’t a pleasure to look at.

I assume these people are all supermodels, so it looks like Orbital is doing great among the high fashion set.

I got out my scissors, called in the wardrobe department, applied polish and buffed with a chamois. This is the new smooth look, designed to blend in with the new admin themes of WordPress.

Hey, good lookin’!


Beauty comes in all thicknesses

Along the way, I’ve added some features – now it is responsive, cleaner and is even usable on my Galaxy S5. Check out this hot resizing action!

Future attractions and graceful aging

Coming soon are some cool things. First, I’m working on version 0.1.9, code named Born Free. It will deal with the how to leave Orbital and how to get into Orbital. I’d never want to trap you!

Second, WordPress is going to upgrade to version 4.0 soon. I’ll be getting Orbital ready for that, and the new REST API should make it easy to build a better mobile experience for Orbital.

Press for Orbital

Two new reviews for Orbital bring a smile to my face!
WordPress Plugins A-Z gave Orbital a 4/5 rating:

This is a great feed reader especially if you are doing research for a post or if you are like many people out there who write additional articles based on what they read. This make it easy to get a pull quote from an article and drop it right into a post. While the layout and functionality is a little raw in its appearance it seems to work very well and to give it a good go I added it to my secret blog site as a place to test some ranting on article and stories. And it seems to work quite well..

That’s great feedback and I feel like I do need to work on the style and appearance – it’s tough and I need help.

Jeff Chandler over at WPTavern also reviewed Orbital, comparing it to Feedly and Google Reader. It’s a lukewarm review – he doesn’t like the interface and feels like Feedly plus PressThis is find for him. Still, he’s offered to help me by looking at revamps of the interface.