INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

PIPPIN: Welcome back to Episode 79 of Apply Filters. Today Brad and I are going to go over some more listener questions. We’ve been getting quite a few from everybody. Thank you all for submitting them via Twitter and email. If you have any questions that you would like to submit, you can go to our website at ApplyFilters.fm. There’s a form there to submit your question, or you can reach out to us in any way that you know how to, whether it’s Twitter, email, other websites, et cetera. We love to get your questions.

We’ve got quite a few to go over today, and we will try to get to all of them. If we don’t, then we’ve got more episodes coming. Brad, do you want to take us away with the first one?

BRAD: The first question is from Darren Spence. He asks, “What is your least favorite part of developing for WordPress and why?” Huh.

PIPPIN: Plugins.

BRAD: I think for — yeah. What? Isn’t that your whole business?

PIPPIN: Yes, sir. Let me expand on that a little bit.

BRAD: Okay.

PIPPIN: Okay, so I think one of the most awesome things about the WordPress industry, world, community, whatever you want to call it today is the fact that we have such a thriving plugin ecosystem. There are 50,000-plus plugins that do anything and everything from full blown solutions that transform your website to little tiny things that put quotes on a page. There’s a plugin for just about anything, and anybody can get into building plugins. It’s a free for all. You can — you have a plugin you want to build, build it. You can release it for free. WordPress.org provides a great infrastructure from which to do that. It gives you an opportunity to put it in front of people and find an audience for it.

It’s obviously been successful for us, as both you and I, Brad, have been able to build successful companies on top of the WordPress plugin industry. But because of the success, it is also sometimes super painful to build plugins within WordPress and build them reliably so that they always work. I mean I think if you look into any commercial plugin or theme or any WordPress business, their biggest support burden is probably people having problems on their site using your plugin, your theme, et cetera. And a lot of the time it’s because of some kind of conflict with another plugin, whether it is a, like, PHP error, if it is notices from another plugin, or if it’s simply two plugin clashing in their design or what their outputting on the front of the page.

Basically, it’s an uncontrolled environment, and sometimes, depending on the day, sometimes it is so brutal I want to walk away. We’re like, “Why do we do this?” But most of the time — I mean most of the time I genuinely enjoyed it. But if you could think about the difference between building products, free or commercial, in a controlled environment, think of like a SaaS, versus building in a free for all where you never would know what the environmental variables are, the latter is far more difficult and painful for a lot of obvious reasons. That’s my least favorite part.

BRAD: Yeah. I think plugins are like your most favorite part and the least favorite part at the same time. You know?

PIPPIN: Yeah, absolutely.

BRAD: Yeah. It’s like with great power comes great responsibility. Sometimes people don’t get the last part right.

PIPPIN: Yeah.

BRAD: The responsibility part.

PIPPIN: Well, and I think that it’s so common because there are so many different developers out there and it’s so easy to release a plugin. Sometimes because it’s so easy you get a lot of plugins that are released. We see this on the WordPress.org plugin repository every single day in plugin submissions. A lot of people are building plugins that I don’t want to say that they have no business building plugins because I believe everybody has the opportunity, but they simply don’t have the experience to know what they’re doing is problematic because this is the first time they’ve ever released it.

It’s a trial by fire, but it means that there’s thousands of those where somebody just builds a little thing that was fun and they released it. But then somebody else came along and installed it without knowing that this thing is garbage on the inside. Not necessarily by intention, but maybe lack of experience. Then that causes problems.

BRAD: This is a whole other kettle of fish, probably. I’m opening up a can of worms here. Do you think that the WordPress.org repo should be more — either it should, like, identify plugins that are — I don’t know. Somehow identify the ones or highlight the fact that certain plugins aren’t following the rules or best practices or something. I don’t know. Would that help?

PIPPIN: It’s tricky.

BRAD: Maybe not even — on the, like, extreme end of that, maybe like not even let them into WordPress.org and say, you know, go on GitHub until you get better. That’s the extreme end.

