Tag: support

Hello, Mike
There’s an interesting thing when people think I’m Mike. Or perhaps it’s interesting when people think my name is Mike.

My name is four letters. Three are the same as Mike. The last is an A, however. The best guess I’ve ever been able to make has been that people read ‘MIK…’ and their brains absolutely stop. This has been a problem my entire life, in and out of tech support, from school to work to everything in between. I was called ‘Mike’ at my SATs, much to the hilarity of my classmates.

But I rarely correct people these days, certainly not when I’m online, because it’s one of those things that really only matters if we meet in person. In person, I will correct you. “Actually it’s Mika. With an A.” I’ll always be polite when you ask me how to pronounce it. The first time. The second and third time get you teased. At four or five, there will be serious remarks. At seven, I start intentionally mispronouncing your name.

Since most of my communication, even with my own coworkers, is online, and since there’s a fellow named Micah (pronounced the other way), I really give people a pass with mucking up my name. It happens and if it’s not intentional or obstinance, I don’t mind.

At the same time, I like to keep track of places where I’m more often called Mike. I try to make sense of the madness just to understand the world a little more. While all of this is anecdotal, and while I did make a scratch sheet where I tallied these things over the course of 4 months, this is not some government funded study. The numbers are also off if I’ve been talking to people from countries where Mika is a normal name, and moreso in Japan, where it’s a girl’s name.

When am I Mika or Mike?

So here’s the non-scientific notes I’ve boiled things down to:

I’m Mike…
- If I do technical things really, really well
- When I talk code/development
- When I talk about my wife
- When someone is incredibly upset for whatever reason
I have no name…
- When I do technical things really wrong
- When I disagree with developers
- When I apologize to people
I’m Mika …
- When someone realizes they’ve been wildly out of line and apologizes to me
- When someone has been really personable and polite the whole time
- When I talk to someone who consistently uses proper grammar and punctuation
What Does This Tell Me?

It’s important to note that the ‘technical’ things I do well or not don’t actually have to be correct. Many times I do the code things really well and they just disagree. But if I’m perceived to be correct, I’m generally a Mike.

When people are angry they tend to stop reading well, the comprehension goes out the door. That lends some credence to my theory that people’s brains stop. Strangely, though, when I get things really, really, wrong (or am perceived to do so), the use of any name in their replies plummets. Like I found three in a year. It’s possible that those people, still being angry, are reading my name as ‘Mike’ but cannot find it in themselves to be angry at a male name in the manner they’re about to be.

As for me talking about my wife, that’s just heteronormativity in action, and for the matter of this study I ignored it. It skewed results. It’s the same with folks who are from Scandinavia, where Mika is a boy’s name.

My Conclusion?

People still often default to thinking everyone’s male.

I too have this flaw, I admit. But seeing it in others and how it impacts me certainly makes me think about it more.
20 April, 2015
Learn Another Language

At WordCamp San Diego, someone asked how he, as the only English support tech, could help his coworkers learn English. I gave an answer (watch sitcoms with closed captioning on and try some software) but then I took the opportunity to remind everyone that was a native English speaker to learn a second language.

Many people have thanked me for saying that publicly since then. For those who missed it, here are my thoughts on why and how we should do this.

Learn Perspective

All the BS about opening your neural pathways aside, it’s a good idea to learn another language. I picked French because my mother, father, and step-mother speak it. It’s one of the most commonly spoken languages, it’s useful in most of Europe. But more than just being able to communicate more with family, learning French puts communication in perspective.

As I learned at WordCamp Tokyo, I need to phrase myself clearly and simply when I’m speaking via a translator, or with someone who does not speak English natively. Learning French is also giving me a great deal of sympathy for the people who get emails from me about Plugins. Here I have to talk about things in technical terms for which there are no decent simpler terms. When I connect that I’m talking to someone who’s ESL, I change how I explain things to try and make it easier to understand.

