November 28, 2014

Apply Filters
Apply Filters
Episode 31 - Challenges for Lead Developers Leading Businesses

In episode 31 we discuss some of the challenges that are faced by lead developers of projects that are also leading the business around their software.

This episode was sponsored by WP Ninjas, the creators of Ninja Demo and the highly popular Ninja Forms plugin.


Show Notes:

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 Apply Filters. My name is Pippin Williamson, and with me is my cohost, as usual, Brad Touesnard. Today, we are going to talk about some of the roles as a lead developer that is also leading a business, so some of the difficulties that we run into, some of the challenges we have, tasks, et cetera.

Before we do that, we want to give a quick note to our sponsors WP Ninjas and their plugins Ninja Forms and Ninja Demo. You can check them out at

Before we get into the meat of the episode though, let’s mention really quickly some Black Friday and Cyber Monday deals. Brad, what do you got for us?

BRAD: Well, I’m just going to mention mine, but, yeah, we’re running 20% off Migrate DB Pro right now until Monday at midnight.

PIPPIN: Awesome!

BRAD: The coupon code will be in the show notes, but you can just do — so it’s BFCM2014 – Black Friday Cyber Monday 2014.


BRAD: Yep.

PIPPIN: We’ve got a couple deals going through EDD, Affiliate WP, and Pippins Plugins as well. For EDD, there’s 30% off any extension or theme purchase. The discount code is actually listed on the site, and that goes until Monday at midnight. And then Affiliate WP and Pippins Plugins are both 40% off for all plugin and membership purchases until Monday as well. Both those codes are also available on the site.

There are also some other really good deals I’ve seen floating around. Go to for membership and e-commerce deals. Then I know that WP Mayor wrote up a blog post with some roundups, and there are some other ones going around too. So if you have some plugins to purchase, this weekend is probably the time to do it.

BRAD: Yeah, definitely. We haven’t actually participated in any holiday deals or sales in the past, and I kind of just realized this time around that if you’re not part of the madness, then you just kind of fade to the background and no one pays attention to you.

PIPPIN: I’ve kind of flip-flopped. Sometimes — there were a couple years where I did a deal, like, every single weekend. Not every weekend. Every holiday, and then there are other times when I just didn’t do any. Now I’ve kind of decided there are specific holidays that I will always do. If you do it well, it can be pretty good for business.

BRAD: Yeah, yeah. I’m hoping so.

PIPPIN: Yeah, hoping.

BRAD: Yeah. I think, like I said, it’s worth being part of it.

PIPPIN: Certainly.

BRAD: I think people are out there looking for deals, and if they find that you’re not promoting any, it can be disappointing for them.


BRAD: So just throw something to there is kind of my new position on this.

PIPPIN: Yep. Let’s jump into this. We want to talk about kind of the role of lead developers in a business, especially when that lead developer is also leading the business. This is really kind of personal and applicable to both of us, for Brad and I, because it’s exactly what we’re doing every single day. We’re both the lead developers for projects, and we’re also the people leading the business. There are some challenges that that faces and that that brings up.

BRAD: Yeah.

PIPPIN: Brad, so you want to get us started with some of the first things?

BRAD: I don’t know. At the bootstrapping podcast I listen to and kind of some people that I read, most of them are really championing outsourcing, right? Outsource, outsource, outsource. Free yourself up to focus on the business, grow the business, and those kinds of things.

PIPPIN: Usually they’re talking about outsourcing the development, right?

BRAD: Not necessarily. They say everything, right? They say writing articles for your blog. They say obviously your accounting, your legal, and all that stuff needs to be outsourced. And a lot of them champion personal assistants or — What do they call them? — VAs, virtual assistants.


BRAD: Which I’ve contemplated in the past, but I always felt like it would be more work to manage a virtual assistant than just to get the little things done.

PIPPIN: Mm-hmm.

BRAD: Have you ever thought about that?

PIPPIN: I’ve always kind of had the same idea that it would take me more time to help get them going and have them have their day-to-day tasks going than it would be for me to it myself.

BRAD: Yeah.

PIPPIN: Now, I’ve come to realize that it’s probably just because I’ve never met the right person to be a VA for me.