PIPPIN: Yeah.

BRAD: I’m not saying I’m for it.

PIPPIN: I can see the positives of that. The official .org policy is, basically, look, anybody deserves the right of being able to release a plugin here. We are not to judge you how well you write your plugin. Yes, there are things that are disallowed. I mean for example you can’t put a fatal error in your plugin. That’s going to be rejected. Ideally it doesn’t throw PHP notices. Ideally it uses proper prefixing and/or name spacing. As long as you do all of those things, like, the rest of the quality of your plugin is not for us to judge. That’s the general rule that we go with.

BRAD: Anyways, I guess we’ll leave it at that and not open the kettle.

PIPPIN: What’s your least favorite part?

BRAD: I’m probably going to say, like, so this is my favorite part. Again, it’s like a favorite part and a least favorite part at the same time. It’s backwards compatibility. You know having to support PHP 5.2 still is pretty painful for WordPress developers, I think. Not being able to use a lot of the features and even PHP 5.3, which is, you know, ten years old now, that’s pretty painful. You can’t use name spaces.

We covered all of the things that we would get as soon as we’re able to draw up support for PHP 5.2. We covered that in a previous episode. We’ll link that up in the show notes, the previous episode that we covered that in.

I think another thing was closures, so being able to write anonymous functions would be something that we would gain by dropping 5.2 support. Just all those things, I think, just make it less fun to develop for WordPress, right? I’m certainly not the first person to say that. I think it’s a pretty popular opinion, right?

Like I said, it’s also one of the best parts about WordPress that it just works, and it doesn’t break for people. I guess I said backwards compatibility, but that’s not really backwards compatibility, right? That’s support for PHP 5.2, old versions of PHP.

PIPPIN: But that is coming from a commitment to backwards compatibility.

BRAD: Yes. Yeah. I still like backwards compatibility. I mean I wouldn’t say that’s one of my least favorite parts. I kind of like the challenge of trying to build something new, but still works for anyone that does it the old way kind of thing, you know, and then deprecating things. It’s just — I feel like that’s just the responsible way of doing development. I kind of like backwards compatibility, but I’m not opposed to, you know, breaking it at some point.

PIPPIN: Sure.

BRAD: Where it makes sense. Anyways.

PIPPIN: Alrighty. Thank you, Darren, for the question. The next one comes from Josh Eby. He said, “I would like to get your thoughts on using Composer and Bower in terms of plugin development. I understand the benefits of Composer when working with a team or using it to manage an entire website, but how can it be used when developing a single plugin? Do you use auto loading for your classes in your WordPress plugins? Why or why not?”

There’s a couple of different questions in here. Do you want to start us off, Brad?

BRAD: Sure. Composer, why — so how do you use it when you’re developing a single plugin? Well, let’s give a concrete example. WP Offload S3, it uses the Amazon AWS or the AWS SKD, right? That’s part of the plugin. That’s a library that’s included in the plugin.

We use Composer to manage that, to manage that inclusion in the plugin. I can’t remember. What’s the Composer command line thing? Composer something.

PIPPIN: Composer update. Like if you want to update, if you want to update your libraries?

BRAD: Yeah. Whatever. Your Composer file that has the version numbers in it, you just change the version number, do a Composer update, and it just updates it. Commit that to Git. Commit your Composer file to Git and away you go. I mean that’s basically how we use it in our plugin. Do you guys do something similar, Pippin?

PIPPIN: We do, not in all of our plugins, but some of them. One of the main examples would be like our Stripe payment gateway, both for Restrict Content Pro and Easy Digital Downloads. Those both rely on the Stripe PHP SDK that they provide, and so we have that set up with Composer. Any time that we push out a new update, we can just run Composer update and it goes ahead and pulls in the latest SDK from Stripe and sets up the auto loader for it and it works great. That’s the main time that we use it.

We have used it before for other kinds of dependencies, say like if we have one of our own shared libraries that we use across plugins. We’ve used it for pulling those in, pulling sub-modules in before, but pretty rarely. Honestly, we don’t use it very often. We do have some–

