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.


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.

Upgrading old WXR files with wp-cli

I recently had cause to try to import an old WordPress WXR export file into a more recent version of WordPress. There are some simple differences in the way the old files and the new files are formatted that keep this from working. The usual rigamarole for getting around this is to install a throwaway copy of the version of WordPress that the export file was generated with, import the file, and upgrade WordPress until you’re at the latest version. Then you export and the WXR is updated. That’s kind of painful and lame, though.

So, riding the wave of my recent fervor for wp-cli, I made a wp-cli command for doing the conversion. It’s called… convert-wxr.

Usage looks like this:

wp-cli --file=file-to-covert.wxr --outfile=converted-file.wxr

If you don’t specify an outfile, it just spews to the screen (you can redirect output to a file). It won’t clobber an existing file.

The script just does some simple regular expression and string replacements based on the differences I found between older and more recent WXR files. It’s entirely possible I missed some differences, but the conversions I tested seem to work well enough.

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


I’ve just returned from meeting up with some coworkers in Lisbon, Portugal. It’s the prettiest city I’ve been to. I loved how the terra cotta roofs contrasted with the colors of the buildings, the greenery, and the sky.

It’s a pretty easy city to get around in. Taxis are surprisingly cheap and the drivers actually give you change, though they often seem not to know where your desired location is until they have an epiphany partway there. You tell or show them the address and they more often than not give you a long puzzled look. Occasionally they’ll consult a book that helps them out. Then they tear ass toward your destination, whipping around the streets, tailgating trolleys, and narrowly avoiding pedestrians. In spite of apparent confusion and the distinct impression that the drivers are just wandering to find the place sometimes, the fares still wind up being cheap. The ride is also generally somewhat Mr. Toad’s Wild Ride-ish.

We went to the aquarium, which was pretty nice but which I didn’t bother to take many photos of thanks to lighting and the sort of universality of aquariums. We also went to the Castle of São Jorge, which was really neat. After wrapping up at the castle, several of us wandered the old city for a few hours. Near the end of the trip, I stopped by the Estrela Basilica just a couple of blocks from our house, but I took no pictures of the interior because it was quiet and being an obnoxious American tourist there felt inappropriate. It was beautiful inside but also seemed somehow more used, more dingy, than some similar buildings I’ve visited.

We ate at several pretty good restaurants that were mostly reasonably priced. Cod is the thing to get if you’re into fish, though I heard from a native that they import most of their cod from Norway. Wine is absurdly cheap and pretty good. We bought plenty of bottles of utterly decent wine for two to three Euro each (less than four bucks).

WordCamp Nashville

A couple of months ago, I attended the two-day WordCamp in Atlanta, and when I learned a few weeks ago that there was to be a WordCamp in Nashville (about three hours from home), I snapped up a ticket. This was Nashville’s first WordCamp and seemed to be a great success. I had signed up to help staff a happiness bar in the afternoon and so wound up attending only two sessions. My notes follow.

The Blank Screen: Overcoming Fear of ‘Pressing from Scratch’, presented by Mitch Canter.

I had actually heard of Mitch before via a local contact and was curious what I might learn from him about starting a WordPress theme from scratch, something I’ve never really done (being not at all gifted with design talents). Although he had some slides and some high points he wanted to hit, Mitch offered a pretty informal, somewhat discussion-driven format, and it worked well. He was funny and engaging, a very capable speaker. The high points I jotted down from the session:

  • Designers have to work with their developers before putting a design on the screen; else you wind up making beautiful things that the coder may not be able to implement.
  • If you’re working with the 960 grid system (something I didn’t know about), check out, which gives you Photoshop templates for creating layouts more efficiently.
  • Establish a process/framework to speed up dev, to build a comfortable flow for your work, etc. That is, condense repeat actions into a formal set of processes/templates/etc. so that you’re not actually starting from scratch each time you start from scratch.
  • Mitch tends to start with static html pages (with lorem ipsum type content) to do most of the design outside of WordPress, and then he goes back in and substitutes in loop functions just before he pushes content to the client’s servers. I asked about local dev environments like XAMPP, and he said he also uses/advocates those. As XAMPP/etc. may be a little more technical than some designers are able to deal with, the static build may be reasonable for some.
  • He mentioned using github to deploy changes to his parent theme framework, though it wasn’t clear to me why that was terribly significant. I think he uses github over the core plugin/theme repository because he has some MIT-licensed components.

Child Theme Frameworks, presented by Ryan Green.

Ryan is the head of UX+UI at cjAdvertising in Nashville. He gave a much more structured talk than Mitch, and it was full of good information for any new to the notion of child themes. After defining UX (sort of the nexus of design, interactions, usability, and analytics), he made sure the room understood what he meant by a child theme and a framework and then jumped into the advantages and disadvantages of using a framework. Advantages:

  • You start with a bulletproof theme.
  • If you break something with your child theme, you just delete/disable it and still keep all the core functionality of the parent while sorting out what went wrong. In other words, it’s sort of like working with a net.
  • You can roll multiple themes from one parent. He gave the example of a seasonal theme for a given site. If you have your core functionality in a parent theme framework, then you can just override the styles, etc., in the child themes and swap those out easily with little risk to how the site actually works. This is obviously an advantage if you do lots of work within a vertical market that tends to require rubber-stamped functionality but varying designs.
  • If you’re using as your parent theme one that’s updated via the core themes repository, you can keep up to date easily with security patches at a reduced risk to the site’s functionality. One nasty alternative is to hack your parent theme locally, in which case updating becomes a pain and exposes your site to vulnerabilities. Extending a parent theme lets you keep up with updates while managing your changes to the theme within the child.
  • You may need to know less PHP if you go this route. That is, given a parent theme that has all the functionality you want, your child theme can simply replace the style sheet, which lowers the barrier to entry for designers who aren’t comfortable wrangling PHP code.
  • Visual design principles can be baked in. So if you find yourself working always within the 960 grid system, you choose a framework that adheres to the 960 principles and save yourself some grunt work.

