DreamHost is making my life way more complicated

Argh – normally I like everything DreamHost does. They had a history of just making my life easier over time. Their plan was simple: unlimited email and storage for your website, a reasonable price.

But now, for the second time, they are taking away a feature that I use heavily! DreamHost is killing catch-all emails! This is terrible for me.

The short version: I own this domain and I get or send email from from anything@morelightmorelight – so honeybooboo@morelightmorelight gets to me and I could send you a mail from DarkCrushingVoid@morelight… This is fun, but where it is really useful is in dealing with all the damn signups online.

Everyone online wants you to sign in or sign up! The reason why isn’t always that they love you and want you to be a member, it is sometimes that they want to track you and sell your details to other businesses. Imagine that! Sometimes they are nice but they just don’t have great security and someone steals your email address from them. That’s how you get all that spam!

Stop for a minute and give Have I Been Pwned a check for your email address. Yeah.

The emails I use for talking to people I love and care about don’t show up here. For example:
Image showing that my primary email hasn't been in a data breach
But when I am forced to register with a service, I just make up an email address with their name in it and I make up a password just for them. When they get breached by hackers, they hackers can’t use that email or password on other services to get into more stuff. For example:
Image showing that an email and password associated with adobe was stolen from the adobe servers

The password with adobe and the the email address are disposable to me.
I filter out emails from places that have been breached by hackers.

And all is good! I have unique emails per place to log in, I have unique passwords per place to log in, and I have a way to respond to data breaches. But now, DreamHost is turning off this feature for me.

They will delete my email account in October if it isn’t converted over to a different email account. I have to figure out a way to create email accounts for all the logins I’ve had over the years or go change them on every site. It is going to be an incredible pain in the ass. So now, I have to start figuring out how to respond.

My likely plan:

  1. learn how to download all of my emails and get a way to analyze them.
  2. Figure out all the unique email addresses I get email at and mark them as keepers and personal. This will take coding.
  3. Create a main personal account
  4. Upload all my history back to this account and figure out how to sync that back with Thunderbird
  5. Create all the other personal accounts and forwards from all the other personal accounts to the main personal account. This will take coding.
  6. Create business accounts and forwards for each of them. This will take coding.
  7. Create a general new throwaway scheme for login emails
  8. Investigate whether it’s time to move to hosting that gives me more control or adapt to this and concentrate on other things in my life.

That last one is also important. When I was younger I did a lot of flexing in tech to do things myself so I could be super independent. This taught me TONS of things and is great! However, I can’t do everything, so I now make compromises so I can spend time on what matters most.

That’s the part that irks me. I am fine with adapting to the new business reality at DreamHost – but they don’t have a plan for me. I’m going to have to build my own tools and figure out my own way. I can do this, but I don’t want to! I’d rather spend this time building a website or helping people or being with my family.

Dataclasses coming in Python 3.7

I’ve been loving my time writing in Python. I started with 3.4 I think, and every release has brought something new and useful to the table. All the speed and async improvements are great, but the thing that I loved most in Python 3.6 was the new f string formatting. Removing boilerplate and providing the simplest easiest path just makes every task easier.  Less code on a page means fewer places to make mistakes. So it’s much better to see simple than complex code.


foo = 'bar'
# this is so clear and direct
message = f'Meet me at the {foo}'
# versus
message = 'Meet me at the {location}'.format(location = foo)

In 3.7, I’m excited about dataclasses. It’s like the attrs library – just a simple place to store data where you don’t have to re-implement all the standard dunder methods (__repr__, __str__, __eq__ etc). Adding a dataclass decorator and a list of the fields gives you a class with a standard constructor and all the other bells and whistles. The more you can use the standard library to accomplish high level concepts without having to type more code and write more bugs, the better. It’s coming in Python 3.7, but you can use dataclasses today with Python 3.6 using this backport on github – totally same functionality.

I’ve been playing around with using them here.

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.

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.”

Conclusion

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.

o no its ringing o no

How to do a crisis call in technology

This started as an answer on Reddit that someone thought was good enough to gild. So I thought I’d expand it here while Lil Z is sleeping in case it helps more folks. Some tech folks really wanted to know how to talk to business people on troubleshooting conference calls. I’ve seen this done well and done poorly and I have strong opinions on the subject.