BRAD: What about for unit tests? I think we use it for that as well. When the unit tests run, I think Composer runs as well.

PIPPIN: Well, we do have it set up so it pulls in, like, the latest version of WordPress, the latest version of….

BRAD: Right.

PIPPIN: –from GitHub, et cetera. That is all inside of our Travis config for Travis CI.

BRAD: Oh, okay.

PIPPIN: But in terms of the rest of, like, using it to manage our plugins, we don’t use it very much.

BRAD: Yeah, so it is composer.json.

PIPPIN: Yeah.

BRAD: I was … my instinct was right.

PIPPIN: In terms of Bower, I’ve never used Bower before.

BRAD: Oh, yeah.

PIPPIN: I’ve never used it. I can’t really answer much on that. I know it’s another package manager. I know a lot of people that do use it, but I couldn’t given any answer on to how to use it or what’s the best way to use it.

BRAD: Do you use auto loading for your classes in your WordPress plugins? Why or why not?

PIPPIN: Only when it’s part of a Composer install. Like with the Stripe API for example, whenever you do Composer update, it actually pulls in the latest version. That then all we have to do is load one Stripe PHP file, which then has an auto loader inside of it for the rest of the SDK. But that’s the only time. We have never built an auto loader into any of our plugins.

BRAD: Right. Any reason for that, or is it just you just never bothered?

PIPPIN: Originally it was because of PHP 5.2 support. I mean, yes, we could build like a pseudo auto loader, but like a true auto loader, we’ve never done. I think, honestly, it’s just left over from not doing it for old PHP versions, and we just haven’t adapted to moving in that direction. It has never been that much of a need. There are a lot of things that we can focus on and that we can spend a lot of time and effort on, and auto loading has never been a priority. If you have a great reason for why we should, I’d love to hear it.

BRAD: Yeah. I mean I guess the argument for doing it is so that you’re not loading unnecessary files into memory, right? You’re not making PHP do extra work for nothing, you know. That’s probably the argument, but I don’t know. When you’re talking about a plugin, you know, loading a few extra files, is it really worth all the overhead of adding auto loading for that, right?

PIPPIN: I have not yet been convinced it is.

BRAD: Yeah.

PIPPIN: If somebody has a case or an example of why it is or a different example of why there’s a significant advantage to it, please do share.

BRAD: Yeah. I like auto loading. I’ve written some auto loading. I wrote the one for our website. Our website does some auto loading. I hate having requires, like a giant block of requires sitting in a functions.php file. It just looks funny to be just requiring that many files at once. And a lot of times they’re not even necessary. They’re not even going to be used in this particular request, right? I don’t think we do it for most of our plugins either. Yeah, it’s probably something that we should, we should eventually get to.

The next question comes from Theron, and he says — he has some API related questions and he asks, “Should new plugins use the api to insert new post or wp_insert?

PIPPIN: I would assume this is asking whether we should use the REST API and the creation endpoints through that to create new posts, or should we use things like wp_insert_post?

BRAD: Right. Right. That’s what I get as well.

PIPPIN: I would think it’s really going to depend on the context. I mean if you are running a process inside of PHP, you use wp_insert_post because I don’t see any reason to fire off a remote request to the same API when you already have full access to, say, wp_insert_post and the rest of the database classes. If, however, you are in the context of a front-end request and you want to do it via JavaScript, absolutely use the REST API. If you are doing it, say, between applications so you have one WordPress install and then you have another install, whether it’s WordPress or a different one, and you need to create content between them: REST API. That’s one of the things that it’s built for. But inside of the context of, like, within your plugin’s own PHP files, I don’t see why we’d use the REST API.

BRAD: I completely agree with that.

