For my day job, I have the whimsical title “Happiness Gardener.” Honestly I don’t love the title. When asked to provide my title for paperwork, I tend to just say “developer” since that’s the sort of work I tend to do, though you wouldn’t know it from my title. I work on the support team, providing debugging and tool support for colleagues who interact directly with the people who use my company’s products. These colleagues are called Happiness Engineers, a title that is still whimsical but from which does make a certain sense once you connect it to the role these colleagues fill. Getting from “developer” to “Happiness Gardener” takes a little more squinting, I think.

So, the Happiness Engineer position existed before the Happiness Gardener position. Back when there were a dozen or so (maybe even fewer) Happiness Engineers (HE for short) at the company, a developer was hired to fill the sort of role I now fill. The idea was that he would sort of clear out weeds by fixing things that affected HEs and customers, while also cultivating improvements that’d help HEs flourish in their roles, and so the Gardener title was born. I was later hired as the second Gardener. The original Gardener has moved to a different team after about 5 years in the role, and now I lead a team that has grown to 7 members.

Happiness started out as just a few people working together on one team, but over the years, sub-teams focusing on specific products or on specific types of support have formed, and now we’re around 100 people. Some teams have come and gone, or been renamed, and people have floated from one team to another. Over the years, a few in-jokes have popped up as well.

Employees at my company work remotely, from coffee shops, airplanes, their homes, and pretty much anywhere they fancy working from at which power and wifi are available. Once a year, we all get together for a big meetup. In preparation for this year’s meetup, some colleagues designed and ordered a bunch of patches for people who have worked in the Happiness organization. The patches are something like 1.5 inches in diameter, and each of the various teams and represented in-jokes have a patch. I knew about this project a few months in advance of the meetup and was uncharacteristically excited to get my hands on the patches. I’ve got a backpack embroidered with the WordPress logo (a perk of working for the company I work for), and I’m eager to get these patches stitched to the backpack.

Because my work tends to touch a lot of the Happiness subteams, I was deemed eligible for a bunch of the patches. Now I just have to find a way to get all of them stitched onto my backpack in a pleasing way. The Happiness Gardener patch is the one that looks like a rake. The origins and meanings of the others I’ll leave to your imagination for now.

Las Palmas

My team at work spent a few days last week at Las Palmas, on Gran Canaria — one of the canary islands. The islands are part of Spain but are geographically much closer to the northwest coast of Africa. For some reason, the airfare from my home airport was outlandish, so I drove to Charlotte, then flew through JFK to Madrid and then on to Las Palmas and more or less reversed the sequence (with some complications) on the way home, which was not altogether fun.

The city was mostly unremarkable to me — just sort of a standard city with lots of one-way streets and crazy parking (like on the sidewalk, straddling a corner, or at times even double parked). It was my first time driving outside of the U.S., which made me pretty nervous.

Most of the cities I’ve visited outside of the U.S. were pretty English friendly, but here very few people spoke English, so I often felt like a big, helpless, boorish, American baby. It didn’t help that I’ve been familiar with French more recently than I have Spanish, so when I did try to speak — even just to apologize for being a dumb American or to communicate other simple things, I often enough did so in a strange English-Spanish-French pidgin. Luckily, one of our guest attendees from a different team was a native of Argentina wonderfully fluent in both English and Spanish and was able to help us navigate meals and other transactions with the locals. Most of the time, he would just order plates of various foods for the table, so we had lots of variety, and it was all really good. We ate various rice dishes, lots of seafood of many types (squid, prawns, snails, clams, several fishes, octopus, and likely others I’m forgetting), and wrinkled potatoes with just about every meal. It was really some of the most consistently yummy food I’ve had at a meetup, and it was very inexpensive to boot.

Some of my colleagues had hoped to do some surfing or snorkeling while we were there (we worked at a place catering to such outings called The Surf Office, which was featured in the New York Times while we were there, complete with pictures of our team and some others who were sharing the space with us), but weather and scheduling stood in the way of those plans. Our main venture as tourists was to visit the Caldera de Bandama, a volcanic caldera. There’s a steep path down into the basin of the inactive volcano, where a working farm is currently situated along with some abandoned buildings. It was really neat, and the trip back up out of the volcano highlighted how seriously out of shape I’ve let myself get.

We got some good work done on the trip, and for me, the tourism to work ratio was about right, so the trip itself was very good, though I could certainly have done with less travel at both ends of the trip.

This slideshow requires JavaScript.



I spent last week in Park City, Utah at the Canyons resort with coworkers. I had my first fly fishing experience, took a couple of short hikes, helped a few of my company’s support staff refine some technical skills, and spent more time talking to real live people than I do in probably an average month (which was both rewarding and overwhelming). The mountains of Utah are really gorgeous, as pictured below.