BRAD: Right. A lot of them say that they just go on Odesk and, you know, go through 20 of them before they find somebody that’s worth having. But I think the way to do that is what’s called standard operating procedures, so having documents that basically step-by-step in painful detail how to do things, and then you just say, “I want this done. Here’s the document.” Then the next time you need it done, you just send them the document again and it’s repeatable.


BRAD: Yeah, I thought about doing that kind of stuff, but I feel like, for me, the best thing to hire for is development because I can evaluate a developer much better, and they can help me with these things as well, right? If you get a couple developers onboard, not only can they do the development and help you with that, but they can help you with these menial tasks that are your burden as well.

PIPPIN: Right. That’s definitely been a — I found that getting somebody to come on as a developer and as support is where I’ve had the most success with kind of outsourcing some of those tasks. But it was not necessarily easy. I’ve had a lot of different developers and support people that have worked with me and it’s actually been more difficult to have them onboard than not onboard.

BRAD: Yeah.

PIPPIN: And it was because they weren’t the right person.

BRAD: Right.

PIPPIN: Then finding the right person, then you realize, “Oh, this helps so much!”

BRAD: [Laughter] Yes!

PIPPIN: And for me —

BRAD: What are some of the pitfalls? When the people weren’t working out, why weren’t they working out for you?

PIPPIN: If you need day-to-day direction, you’re not the right person to work with me. I think some of that is because, in general, I’m a very driven person. I like to get things done and, if there’s a task that needs to be done, I try to make it happen. Maybe it’s just kind of a personal thing, but I don’t really like to see when somebody sits to the side and says, “Okay. What’s next? What should I work on?” If there is a large list of issues, whether we’re talking development issues or support tickets or anything, basically just stuff to work on, someone shouldn’t need direction in down time.

Now, obviously you can give people direction and say, “Hey, today I would like you to work on this. Today I would like you to do this.” But when they’re not being directed, you should be able to find work. You should be able to know something that you can do that’s going to progress the project or the company. And if you need to be told what to do in order to do something, you’re not the right fit.

BRAD: Right. Yeah, exactly. I mean that’s — yeah. You’ve just got to keep going, put people on trial, and see if they can manage themselves. If not, then cut them loose. It’s pretty much the approach that I’ve been taking. Obviously, before you put them on trial, you try to vet them as best you can from their GitHub profile and their profile and all that stuff to try to figure out are they a self-driven individual.

PIPPIN: Mm-hmm.

BRAD: But it’s not always easy to figure it out from just those things, right? Then there’s cultural fit and a whole other list of things that are really difficult to judge until you actually start working with the person.

PIPPIN: Right. Well, you just won’t know.

BRAD: Yeah, exactly. Bringing it back to kind of the focus of this talk, should we actually be hiring developers so that we no longer do development, because I’ve been struggling with that, that question whether I should stop doing development in the future, at any point, or should I continue just to do development because my developing is a big part of the business?

PIPPIN: Right.

BRAD: How do you feel about that?

PIPPIN: Well, it’s really tough. I know that, basically, so I lead the business, and if I step back and stop leading the business, the business dwindles. I’ve seen this happen too. One of the things that does have a dramatic affect on the success of the business is the progression of the development: fixing bugs, adding features, et cetera. And so it’s splitting my time between development and non-development can be challenging, and so, yeah, I can say, “Let’s hire a developer, and let’s get more of this stuff done.”

BRAD: Mm-hmm.

PIPPIN: But then am I taking myself too far away from development because I feel like I am most valuable in code.

BRAD: Right.

PIPPIN: That’s where my primary skill set is. That’s where I have the most to give to the company, to the products, et cetera. And so if I’m no longer coding, is the company going to suffer?

BRAD: Right.

PIPPIN: I honestly don’t know the answer to that.


BRAD: Right.

PIPPIN: I think it’s one that I have to acknowledge that, as the leader of the company, I have two choices, basically. I either find someone to replace me as the lead of the company and I spend most of my time in development, or not necessarily replace me, but help me with it. Two; I lead the company and step back in development.

BRAD: Sorry, you leave the company?

PIPPIN: No, lead.

BRAD: Lead, right.

PIPPIN: I either —

BRAD: Do what you’re doing now.

PIPPIN: — lead the company and take a lower role, lesser role in development, or I give up the control of the company to someone else or give up some of it and then spend more time in development.

BRAD: Right. Hmm.

PIPPIN: That’s kind of where I’m at right now.