PIPPIN: All right. This next one comes from Scott Fennell. He says, “I’m working on speeding up our admin-ajax calls. We have many, many plugins, most of which are probably hogging resources. However, I’m having trouble identifying which ones are the worst offenders, since it’s difficult to see a meaningful difference when we’re talking about a hundred milliseconds here or there. Any suggestions to debug this? I understand how to log which functions are calling admin-ajax, but what I want to get a few on is slightly different. Which functions are hooked into the hooks that fire when admin-ajax runs! You see the difference? Stuff like admin_init, etc.”

How do you track down performance problems inside of ajax and figure out which functions are tied into admin-ajax hooks?

BRAD: Right. Probably what I would do is probably the wrong thing. I think what I’ve traditionally done–

PIPPIN: Does it work?

BRAD: Yeah, but probably poorly. I mean there’s probably some really good diagnostic tools out there like Query Monitor would probably be one that would work well for this, right? Have you used Query Monitor, Pippin?

PIPPIN: I use it on every single one of my sites all the time.

BRAD: Right. Would it work for this scenario?

PIPPIN: Possibly. It’s going to depend. You’re going to be able to see, say, like during an admin_init request or like any page load in the admin which hooks are in there and what kind of performance you’re seeing, but those may or may not have the same impact as they do inside of an admin-ajax request.

Let me give you an example of something that we recently ran into that I think can apply here. Now in our case it wasn’t with admin-ajax. It was actually with wp-cron, but the same methods would work. We were having a site that it wasn’t sending emails any more. Well, it wasn’t sending a particular set of emails.

We had these emails that were supposed to send automatically, say, one week before a subscription is due to process a renewal payment. But these emails weren’t getting sent. They used to be sent, and then one day they just stop. We couldn’t find any explanation for why. There was no error logs. There’s no errors logged inside of the error logs. There was nothing that we could find.

It didn’t matter whether all the other plugins were deactivated or not. Like if we had EDD running and, in this case, Recurring Payments plugin and a software licensing plugin, just three plugins, they wouldn’t work, and we didn’t know why. And this is a site that had been sending these emails fine for years.

I eventually started doing some digging, and I figured out that if I deactivated one of our own plugins, in this case Software Licensing, the emails from Recurring Payments would work fine. I thought, huh. Okay, so that means that you’ve got some kind of overlap. I started looking into all of the things that they both did related to cron, and I found two of them.

It turns out that there was one. For example, our software licensing would run a daily cron job to look for keys that should be expired, and so it would go find expiring keys and mark them as expired. Then the Recurring Payments plugin would go look for subscriptions that were due to renew, and it would send a renewal notice. But if software licensing was active, the renewal payment notices wouldn’t get sent. But then I also figured out that if I swapped the order so that I made the Recurring Payments one run before the software licensing one, it worked fine. This told me that they were both hooking into a same action, and one of them was stomping out the other.

What I ended up discovering was basically that the software licensing plugin was doing a query that was pulling in too much data, and it was running out of memory silently during cron, and it was killing the rest, anything that was going to run later in that same cron job. The reason it happened was because the database on this site had just gotten too big and it couldn’t pull in the same amount of data as it used to be able to. There was too much data to pull that it would run out.

To fix it, we just made the query smaller and more efficient. That took care of the problem. Basically what we had to do and how we found it was going in and using things like the debug bar, actions and filters add-on, to see, during a request, what are all of the actions that are hooked in. Then you can say, okay, on admin_init here are all of the things that we have hooked. Then let’s say that we have this function that is not working. Now remove every action on admin_init there’s actually a function called remove_all_actions. It would deregister all of them, and then you could test the function again. Then if the function works, in this case sending emails, you know that something within the admin, something tied to admin_init is breaking.

Then we said, okay, we have all of these things on admin_init. Now what if we just remove 50% of them? Remove everything from this action to this action. Does it work? Good. That means that one of those in that first 50% is causing the problem. Now let’s remove them one at a time until we find the one that’s actually causing the problem. Now we can at least identify where the problem is coming from.

If you’re trying to debug performance in ajax, you could do something similar. First, look at everything that’s tying into admin_init or into one of the wp-ajax callbacks. Remove them all using remove_all_actions. See what kind of performance improvement you have. Then step through and remove them individually.