Learn For Fun

I sometimes set my phone to French. I watch movies in French (with subtitles). I read comics in French. Doing those things, forcing immersian for fun, makes me think harder and process. My phone in French lasted a brief moment before I realized I didn’t know how to ask what the weather was («Quel temps fait-il»). Having to both ask and listen to Siri in French showed me where the major gaps were in my skills. I have trouble thinking in French. It’s been a couple years since I studied it, though, and I only started studying again in earnest in February.

Learn With Software

We’re techs. I use Duolingo which is free and lets me ‘play’ in French on my iPad. I take breaks, I sit on the couch and give it 10 minutes of my brain, and I struggle with one stupid section.

See? I’m learning French!

I’m not very good, but it lets me keep trying. And I can use my iPhone, iPad, or browser. I can see where I suck and where I’m great. I can go back and take a test over again all I want, and no one cares but me.

Having also used Rosetta Stone, I find this far less frustrating. Also did you know on the Mac keyboard you can hold down a letter to find the version with accent marks?

Cool, right?

Learn The Point

English isn’t the majority language.

WordPress (and many other CMS tools) are pushing Internationalization.

Internationalization will be a big focus of the coming year, including fully-localized plugin and theme directories on language sites and embedded on dashboard in version 4.1, which is coming out December 10th.
— Matt Mullenweg: State of the Word 2014

Simply put, if you’re not getting yourself ready now, you’ll regret it later. Pick a language. You won’t get better until you start.

15 April, 2015
Slow Site Troubleshooting: Database Edition
So your WordPress is slow and you’ve already done the needful. You’ve checked your plugins and themes, you’ve put caching in place, you’ve checked for hacks, but it’s still slow, especially on the back end of WordPress?

It may be your database.

More specifically it may be your wp_options table. When your options table gets very, very large, it gets very, very slow. WordPress regularly queries that when you’re logged in, and it’s not indexed. DB indexes are used to locate data fast, without searching every row in the tables. This sounds sensible in many ways, but we don’t

Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed. Indexes can be created using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records. We don’t use ’em in the options table for a variety of reasons, but mostly that it slows things down.

So in lieu of making indexes on your own, what can and should you do to debug things?

Optimize Your Database

Got WP-CLI?
```
wp db optimize
```
Otherwise you can use phpMyAdmin to check tables with overhead and clean ’em up. I don’t use a plugin, I think asking WP to optimize itself is a little weird, but you certainly can. The point here is to keep it clean.

Cache that Database!

Caching makes things better. Right? Kind of right. Mostly right. I use memcacheD (which I often typo as memecached) and that plus an object-cache.php file can cache your DB calls so they’re faster, which is great. Unless your wp_optimize table is too big.

Your cache has two major issues. First, there’s going to be data you don’t want to cache (like private, sensitive information), but also when your cache is too big, or it’s trying to save data bigger than it is, it can make things slower by trying to cache, crashing, and repeating that over and over. That gets worse when we talk about the temp data generated by _transient entries in your database.

Check The Size

Your options table really shouldn’t be large. My biggest, busiest, site is only using 142K. It’s a site that’s old (8+ years now), it’s had many iterations and themes and plugins. You’d think it would be filthy with leftover code, because we all know plugins don’t always clean up. Nope. I did rebuild the DB once, in 2009, when I rebuilt the entire site from scratch, but that was 5 years ago and a lot has changed since then with plugins and themes. The next biggest site, a Multisite Network, has a wp_options of 100k. The biggest I’ve had is one of 500kb and that’s on a test site where I install and delete plugins daily.

You get the point I trust. These things should be small. At most, I’m going to have a lot of _transient entries. But that’s actually issue here.

Clean The Transients