BRAD: Yeah.

PIPPIN: Is trying to figure out that balance and figure out where we want to go with it, and that’s — right now, over the last six months, we’ve been talking with somebody coming on as a potential full-time developer. We have a lot of people that are doing support, and we have one guy that’s doing full-time support for EDD. But no one is doing full-time development aside from me. But I’m not really full-time development either because I’m leading the company.

BRAD: Right.

PIPPIN: But I’m talking with a developer now and have been for the last six months about bringing them on as a full-time developer and doing nothing but development.

BRAD: Right. Right, and you trust this developer so much, like, he’s pretty much — he could step in to your shoes and handle the development.

PIPPIN: Well, yeah. To put it this way, he’s the guy I go to when I have a problem I can’t solve.

BRAD: Right, right.

PIPPIN: Usually, as the lead developer — and this isn’t just me. This is just lead developers in general — we are usually the people that are handed the really hard problems. If you have a developer that’s working with you, or multiple developers, and they are having problems or they can’t solve an issue, they come to you and say, “Hey, can you help me?” In this case, he is the developer I go to when I need that help.

BRAD: Yeah, yeah.

PIPPIN: Yeah, yes, absolutely trust him.

BRAD: Right. It sounds like you’re kind of on that path to trying to hire someone to take over a lot of the judgment calls with regards to the code that you spend a lot of time on at the moment, like reviewing pull requests submitted by whoever that’s in your community.

PIPPIN: I don’t know if I would put it as giving up those decisions or the judgment calls.

BRAD: Okay.

PIPPIN: I think, instead, it’s the execution of those. Well, I mean, to some degree. There’s going to be a lot of times when that other person who is taking over a lot of the lead development will make the decision on: do we make this change, or how do we make it, or how do we fix this problem? A lot of times it’s not so much making the judgment call. It’s about actually writing the code after a decision has been made.

BRAD: Okay. Right.

PIPPIN: Sometimes that’s much harder than making the decision. Not always, but sometimes.

BRAD: Yeah. I find, though, it’s harder to find people that are good at making judgment calls than people that are good at coding.

PIPPIN: I think that’s an exact same problem with finding people that are self-driven.

BRAD: Right.

PIPPIN: Let’s say you’re hired to do support. You may be the person that can answer ticket after ticket after ticket when they’re assigned to you, but can you go find those tickets that needed answered? Can you go help those customers that haven’t already been given to you? I think that’s just as hard as a person to find as finding that person that can make those judgments about development.

BRAD: Right. Yeah.

PIPPIN: They’re really kind of the same kind of individual in just different areas.

BRAD: Yeah. I think my answer to the question, “Should the goal be for us to stop developing?” the people that are leading the company, should we stop developing eventually; I think the answer long-term is yes because eventually you want to hire someone who you can trust to make the calls, the judgment calls and do the project management stuff that you’re currently doing right now and make all of the right calls with regards to the code and the direction of the project. I think you can hire someone that will fill those shoes eventually, right?

PIPPIN: Absolutely.

BRAD: Long-term. You’re not going to find that person necessarily tomorrow, or we might find them, but they’re probably not going to be available. I’ve found all kinds of people that aren’t available.

PIPPIN: I’m going to disagree with you a little bit though.

BRAD: Okay.

PIPPIN: I’m going to disagree with you for me because I think this is going to vary for every single person, every project lead, every lead developer. For me, honestly, I think I could tell you; in the long run I’m not nearly as interested in running the business as I am about coding. And so, at some point I would like to stop running the business, or I would like to relinquish some of those controls and hand them over to someone else.

BRAD: Right.

PIPPIN: Not necessarily all of them, but at least some of them I’d like to share the load more. A lot of that is just from the mentality that some days I just want to sit back in my chair, not worry about anything except for where my syntax error is.

BRAD: Right.

PIPPIN: But there are definitely; I mean some people do want to just not worry about code. They just want to run the finances. They just want to run the business.

BRAD: That’s interesting though, what you just brought up, because you do see this in companies. For example, WP Engine founder Jason Cohen has gone from running the business to, he’s dropped to the CTO position, right?

PIPPIN: Right.

BRAD: He’s now the technical officer or whatever title it is.