One of the issues why this is pretty tricky to do by just deactivating plugins is that there’s a lot of interaction sometimes between plugins. Just deactivating a plugin is not going to necessarily have the same effect as removing one hook that a plugin adds because you never know how many different interconnection points there are. That’s how I would do it.

I would try to step through those actions. I would find all the actions that are registered, and then I would remove all of them. See what kind of improvement you have. Add some back in. See what you get. Remove them one at a time. Eventually you’ll find the slow ones. I hope that kind of made sense.

BRAD: I think it made perfect sense. Just to recap though, your tool of choice for finding the bottlenecks with the hooks, what was that called again?

PIPPIN: It’s the debug bar add-on with actions and filters. There’s debug bar and then there’s debug bar actions and filters. What it allows you to easily do is go in and view all of the actions that are tied to the current page load. And so you can see all of the actions on admin_init, on WP, on plugins loaded, on shut down, all of them. And so then if you–

BRAD: Presumably how long each one takes to run. Is that right?

PIPPIN: It doesn’t, which is where it gets a little trickier. Especially it’s tricky during ajax because you’re not necessarily going to see the same thing during an ajax request as you will like in admin page load. But it still gives you a good starting point.

BRAD: Right. I think admin-ajax is a little trickier to debug with a UI tool like that because those calls are kind of happening in the background, right?

PIPPIN: Well, right, but that’s why — so with like the debug bar, the actions and filters add-on, what you’re starting with is getting a list of all the actions that are registered and then, say, remove them all. Fire an ajax request. See how it works. Add them all back in. Fire an ajax request. See how it works. Remove some of them. Repeat. Repeat. Repeat.

BRAD: Right. Not ideal.

PIPPIN: No, not ideal. A pain in the ass to do, but it does work.

BRAD: Yeah. I think Query Monitor does show you hooks as well. I was just taking a quick look at the screenshots they have. It does show them, but I’m not sure how useful — like I’m not sure if it shows the time that each one takes or anything. I’m not sure if you can get that information out of it. Maybe your way is the only way. Probably not. Yeah. Cool.

The next question comes from Bob Riley, and he says, “Hi guys, we are considering expanding our existing plugin business by purchasing a free plugin or paid plugin. Regarding a free plugin, how does one determine what a good price is? Is there a rule of thumb for price paid to be based on number of active users? Also, if one wished to purchase a paid plugin from another company, is there a general rule for what you would pay for one of those, perhaps a revenue multiplier? Finally, from a negotiation/tactics standpoint do you have any advice for how one would go about approaching a free plugin author or paid plugin creator – specifically how to open the conversation and then broach the topic of a specific offer price. Thanks guys and keep up the great work.”

Thanks for the questions, Bob. This is right up my alley. I’ve done — I have acquired a free plugin, but it was kind of — I kind of cheated a bit because it also had a commercial. There was a commercial version of it, so, you know, I got them as a package deal, so yeah.

PIPPIN: I think purchasing a free plugin is a little bit trickier than a paid one because just trying to find a value proposition.

BRAD: Exactly. What Bob was saying is maybe you could base the price on the number of active users, which I don’t think is quite right. I think what he means is the number of active installs, I guess, that WordPress.org is showing, which, I mean, that’s not a bad metric to go by. That’s one thing you could use in your consideration. Yeah, I mean it’s tough, man. To put a value on something that’s making no money is really tough.

PIPPIN: I think you have to really look and, number, one, like what does the plugin do? What is the potential of you, like, do you plan to take this free plugin and then make a commercial version of it? Do you want to upsell it to services, upsell…? What do you want to do with it?

Let’s just give a super famous example of Facebook buying Instagram for $1 billion. Instagram didn’t have revenue, but they paid $1 billion for it. Why? Well, they wanted the user base. They wanted the audience that came with it. If you have a plugin that has a massive number of installs and has a very large user base, there’s a lot of potential there. But how you choose to upsell them is going to be different from plugin to plugin.