There’s a story here about why WordPress doesn’t really clean your transients. Why? Well as the name implies, transient data is meant to be transient. It should be temporary data, saved and used briefly, and then it should go away. A lot of developers, as it happens, were storing it for long term caches. Like checking when the last upgrade ran, or when a cron kicked off. So while for one, glorious, month we did nuke them all on upgrade, now we only delete expired transients, which doesn’t help as much as it could. As Nacin said:

This leaves much to be desired, but we don’t want a core update to be blamed for breaking a site that incorrectly assumes transients aren’t transient.

Basically people doing things wrong in a way we couldn’t adjust for.

There are plugins like Delete Expired Transients and Transient Cleaner (which has the cutest header image). Those can be used to clean out your old transients.

If you want to go whole hog, there’s a command to clean the whole thing out with SQL:
```
DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')
```
Of course you want to run a db optimize afterwards to actually flush out the rows.

As always WP-CLI has features like wp transient delete-expired and wp transient delete-all.

What if that doesn’t help?

Then you should check the Database to see exactly what the biggest value is. In this case, I ran wp db cli to leap into the database and then this:
```
mysql> SELECT option_name , length (option_value) AS blah FROM wp_options ORDER BY blah DESC LIMIT 5;
+--------------------------------------------------+----------+
| option_name                                      | blah     |
+--------------------------------------------------+----------+
| cron                                             | 12194468 |
| _transient_feed_d117b5738fbd35bd8c0391cda1f2b5d9 |   223838 |
| _transient_feed_ac0b00fe65abe10e0c5b588f3ed8c7ca |    98184 |
| _transient_is_cached_instagram_images_self       |    97315 |
| mytheme_storage                                  |    18354 |
+--------------------------------------------------+----------+
10 rows in set (0.02 sec)
```
CRON is 12 megs. That would be the problem. Of course the only way I know of to fix that would be to totally trash cron and let it start over.

Is That It?

When you see a ginormous wp_options table, what do you do?
23 March, 2015
Overreaction to Negative Reviews

I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.

This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.

With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.

You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.

I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?

It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.

We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.

If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.

Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.

While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.

Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.

Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.

So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.

What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.

2 February, 2015
You’re Not The Priority With Free Support

Once in a while, someone flies off the rails when they don’t get a fast enough answer for their question in a freely supported product. They don’t get the right answer, or they get what they feel is a run-around by a total stranger trying to understand the real problem, and basically they feel the service should be better.

Here’s a cold hard truth.

When it comes to free support on free products, you aren’t the priority.

Usually when people get shirty about the ‘lack of quality support’ I point out that (on WordPress.org) support is handled predominantly by unpaid volunteers who are offering sage advice and help out of the kindness of their hearts. This is mostly true. Some of us are paid by our companies to volunteer, others are doing it to master skills (not much teaches you how a product works faster than helping someone else debug it), and others do it because they enjoy it. But as far as WordPress goes, it doesn’t directly pay anyone to do support.

Sidebar: Automattic isn’t WordPress and doesn’t own WordPress. Automattic is a company who pays for some of their employees to help out in the forums. And it’s making my point. Some of us get paid by our companies.

When I tell people that they need to scale down their expectations, what I don’t mean is they should expect worse help, but that they should expect slower help. Because they’re not the priority.

What’s my priority? Number one is my family (hello). But after that you get my paying job. Keeping abreast of everything WP related that impacts us, keeping on top of server changes, looking for patterns in tickets to see if we missed something, and generally knowing everything I possibly can about WordPress at DreamHost. After that my priority becomes the websites I run (like this one) and other hobbies I have.

That begs the question of when is WordPress public support my priority? When I have the time. I try to carve out at least a couple hours a day to check in. These need to be consecutive hours, a nice block of time to catch up and read and help. I don’t always get it. Sometimes I get thirty minutes. And when I am helping out, I prioritize my time.

If there’s an alpha/beta of WP out, I check there first. If we just released a new version, I’m over in the general troubleshooting. Then I hit Multisite, because we have a very small amount of people there. If I still have time, I’ll get the ‘Requests and Feedback’ and ‘Misc.’ forums. Next I hit up the dread Ideas forum, clean out the spam, and sort things that are dupes or solved or in the wrong place.