PIPPIN: I think that’s a great example because I suspect that part of that move was, one, because they were growing massively and they had to have more people come onboard in order to handle the growth. But, two, I suspect some of that was based around where his skill sets were.

BRAD: Mm-hmm.

PIPPIN: He was probably not as good at leading the business as he was on the technical side of things.

BRAD: Right, or maybe he’s just —

PIPPIN: There’s another really good example.

BRAD: Maybe that’s just where he’s most valuable to the company, right?

PIPPIN: Right, and I think that’s what you really need to determine.

BRAD: Right.

PIPPIN: Let’s say that if I was to suddenly expand my business to 50 employees and maybe 3 executive officers in some form or other, where would I be most valuable at?

BRAD: Mm-hmm.

PIPPIN: Well, I would like to say in the code. I don’t know if that’s true because it really depends on, well, what other developers do you have working with you?

BRAD: Right.

PIPPIN: I’m much better at marketing than a couple of people that work with me. That doesn’t mean I’m great at marketing. So if there’s someone that comes to work with me and they are much better at something than I am, they should probably take a lead in that position.

BRAD: Right.

PIPPIN: I think that’s one of the balances you find when you’re growing a company.

BRAD: Hmm.

PIPPIN: There’s another really good example, and this will lead us into a subject that I think we want to cover, and that’s technical debt. One of the issues that we run into if we bring on more developers to help share the workload, if we outsource some of the development, et cetera, sometimes we get into issues where we have technical debt because we have maybe less than stellar code that’s gotten approved into a project.

BRAD: Yeah, and then it snowballs, right?

PIPPIN: Right.

BRAD: Bad code gets in, and then more bad code gets in. You might get a good developer working on the bad code, and he has no choice but to commit more bad code because bad code invites more bad code.

PIPPIN: Sometimes you just have to do it.

BRAD: Exactly.

PIPPIN: There’s a really good example of technical debt in the WordPress world. I hope he doesn’t hit me for bringing this up. WP eCommerce is a really good example of this. WP eCommerce, for anybody who doesn’t know, is actually one of the oldest plugins around for WordPress. When it was first committed to the repository, there were less than 4,000 plugins in the repo in total. Now there are over 40,000, to give you an idea of how long this plugin has been around.

This plugin was also around before custom post types of any of the normal tools that we would use when building a large-scale plugin, especially in e-commerce today. Because of that, and because of some less than awesome development practices early on, WP eCommerce has kind of suffered from some large technical debt. They’ve had some bad code sitting around that’s hurt them for a long time. And you can see that if you go to the review section of and go back a few pages. There were a lot of times when a developer would be working and trying to build a site on WP eCommerce, they’d find a problem because of some old technical debt they had.

Now, Justin Stanton, who is now the lead developer of WP eCommerce, has come in and he said, “Hey, let’s take the time to actually fix these. Let’s make it a good plugin again,” and it is. It is a really good plugin now. It’s awesome. I recently used it when integrating, doing a new feature for Affiliate WP.

But it’s a cool example here because it’s not just about technical debt, but Justin, who used to work only as the developer, like he was just the developer on the project, and he would be given a task, and he would work on it. Now he’s stepping up to become one of the leaders in the project, not just as a developer, but leading the business as well.

BRAD: Right.

PIPPIN: And that’s because they’ve found that he’s valuable in that.

BRAD: Right. Yeah, that’s awesome. I mean it’s great to see a project come back to life, kind of, or get kind of re-polished like WP eCommerce has been. I remember working with it years ago, and I remember it being very frustrating as a developer working with it.

PIPPIN: Right, and that’s a lot of what’s changed.

BRAD: Yeah.

PIPPIN: And some of it has changed just because Justin is a good developer, and he has been able to say, “Hey, let’s figure out how to fix this.” But two, because he’s also a good businessman, and he’s figured out how to fix it for users as well, not just the code problems.

BRAD: That’s awesome. How does this relate then? I guess this relates to the question that we’re asking ourselves, “Should we take ourselves as developers out of development roles?” Because if we just, if we outsource, if we outsource development and kind of leave it unchecked, we could end up with a ton of technical debt like this. Then we’d be forced to eventually tackle it because, if you don’t tackle it and you’re just constantly working against this awful code, you’re going to spiral into a depression probably. [Laughter]