If you want to come up with a price for you and something that you’re considering doing, think about, well, what do you realistically — as with any business purchase, like, what do you expect to be able to get back from your investment? I mean if you pay $5,000 for a plugin, are you doing this because that’s what the plugin author wants or because you genuinely believe that you can make $10,000 off the plugin?

BRAD: I think this boils down to, like, buying anything that doesn’t have a price tag on it. Like if you go — I don’t know. If you’re in the world and, like, you see a car you really like. You’re like, I wonder if I could get that guy to sell me that. You know? It’s going to depend on how willing that person is to part with their car, like how much they value their vehicle. Is it a rare vehicle, or did they put a lot of time into it that they feel like they have an emotional connection to it? All those things go into what the person that’s the potential seller, you know, what their value for that plugin or car is.

Then the other side of that is, like, how much the buyer is actually willing to pay. What’s their breaking point, right? At what point are they like, okay, that’s too much? I can’t. I’m walking away.

Clearly with your example, Pippin, like with the Instagram thing, clearly Facebook put a high value on what they thought it was worth, but also I’m sure the Instagram guys were not really looking to, you know, flip it quickly. They probably weren’t even interested in selling until Facebook waved a ton of money in front of their face, right?

PIPPIN: Yeah, I think that’s an example. Everything has a price.

BRAD: Yeah, exactly. Yeah.

PIPPIN: I think when it comes to purchasing a commercial plugin, something that already has revenue to back it up, it’s a little bit simpler, at least in terms of coming up with a price tag that makes sense for both people. I think a general rule of thumb that is typically considered a good price in most cases is a 1.5 multiplier of like the annual revenue. If a plugin makes $10,000 a year, $15,000 would typically be considered a good valuation.

Now, that’s a general rule of thumb because say for example you built a plugin last month and you made $20,000, and so you say, well, it’s probably going to make $200,000. Well, you made $20,000 that quickly. That says that you probably have a huge potential for growth if you can launch it and immediately do that. And so a 1.5 may not work there.

If you have a plugin that has been around for ten years and you know exactly what it’s made every single year, it’s a little easier to figure out. The history of the plugin is going to matter a lot here. For example, I sold one of my plugins, Easy Content Types, in February of last year. We ended up picking, I think, a 1.8 multiplier for the annual revenue, but we had four years of revenue to look at and to see. We know where its peak was. We know where its value was. We know what it’s done average from this time, and we know what it should be able to do. Whereas if your plugin is two months old, that’s a little trickier.

BRAD: Yeah, absolutely. I think there’s also lots of other factors at play here than just revenue.

PIPPIN: Oh, for sure.

BRAD: Even for commercial plugins. For example, if the plugin is five or six years old and has a history of solid revenue and even maybe recurring revenue, that’s a big plus. But also if the brand of the plugin has a reputation, I think that that makes it also stronger.

PIPPIN: But sometimes more difficult too.

BRAD: More difficult?

PIPPIN: For the buyer.

BRAD: To sell?

PIPPIN: Because let’s say, for example, that a plugin has a really strong reputation and a very strong brand. Then somebody wants to come in, but that somebody is, let’s just call them, an unknown. They’re not known within the community or the customer base and they buy it. Then they may be inheriting some of that brand reputation, but they are not coming in with a reputation themselves already.

BRAD: That’s true.

PIPPIN: I think we’ve definitely seen this happen a few times. It also goes the other way. If somebody with a strong reputation buys a plugin from somebody that does not have a strong reputation or brand, that greatly enhances their brand, I mean of the plugin being bought.

BRAD: Right. I think 1.5x is a good kind of baseline, I guess. But I think that can go up based on other factors as well.

PIPPIN: Yeah.

BRAD: Yeah, definitely.

PIPPIN: Yeah. I don’t think I would typically go down.

BRAD: No.

PIPPIN: There’s got to be some pretty good reasoning for going down.