In April, I went to Cardiff, Wales to do work on a project for my job. We got lots of work done but also did a fair amount of tourism. The coolest thing for me was visiting the Doctor Who experience and seeing lots of props from the show. We also visited a castle (some went to a second, apparently more impressive, castle). There were lots of gardens, and the city itself was pretty happening. One night we went to Chippy Lane, which is where one goes to get fish and chips when really terrifically drunk. We weren’t terrifically drunk, but it was a neat experience nevertheless. Here are a few photos from the trip.

The Year Without Pants

This summer, I attended a really good local conference called CodeStock at which I also sat in on what turned out to be a really bad session on being a remote worker. The original speaker for the session wound up not showing, so someone representing one of the conference sponsors stepped in to lead the session, since there was interest. So it was understandable that he didn’t have a bunch of information prepared. But he had worked mostly from a home office for a while, and he managed a remote team, so he felt equipped to lead a chat on the topic.

The problem was that he didn’t have a real understanding of how remote work ought to function. His advice seemed mostly to include ways of trying to shoehorn in-office work into a remote-office scenario. His approach, in other words, was to try to make working remotely mirror as closely as possible the experience of working from an office. I disagreed vociferously with nearly everything the man said, and it was all I could do to avoid rolling around on the ground in despair. I’ve worked from a home office for nearly a decade with companies that really embrace remote work as a new type of work rather than as a mere perk for workers, and so I figured that my experience probably wasn’t terribly relevant for the others in the session, who would likely be in just the type of environment the leader gleefully perpetrated and who gobbled up his well-meaning advice. I kept mum and swallowed my despair.

I’ve worked at Automattic for approaching three years now. We’re a fully distributed company, with employees happily working from at least a couple of dozen countries. It’s the best place I’ve ever worked, and I’ve been really happy at a couple of my other jobs. For a few months of my first year at Automattic, I worked with Scott Berkun, who has recently published an account of his time there in the form of a book titled The Year Without Pants.

I should go ahead and confess that this isn’t generally my sort of book. I like to read fiction, usually the more ponderous and confusing the better, and business books just don’t interest me a whole lot. I don’t have mental bandwidth for them. Still, it’s a book about my company and a book that — since I worked with Scott a little on a project to encourage people to blog daily — it was infinitesimally possible I might get a brief mention in (I don’t). So, tailor your reception of my brief review with this confession about my qualification for reading the genre in mind. My view of the book is that of an insider and not of a particular expert on business books.

Of course, being an insider makes the book hard to judge in a meaningful way. I know the people discussed in the book. I spent a few days last week actually hanging out with them at a company meetup, in fact (I’m famous by proxy!). And just as you hardly recognize your recorded voice as your own, it’s hard to know whether what someone writes about your company squares with 100% faithfulness to the company as you know it. Does the book have it wrong or do I?

Some of what Scott writes does seen genuinely wrong, or at least betrays a net cast too wide. For example, in writing about development process, he makes the unqualified statement that our method is to write a launch post prior to beginning feature development. This isn’t something I’ve ever done, though doubtless other teams within the company have.

Scott writes largely about the team he led while at Automattic, and I feel at times as if he assumes that team’s method of working represented that of the company as a whole. Whether he does so out of editorial expediency or out of myopia it’s hard to say. If it’s a defect, it’s a small one.

I don’t feel as if the book ultimately lives up to the promise of its subtitle (“ and the future of work”). As a reader of a business book (if not an expert such reader), I expect something of a payoff or prescription for how the sort of work done at is leaching into the larger occupational consciousness, or of how other companies might emulate the Automattic work experience. The book does include three chapters that purport to make a sort of prescription, but the prescription is pretty squishy (necessarily — it’s the nature of the beast), and the chapters seem tucked into a book that mostly stands well enough on its own as a document describing Scott’s experience at Automattic. In other words, the book feels a bit like a memoir that got hammered sort of halfway into something that could be sold as a business book. I think I would have preferred straight memoir.

As semi-memoir, it’s a nice read. The affection Scott had for his team shines through, and the book shows enough of the work process to be instructive and thus not dismissed as pure personal fluff. You get a sense of the friendships that form at Automattic, which are unlike any I’ve had at past jobs (however much I genuinely like many of my past coworkers).

Put enough smart, compassionate, passionate people together in a company and great things happen. This is why Automattic is a great place to work. Scott touches on the fact and illustrates it in his portrayal of how his team was built and how they bonded and grew. I don’t think there’s a recipe for making a great distributed company, or if there is, it’s something vague like “use great ingredients,” which doesn’t make for a highly marketable business book.