PIPPIN: I ran into this recently, actually. We had an extension for EDD that we just kind of let it just go, and the original developer just, at the time, wasn’t that great. Knew how to write a whole lot of code, but wasn’t necessarily the most reliable code. But we kind of made the mistake of: It looks good on the surface. Let’s just go through with it. We’ll just let it go.

And it caused some pretty severe problems. And, unfortunately, caused a lot of technical debt too because, over the last year, we’ve been working to make it dramatically better. The developer that originally wrote it has progressed miles and miles and miles in their development skills and also what they understand of it. So they kind of went from being that developer that’s approving the kind of shotty code to somebody who is working to fix all of that original bad code. But, it was an issue because, as the owner, and as the person managing the business, we just let it go through.

BRAD: Right.

PIPPIN: And we were suffering those consequences.

BRAD: Right. Your example here brings up a really good, a really important issue here. Because we’re dealing with open source software here, and people are using WP eCommerce or Easy Digital Downloads, or whatever plugin, to build their site with, they’re really interacting with the code that’s been written in that plugin. Do you think this is different for closed source software or SASs? Do they have to worry about technical debt or code quality as much as we do with open source plugins?

PIPPIN: I think yes and no. Yes in the sense that if you have bad code or some technical debt that’s actually causing problems for the users of the software, obviously that’s going to affect you. But a lot of times technical debt doesn’t affect those people because people that can’t and users that don’t see the code because they’re just using the software, and if it works fine, it doesn’t really matter what it looks like behind the scenes. But if you have a developer that’s trying to build something on top of your software, they probably are digging into the code in order to figure out how to do something. That’s where it becomes problematic.

BRAD: Right. I guess it’s also problematic for whoever ends up working on that code in the future too because if you have to work on it, it’s going to suck, right? I’ve been in the situation before where I’ve inherited these massive code bases that have horrible code that’s just using legacy systems and all this stuff, and it’s painful, really painful. I used to work at a company, and that was the situation there, and I actually stuck around the company for two years, but only because I loved the people I was working with. If that weren’t a factor, if the people sucked, I would have been out of there, like, on day two.

PIPPIN: I remember a little bit of that with — before I was working full time on EDD and just plugin development in general, I worked as a contractor for an agency up in New York. We built mostly corporate websites, like little, tiny, micro sites for large corporate companies. The projects always kind of sucked. They were super boring. Their code was never nice. Sometimes we had to interact with their existing systems, and so we had to then deal with their code. But I loved the people I was working with, and that made it worth it.

BRAD: That’s interesting.

PIPPIN: I think it gets into the question of developer happiness is really important for the health of a project.

BRAD: Right, but it’s not just the code quality that makes developers happy.

PIPPIN: No, it’s not.

BRAD: It’s also the people they’re working with and collaborating with, right? I think you’re a great example of how. You’re attracting really great developers with the work that you do because you’re putting it out there, and people admire what you’re doing. I think it’s probably been a little bit easier for you in hiring than if you kind of bottled everything up and weren’t out there kind of showing what you’re doing, right?

PIPPIN: It definitely makes it easier to find potential people to work with.

BRAD: Mm-hmm.

PIPPIN: Sometimes just because people reveal themselves to you, maybe because they’re already working with your system. Just as an example, well, actually, every single person that works on the EDD or Affiliate WP team made themselves known to me. I didn’t reach out. I only reached out to them because they were already very, very visible in the work they were doing with the platforms.

BRAD: Right, right.

PIPPIN: Honestly, that’s a really nice benefit of open source software.

BRAD: Yeah, definitely. I think a lot of the core WordPress developers, it’s a similar situation, right? They were offered a position with Audrey Capital or Automattic or whatever just from their work with WordPress.

PIPPIN: Definitely. I remember being offered positions for that same reason because I was writing plugins. I was making myself visible, and so some people saw that, and they said, “Hey, would you like to come work with us?”

BRAD: Right.

PIPPIN: Which also, I think is just a good testament to say, “If you’re looking for a job in anything, whether it’s support, development, or something like that, simply make yourself visible.”

BRAD: Hmm. I’m interested in, like, what if we stopped developing. Let’s say you change your mind for some reason and you decide, okay, I’m going to run the business, and this developer that I’ve hired, I trust him. He’s going to lead development for me, and I’m going to just grow this business. What are the risks? After two or three years of doing that, let’s say, you’re probably not going to — you’re going to be out of touch.