BRAD: We sold our Web hosting company. I had a Web hosting company for several years, and we sold it. The kind of rule of thumb for that was 1x, 1x annual revenue. That was like the base that was just typical. Then you went up from there. I think it also depends what industry you’re in, what products you’re talking about, but yeah. I guess for plugins, I guess it would be 1.5 and up, I guess.

In terms of tactics to approach people, I would just advise to treat people like people. Ask them to have a conversation. You know, like just, I’d love to talk, you know, hear what you’ve been up to. I mean that’s what I’ve done in the past.

Don’t go into it, like, with a hard sell either, right? Be curious, like how are they doing, like what are their challenges. Maybe it’d be helpful–

PIPPIN: I think you need to show a genuine interest in not only the product, but of the team behind it, I mean, because most successful acquisitions, it’s not just of the product. It may be like an aqui-hire where you’re bringing the team over as well, whether that is one person or 20 people. You better care. You have to care about people if you want that to work.

Should we do one more and then wrap it up?

BRAD: Yes.

PIPPIN: All right, so Scott Paterson has asked us about hiring developers. He said, “I think it would be great if you did an episode on hiring developers, where to find them, managing developers and projects, how to determine salaries, and remote working agreements.”

Well, we don’t have time to do an entire episode today on it, but I think we could still touch on the subject. If you want to hear more on it, let us know, and we can certainly see about doing an in-depth topic on it at some point. Brad, you’ve hired quite a few developers. Do you have any quick tips on it?

BRAD: Yeah. I think we have quite different perspectives on this, Pippin, because I tend to have to, like, go out seeking the developers and advertising jobs whereas I think you have kind of hired from within, from within the EDD kind of contributor mostly, right?

PIPPIN: Mm-hmm.

BRAD: Is that accurate?

PIPPIN: Yeah, that’s generally pretty true.

BRAD: Yeah, so I’ll just speak from my perspective. Typically I’ll write a job post and put it on AuthenticJobs.com, which is kind of my go-to. I recently started experimenting with WeWorkRemotely.com, which is the job board that the Basecamp guys set up, I guess probably years ago now.

Then those applications come in just via email. I don’t make them submit any forms or anything. Then, yeah, we just kind of sort through them, or I sort through them. I read every application myself.

That’s something Matt Mullenweg still does for Automattic. He still reads all of the job applications to Automattic. I’ve heard him say that fairly recently as well. Every time he says it, and he’s still doing it, I’m still shocked because I can’t imagine, you know, how much work that must be. I mean he’s probably got really good systems in place to filter out the bad ones and stuff, but nonetheless he’s probably still reading a lot of applications.

That kind of inspires me to, you know, keep doing it as long as I can. Yeah, and just be really careful about who we bring onto the team. I think it’s super important.

PIPPIN: I think, just like how when you approach somebody to buy a part of their business or something they’ve created, people matter. In hiring, I think people matter probably more than just about anything, at least assuming that you have any kind of company that cares about people, which I cannot imagine how you could have a company that doesn’t care about people until maybe you get so large and whatever – a different subject.

For me one of the most important things is we have to work, like we have to be able to — I want to be able to sit in a room with you and work together. Now we work remotely. I mean we’re all across the world. But if I would not want to sit with you in the same car for five hours, or sit with you at dinner, or sit with you in an office and work, we’re not going to be compatible, and we’re not even going to have a discussion about hiring.

Number one, we have to be compatible on a personal level, which for that reason I rarely hire someone I don’t know. Well, I haven’t yet, with maybe one or two exceptions for, like, contract work. In a way, that is probably severely limiting because it makes our pool of potential people to hire much smaller.

But, at the same time, unlike five to ten years ago, the number of people that we can know, thanks to things like Twitter, Facebook, and various other online communication, the people that we know, our network of people that we have personal connections with, not necessarily that we know intimately, but we’ve had personal relations with, like, we’ve sat down and had dinner together. We’ve gone to conferences together. It’s actually much, much larger than, say, five years ago. We still have a large number of people to pull from, but if I’m looking to hire somebody as for a developer role, a support role, or any other role, I want to be able to know you personally.