And then I’ve hit how much free time I have, so I go over to plugins for reviewing those. Anyone who was closed for a security issue comes first. After that, it’s anyone who replied to our emails. Then I close out anyone who didn’t reply in 7 days, check for people with bad plugin names, and finally I can start in on the queue.

It’s a lot to do on top of a day job. So sometimes you will get a reply from me at 8am and then nothing again for 24 hours, because all of those things are important to people and they all need to be taken care of and you, personally, aren’t my number one priority. It’s the same reason why you may not get immediate replies from anyone volunteering, and its why I tell you to lower your expectations.

Free support isn’t better or worse, but it does run at it’s pace and that may not be yours.

17 December, 2014
Make Your Advice Work

I love Project Runway. Seeing people be that dramatic and traumatic over making clothes is fun, plus I love the design. One of the best parts is when Tim Gunn steps in as a mentor. He rarely tells people exactly what they need to do, but he will give them his opinion. It’s the way he handles critique that makes him impressive. Recently he had a new show called Under the Gunn where he let other people mentor some young designers, and that show was, shall we say, less than spectacular.

One of my favorite designers, Nick Verreos (aka Uncle Nick), was one of the worst mentors. Instead of helping his mentees, he did the work for them and made their designs look more like him. He drew for them, he sewed for them, he even gave them ideas.

That’s not the Tim Gunn way.

COURTESY OF A+E NETWORKS
Tim Gunn (left), host of the new Lifetime show ‘Under the Gunn,’ on set with mentors (second from left to right) Mondo Guerra, Anya Young-Chee and Nick Verreos, all former contestants on ‘Project Runway.’

When people ask you for advice on their work, it’s hard to not insert yourself into the process and put your own self into the work. You, too, are a smart, creative person. That’s why they asked you! So how do you keep yourself out of your advice and let people learn?

Boy that’s hard.

You have to let go of your own ego to do this. You have to be willing to remove your own desires from the equation, and instead of saying “Do this” you have to suggest “What if you did it like this?” It’s a classic case of leading the horse to water, but you really are the one who is going to show them the land where the ideas are and nudge them along.

One of the things I do a lot of is plugin reviews, and many times I see people reinventing the wheel. I don’t often put value judgements on plugins, and in fact I try hard not to do so. But when I see someone taking the hard road of handling a feature, like wanting to put autoplay in all YouTube videos, I wonder why they’re inventing a new oembed and shortcode and not filter oembed_fetch_url and have it check if it’s youtube and, if so, put in the arguments for autoplay?

But… Do I tell them “Here’s the code you want” and give it to them? Will that make them better developers? No, it won’t. Instead, I have to explain why reinventing the wheel isn’t a great idea.

Any time a plugin replicates functionality found in WordPress (i.e. the uploader, jquery), you’ve done something wrong. It’s a security risk, for one, as the features in WordPress have been tested by many more people than use most plugins, so the built in tools are less likely to have issues. But more importantly, you’ve given people too many ways to do one thing. A user doesn’t want to remember seventy shortcodes. They want to know “Hey, I know pasting in my video URL makes it show up on WordPress! I’ll do that!”

They want the easy, and you need to remember to give them the easy.

Similarly, advice on what’s right should lead towards what’s easy. What’s easier for you to maintain, to develop, and support. I know what works for me, but when I’m teaching someone how to update plugins and they ask me “What tool do you recommend?” I say “What do you already use and like?”

That’s my secret, by the way. I teach and mentor by trying to learn what they already know, what they’re already comfortable with, and then explain how to do things better or faster with those systems. But I try not to show them “This is the way to do it.” I stress this is A way to do things, unless what they’re doing really is a reinvention of the wheel, without making the wheel any better.

26 September, 2014