If I weren’t an Automattic insider, I don’t know honestly whether I would have enjoyed Scott’s book or not. Chances are that I would have found it fairly interesting to read some of the stories he tells about individuals and gatherings. Chances are that I would have found some of the few prescriptions (e.g. “hire great people” and “set good priorities”) pretty disappointing, if inevitable and actually correct.

Read the book if you’re curious about Automattic and how we work, and I imagine you’ll find it interesting. If you’re looking for a cure-all for how to build a company, you’re probably doing it wrong to begin with, though maybe there’s something useful in Scott’s book at least in its portrayal of how one company has had great success with the distributed model. I don’t have enough distance from the subject matter to say much else, other than that Automattic is hiring.

Using xdebug with wp-cli

Sometimes when you want to profile something in WordPress using xdebug, it’s not quite as straightforward as just enabling the tool in php.ini and passing a query string parameter. Say for example that you’re wanting to test how expensive it is to delete a term in WordPress. Well, you can load the term page with the query string parameter in place, but then you still wind up posting data without the query string parameter. You have a few options that I know of:

  1. Turn on xdebug for every request and figure out which cachegrind file contains the bits you actually want to profile.
  2. Hack the code to add the query string to your post.
  3. Write a cookie that xdebug can use in place of the query string variable.

None of these options especially appeal to me. They just seem clumsy.

I’ve used wp-cli more and more lately to interact with WordPress installs. And of course wp-cli has commands for interacting with terms. So it’d be neat to be able to profile wp-cli commands using xdebug. Luckily, it turns out to be pretty easy to do.

First, get xdebug and wp-cli set up. Links above will point you to documentation for doing so. When I set xdebug up, the extension was added to apache’s php config but not to the cli version of php.ini, so I had to copy the relevant line (extension=/path/to/ from one php.ini to the other.

Now you just have to add the -dxdebug.profiler_enable=1 option to your call to php at the command line. With wp-cli, you’re not calling php directly at the command line, though, so you have to figure out how to get the option passed through to the actual call. It turns out that the bash script that wraps wp-cli has a handy argument named $WP_CLI_PHP_ARGS that you can use to pass php arguments.

So if you always want to use xdebug with wp-cli, you can just do something like this in your .bash_profile:

export WP_CLI_PHP_ARGS=-dxdebug.profiler_enable=1

But maybe you don’t always want to profile wp-cli. Doing so slows operations down a little, and it generates pretty big cachegrind files, especially for complex or long-running operations (for example, a simple wp term delete command that takes around 2 seconds was generating 5MB cachegrind files for me). To run xdebug with wp-cli only when I really wanted to and without having to remember to set or unset $WP_CLI_PHP_ARGS when I wanted to toggle, I just added these lines to my .bash_profile:

alias wp="export WP_CLI_PHP_ARGS=; $HOME/.wp-cli/bin/wp"
alias wpd="export WP_CLI_PHP_ARGS=-dxdebug.profiler_enable=1; $HOME/.wp-cli/bin/wp"

Now, if I want to generate cachegrind files to profile, I execute wpd instead of wp, and life is good.

wp make-wxr

As part of my day job, I’ve lately been looking at trying to improve the performance of WXR imports into This has meant, so far, lots of testing and profiling of code, and it’s meant my wanting to be able to generate export files that meet particular criteria.

For example, one useful test is to repeatedly import a file that contains 1,000 posts so that you wind up with a benchmark for how long it takes on average to pull in that many posts (so that you can try to make that number consistently lower). Not everybody has a test site with exactly 1,000 posts in it, and it’s sure no fun to manually generate that test data.

For another example, say you’re trying to understand what impact taxonomies have on import sluggishness. The WXR file lists tags and categories near the top of the file and imports them all at the beginning of the process. Then it associates terms with posts as it imports the posts later. In order to understand how the taxonomy import performs, it’d be useful to have a WXR file with exactly 500 tags for that initial import, with a few randomly assigned to the posts.

And say you wanted to learn how comments get bogged down. It’d be handy to be able to easily import a single post that had a great many comments, or to import many posts with either few or many comments each.

Enter make-wxr, a wp-cli command I wrote to help me generate just these sorts of WXR files on demand. Now, by typing a simple command into my terminal, I can instantly have a reasonably customized WXR file for testing various trouble spots in the WordPress importer.

After some initial skepticism, I only recently started using wp-cli as part of a big data migration, and now I’m a pretty big fan of the tool. My little command here is just a brand new baby, conceived and born within the last couple of hours. I already have some ideas for improvements (though probably not much time to implement them, since the itch I was scratching by writing this is now scratched). If you’re a developer who works with debugging WordPress with data of varying sizes and characteristics, maybe the new command will be useful. (If you’re a theme developer, you should use the standard WXR file, since it covers lots of test cases like long titles, menus, etc.)