My rule now is not only do I have to be, like, want to sit in a car with you for three hours, but I have to be okay and comfortable with inviting you to my house and sleeping in my house for a few days. If I’m not comfortable with that, there’s no way you’re coming to work on my team. That’s one rule that we have.

BRAD: I guess we could touch on one more thing in Scott’s question. Maybe it was the remote working agreements part. We have people in the U.K. We have people in the U.S. I’m here in Canada. We have other people in Canada. But that’s it, so it’s mainly we’re dealing with three different countries. Well, actually that’s not it. We’ve got one — well, one guy is in the Ukraine, but he’s also, you know, American, so he has bank accounts and stuff in the U.S., so technically he’s still in the U.S. when it comes to legal and financial things.

Anyway, we treat everyone as contractors, so everyone outside of Canada as contractors. Then people that are full time. The full-time contractors and then the people within Canada are employees. We have to pay employer taxes and all that kind of stuff for those people to be on the up-and-up, so that’s basically how we do it. The only other option would be to set up an entity in the other countries and then be able to treat those workers as employees, which is not realistic when you’re talking about just a handful of people.

PIPPIN: Right.

BRAD: The amount of overhead–

PIPPIN: Not at our scale, typically.

BRAD: Yeah. You have to be — I think the minimum, bare minimum would be ten people in one location to warrant that kind of setup. Even then that seems like probably more work than it’s worth. You have people outside the U.S., right, Pippin?

PIPPIN: Yes. We have two in Britain, one in Germany, one in Canada, two in New Zealand, and so we have a pretty similar setup where if you are in the U.S., we legally classify you as an employee, typically. In terms of, like, payroll taxes, those are all paid directly out of the company. Things like that. Report directly to the IRS, et cetera. If you live international, then you are, like, in terms of as far as the IRS is concerned you are a contractor. We still give you the same employee privileges. You’re still considered an employee of the company. It’s only on paperwork because, yeah, that’s just the way that that we do it.

BRAD: Right. Interesting. I’ve struggled with this a little bit. For example, vacation time. We recently reshuffled things a little bit with the guys in the U.K. because they got a little worried that it wouldn’t look to the government like they were actually a contractor if they were getting paid the exact same amount every month and had vacation time. That the government would start to classify them as an employee and, you know, turn things upside down on us.

We basically took away vacation and then just increased their pay. When they take a day off, they don’t get paid for that day, but they just make more every day that they do work so that, like when they submit an invoice, it just looks a little bit more like they’re a contractor. We still keep track of their vacation time to make sure that they’re, you know, taking enough time off and stuff like that.

The world is just not set up for this yet. We’re just kind of like making it up as we go and doing our best, you know.

PIPPIN: It’s the way I run my company. Make it up as we go and fake it until you make it.

BRAD: Yeah, I guess so. All right. We should probably wrap it up.

PIPPIN: I think we could probably — there’s a lot more we could touch on hiring developers, especially remote team members. There’s a whole lot of interesting nuances about it, and so maybe we’ll touch it again soon. Maybe to pique anybody’s interest, I think figuring out salaries between countries is really fascinating when you look into, like, where a company is located versus where an employee is located and taking all of those different things into account. Really fascinating and sometimes philosophically gray areas.

BRAD: Oh, yeah.

PIPPIN: But that’s for another episode.

BRAD: Oh, man, yeah. I’d love to talk about that, actually, because I’ve really struggled with that in the past. Maybe next episode we’ll dig into that one.

PIPPIN: Sounds good. Well, if anybody has any other subjects you would like to hear about, get in touch with us. Send them in from the website at ApplyFilters.fm. Whether it’s a simple question that we can answer in a minute or two or if it’s a really in-depth topic that you would like to cover an entire episode on, let us know. We’d love to hear your feedback.

BRAD: Awesome. Talk to you next time.

PIPPIN: All right. Cheers, folks.