Now for the disadvantages:

  • You can get locked into a nightmare theme. So maybe you’ve picked a dud but don’t know it until you’re halfway through a project whose core functionality depends on the theme you’ve chosen. Bummer.
  • If you choose a minimalist parent theme, you have to do more design work. (This struck me not as a disadvantage of the practice of using theme frameworks but more as a caution to choose your parent theme wisely.)
  • If you choose the wrong parent theme, you can be bitten by code bloat. That is, some themes that try to be all things to all people add so much extra stuff that they might not really be suitable for your purposes, while adding surface area for vulnerability and performance issues. This, again, is more a caution to choose wisely than a compelling reason to consider rolling a custom theme for each site or rubber-stamping an established theme rather than making a child theme.

Next, he talked about what makes a good theme framework:

  • It respects the grid (has consistent spacing, uses a common grid system, has a clear visual hierarchy among elements).
  • It uses modern code like HTML5, CSS3, jQuery, etc.).
  • It’s easily remodeled. By this he meant that widget areas, nav areas, and so forth can be easily moved around and tweaked. These themes use what Ryan called the “House-Hunters approach” — the theme is essentially move-in ready.
  • It demonstrates a concern for usability; it’s responsive, IA-friendly, works well for those with disabilities.

A few frameworks he’s used:

  • Genesis
  • Thematic
  • Thesis
  • Stumblr
  • Others: Skeleton, Starkers, Whiteboard, Roots, Bones

I’m too lazy to find links for them all. Advantages these generally had in common were that they tended to already have lots of pre-made child themes you could riff on and they’re tried and tested by thousands of users. Thematic (by Automattic) makes it easy to change layout. Genesis has a standard top-nav layout and is generally more corporate out of the box. Thesis has great typography and is optimized for fast load time. Stumblr has minimal configuration options, a Tumblr-style layout, and is very content-focused. He didn’t mention the _s theme recently published by the Automattic theme team, though I didn’t ask  why; maybe it’s too new for him to have looked at much, or too bare-bones (by design) to be generally useful to designers who need a more fleshed-out template for a starting point.

I didn’t jot down any of the questions Ryan fielded, but there were several, and I thought this was a very good session overall — not terribly advanced stuff but a great overview for designers who may not have had much exposure to the concept of child theme frameworks.

The Afternoon

I spent my afternoon in a little cafe area between the rooms designated for the user track and the developer track. Ostensibly I was there to staff a happiness bar to field any questions people had about WordPress, but nobody asked me any questions. This may have been a sign that the sessions were really well suited to the audience, that people were reluctant to miss a session to ask anybody anything.

I did sit and chat for a good long time with Rami Habal, VP of Product with event sponsor wordnik, which I’m going to test drive a bit because it looks neat. We chatted natural language processing, he demo’d a WordPress plugin they’re working on in beta, and it even came out that he had been a Flock user. I also chatted with one Cindy Wall, who works with the Belcourt theater in Nashville and turns out to be a Moby-Dick enthusiast like me. I actually shoehorned myself into a discussion by these two by showing off my goofy little Moby-Dick word frequency analysis site, which married some of the sorts of things wordnik does with some of the literary stuff Cindy had been talking about. And, oddly enough, it turned out that Cindy had run across a blog of mine in her recent searches pertaining to Moby-Dick. So it turned out to be a small world in Nashville this weekend.


This was the third WordCamp I’ve attended, and in terms of sessions, it was for me the best so far, even though I attended only two. Sessions at the other two have been more mixed for me in terms of quality, but both I attended this weekend were very solid.

Registration went smoothly for me. It seemed like a few people slipped into the first session a little late, but that may well have been as result of their own tardiness and not of any registration snafu. The shirts and badge/schedule thingies looked great. WPEngine provided little swag bags including a pretty nice little notebook that I actually used to take my notes. There were free muffins from a local eatery and free coffee from I know not where. You had to fend for yourself for lunch, but there were a couple of restaurants within very reasonable walking distance, and the organizers had negotiated coupons to get a discount on lunch. The barbecue joint does catering, so I did wonder why they hadn’t just had lunch brought in. I suspect the venue didn’t allow food in the classrooms we used, or perhaps adding catering to all the other organizational hurdles for a first-time WordCamp was just too much. This isn’t a gripe — just something I wondered about.

With just two concurrent sessions at any given time, we used two classrooms, and it turned out that the developer track was a lot more popular than anticipated, so the developer room was standing-room only for both sessions I attended. This wasn’t a bad development, and it’s certainly something the organizers will learn from.

Even though I didn’t get to attend many sessions, I had fun at this WordCamp. I think Nashville had a great first time out, and I’ll look forward to going back next year.