The System is down.

It isn’t doing the Thing it does and many, many people are desperate to get the Thing for important money reasons.

You are supposed to bring the System up.

The suits, who are measured on money stuff they can’t do without the Thing, feel terrified. They feel helpless. They can’t bring the System up, they need you to do that. You geeks want to concentrate, think silently, occasionally type things and mutter to each other. That is useless on the big conference call and just inspires anxiety. The day job of a suit usually involves being informed and making decisions – and they can’t do either.

Here is how you do a crisis call right:

1. There is a suit facing call and a geek facing call. Geek talk isn’t the same as suit talk. Perfectly reasonable geek talk (“a reboot will cause us to lose unsaved data”) cause suits to overreact and cause more problems.
2. The talkiest nerd gets to be in charge of communication. That’s their job, not troubleshooting.
3. They go back and forth, figure out status and direction and make real estimates. They give regular updates to suits and give direction to the geeks.

Two Calls

It’s important that you tell people status – if you don’t promise status at regular intervals, they will try their best to go find things out or try to help. They will interrupt the people doing the work so that they can get information they need to deal with their immediate problems.

Geeks get angry when questions interrupt troubleshooting because they think the problem is that the System is down. That isn’t really the problem – no one cares about the System but the geeks. The problem is that the Thing isn’t happening. If they could get the Thing without the System, they would – and that might be a solution you can offer.  The suits may be very happy with you taking a long time to fix the System if you can give them the Thing at regular intervals or on demand until the System is back up.

Folks at Krispy Kreme don’t care about the beautiful donut glazing machine as much as they care about devouring delicious hot donuts.

The Talkiest Nerd does the talking

The talkiest nerd can fulfill a very important role by giving status, information and choices to the suits. Let the suits actually make choices based on good information! They should make those decisions so they can make the money stuff happen! The whole reason suits employ geeks is because they need the Thing to make the money stuff happen – they need to know that they aren’t going to get the Thing for at least 4 hours because then they can tell customers to be calm, they are going to get compensated – or they can tell customers don’t worry – we’ll have the Thing within 4 hours.

Timely Updates

Another important point here is Timely updates. Set a schedule and then keep to it. If you say I’ll give you updates on this conference call every 30 minutes or every 15 minutes, then do it. The talkiest nerd can interrupt everyone 5 minutes before on the geek call and make sure they’ve got a good handle on things so they can give a real status.

The reason you make Timely updates is so that people can deal with silence. The big worry is that no one is working on things or that they are working on the wrong thing. Remember, the suits are feeling an unwelcome sense of helplessness. They can deal with silence if they know that they need to be back on the call at X time to get the next status.

It is important to give them some chill so that they can go and do the very important work of handling the downstream problems of the Thing not happening. They can go work on that knowing what’s happening in the next 30 minutes.

Things To Say

  • We have X people looking at the issue and this is our Y priority.
  • We have an idea what the issue is and we are testing it to make sure we are fixing the right thing.
  • It will take about X minutes to confirm and we’ll next update you with status at 11:45.
  • We were wrong and now we think the problem is X and we’re testing that idea.
  • We think we know what’s wrong. Here is an ELI5 short description and here are two ways we think we can solve the problem. Here are the high level time and danger trade offs in those solutions and here is the one the geeks recommend for the following reasons. (Let them actually make an informed choice here)
  • We don’t have any updates right now. This is tricky and X people are discussing the best next steps. We don’t see how we can get this solved before our next status update at 12:30, but we’ll blast out a message if anything changes drastically.
  • We’re manually handling a certain type of problem – please put a list together of the clients you want ordered by priority and we’ll handle them in that order and let you know when each is done.
  • The problem should be wrapped up in X minutes and we will handle any other issues resulting afterwards.
  • Tomorrow we will be rested and have a thorough look into what went wrong, how it wasn’t caught earlier, what warnings we can put in and how we can handle it better next time.

Why should you believe me?

Since 2003 I’ve worked in finance and technology, often as the face of technology to the business. Things have gone wrong and I’ve seen good communication and bad communication. In places where the business trusts tech to handle a crisis, these kinds of patterns have worked. I’ve also worked in places where there was a terrible relationship between technology and the business: patterns like these helped improve things.