PIPPIN: I’d say there are definitely certain risks. One, like you just mentioned, you’re going to get out of touch with the code base because unless you’re reviewing every line of code that goes through, which, to be fair, if you were, you probably aren’t doing your job of leading the business very well. Two, you might — if you originally were very, very strict about the code that goes in, to make sure the code is always top notch, and then you step back, and you give that control to someone else, it’s possible that they’re not going to be as strict. Eventually, your code quality will suffer. That’s where you just have to make sure you find the right person to take over for you.

But I think there’s a really good example of where somebody has to step back from development, and it’s clearly not suffered on the project: WordPress.

BRAD: Right.

PIPPIN: Matt Mullenweg is not developing. Clearly, WordPress is not a failure.

BRAD: Yeah.

PIPPIN: And, clearly, he’s doing very well for himself.

BRAD: Yeah.

PIPPIN: I think he probably was very conscious of that decision, and I’m sure it was probably a difficult decision at the time was whether or not to lead a company and lead the company that’s founding a lot of the development of this particular open source software, or to spend his time developing. I suspect Matt probably realized that he was more valuable in the company than he was leading the development.

BRAD: Yeah.

PIPPIN: And it probably helped because he’d also found really great developers to work with him. At that time, that would have been, I think, Andrew Ozz and, oh man, some of the older core developers that have been there for a really long time. That’s definitely going to make things a lot easier. If I did not have a developer or two in mind to take over a lot of the development, I don’t think I would be able to consider stopping development.

BRAD: No. No. Yeah, I think it’s a prerequisite to even considering it.

PIPPIN: And I think they need to already be there and have proven themselves.

BRAD: Yes.

PIPPIN: Otherwise it’s too much of a risk.

BRAD: Yeah. Also, the other thing is what if they leave. Say you do step out for a couple of years, and then your guy leaves that you’re depending on to run the whole code part. What then? Then you have to train yourself back up.

PIPPIN: Kind of a problem.

BRAD: Yeah, a huge problem, right? That’s another risk, I guess. If you get too far away from it, you might have a hard time replacing someone, and you might have to fill in.

PIPPIN: Now, to be fair, I don’t think that’s any different than the risks that we take when we are the primary leaders of a project and we realize that we’re human, and we might have a car accident and break both our wrists.

BRAD: Mm-hmm.

PIPPIN: It’s a risk that is just inherently involved with doing business.

BRAD: Yeah.

PIPPIN: You need to be aware of it.

BRAD: I really hope that breaking both my wrists is less likely.

PIPPIN: Oh, I really hope it’s less likely too, but it is an absolute possibility.

BRAD: Yeah.

PIPPIN: If it happens, you are not going to be developing.

BRAD: Yeah.

PIPPIN: You could dictate code, but that’s not very effective. And so, I think maybe my overall sentiment here would be that if you are leading a project of any kind and it’s a project that does scale up, make sure you’re bringing other people on. Don’t do it alone.

BRAD: Yeah.

PIPPIN: If you go out of commission, the project goes out of commission.

BRAD: Yeah. I’m pretty much planning to continuously be hiring, basically.

PIPPIN: Yeah. I would like to have new people come on every single year, for sure.

BRAD: Yeah.

PIPPIN: I don’t know if that means one new person or ten new people, but new people, regardless.

BRAD: Yes. Yeah. I think you have to do that nowadays, right? What would you say is the average retention, employee retention for a developer?

PIPPIN: Honestly, I —

BRAD: Two years? Three years, maybe?

PIPPIN: Obviously it’s going to depend a lot on the company and the number of people that you have.

BRAD: Yeah. Of course, yeah.

PIPPIN: Over the lifetime of EDD, which is almost three years now — or are we almost to four? I think we’re almost to three years. This spring will be three years — I think we’ve had about, like, three developers that were actively working with us that are no longer with us.

BRAD: Right.

PIPPIN: That’s out of about 10, so that’s 30%.

BRAD: Yeah. Yeah, I mean developers are in high demand, right?

PIPPIN: Oh, yeah.

BRAD: So they pretty much have the pick of the litter. Whatever they want to do, they can do it and still find work. That reminds me. Did you see Cristi Burca’s post recently?

PIPPIN: Yes, I did.

BRAD: Scribu.

PIPPIN: Yep, about him not being at WordPress anymore.

BRAD: Yeah! He’s totally out. He’s pulled the chute on WordPress.

PIPPIN: I didn’t know that.

BRAD: No, neither did I.

PIPPIN: I knew that he wasn’t as active, but I didn’t know he was 100% out.

BRAD: Yeah. I knew that he had given up WP-CLI to Daniel Bachhubber.

PIPPIN: Yeah. I knew that he had also given up Posts 2 Posts.

BRAD: Yeah.

PIPPIN: Actually, I don’t think Posts 2 Posts has a new main contributor.

BRAD: Oh, really? Huh.

PIPPIN: I don’t think so. I think he’s still looking for someone to take it over, which, if he is, anybody who wants an amazing plugin to inherit, that’s the one.

BRAD: Yeah. Yeah, that’s —

PIPPIN: I mean you’re stepping into pretty big shoes, but that is a heck of a plugin.

BRAD: That plugin could easily be incorporated into Core because it’s one of those ones that —

PIPPIN: Oh, yeah.

BRAD: — are kind of — it’s like the plumbing. You know, it doesn’t really affect anything, like the interface or anything, unless you activate it, unless you add code to take advantage of it.

PIPPIN: I suspect that it’s built in a way that would be pretty easy for Core to accept in terms of, like, it’s got the right structure. It has a smart database schema.

BRAD: Yeah.

PIPPIN: Everything is pretty consistent with Core APIs and standards.

BRAD: Oh, yeah.

PIPPIN: Cristi was a long-time Core contributor too.

BRAD: Right.

PIPPIN: So he knew how everything worked.

BRAD: Yeah. Well, I was kind of sad to see him go, to be honest, because I’m a big fan of the stuff that he’s done.

PIPPIN: Oh, yeah.

BRAD: And so it’s too bad he’s out, but on to greener pastures, I guess.

PIPPIN: I mean everybody has to move on to something eventually.

BRAD: Yeah.

PIPPIN: I mean I can’t — I have no preconceived notions that I will be doing WordPress work forever.

BRAD: Yeah.

PIPPIN: I don’t know if I’ll be doing it for five years or ten years or one year.

BRAD: Yeah.

PIPPIN: I don’t plan to quit tomorrow.

BRAD: Yeah.

PIPPIN: But everybody moves on at some point.

BRAD: Maybe onto greener pastures wasn’t the right word there. That makes it sound like the WordPress community is garbage. Yeah, onto new things is probably the right way.

PIPPIN: Yeah. Everybody has got to change things up eventually.

BRAD: Yeah, exactly.

PIPPIN: We’re getting pretty close to wrapping this up, but I think this was a really good topic that we could continue on very easily in additional episodes or in the comments, Twitter, Facebook, et cetera. If you are leading a project and you’ve run into some of these challenges, or you have additional questions about them, or you’re thinking of leading, or you’re somebody who works for a project lead and you have questions or issues, I’d love to hear feedback.

BRAD: Yeah, the same here.

PIPPIN: Anything specific you want to ask for, Brad?

BRAD: No, no, I think that covers it. iTunes reviews if you haven’t already.

PIPPIN: That’d be awesome.

BRAD: Please go onto iTunes and give us a review so other people can find us easier.


BRAD: I believe we had a couple.

PIPPIN: Yeah, we had a couple come in over the last week or two.

BRAD: Okay. Maybe next time we’ll —

PIPPIN: A big thanks to those people.

BRAD: Yeah. Maybe next time we’ll maybe read a couple of those in the next episode.

PIPPIN: Yeah. Again, if you’re looking for picking up a new plugin, today until Monday is definitely the day to do it because a lot of plugin and theme shops are doing Black Friday and Cyber Monday deals, so go check them out. There are a couple of sites that have done some nice roundups: WP Mayor, Torque, Sell with WP, a couple of others. Brad has a nice deal going on, and we’ve got a deal going on for EDD, Affiliate WP, and everything on Pippins Plugins.

BRAD: Sweet. The Pippin empire.

PIPPIN: I don’t know if I’d call it an empire, but —

BRAD: All right, man.

PIPPIN: All right.

BRAD: Thanks, everybody.

PIPPIN: If anyone has any questions or comments, feel free to let us know. Thanks for listening.

Apply Filters © 2024