Running WordPress from the Command Line with Daniel Bachhuber and WP-CLI

Joe Casabona: This episode is brought to you by our great sponsors. Do you build WordPress sites? Are you hitting the limits of your coding knowledge? Break free of your limit and do far more than you ever thought possible. Formidable Forms will help you build robust applications quickly without any PHP. Take on bigger projects, earn more clients and grow your business. Get started today at buildpodcast.net/forms. That’s buildpodcast.net/forms.

BoldGrid works as a suite of plugins designed to help you create WordPress websites faster and easier than ever. BoldGrid will improve your workflow by providing direct access to free themes, page templates, photography, design elements, forms, galleries, and much more right from your dashboard. And the BoldGrid page builder allows you to easily drag and drop and edit this content as you see fit all without having to use shortcodes. To learn more, head over to builtpodcast.net/boldgrid. That’s builtpodcast.net/boldgrid. 

And now on with the show.

Hey, everybody. Welcome to another episode of How I Built It, the podcast that asks “How did you build that?” Today, my guest is I never, I always forget to ask how to pronounce the last name. So I hope I don’t butcher this Daniel Bachhuber of WP-CLI.

Daniel Bachhuber: That’s pretty good. You got it.

Joe Casabona: All right. Awesome. Daniel, how are you doing today?

Daniel Bachhuber: I’m doing great.

Joe Casabona: Awesome. Thank you for joining me. We’re going to talk about a product that I just recently started using, much to my dismay like I wish I started using it like a long time ago.  It helped me delete like 3 million spam comments from a database where nothing out like literally nothing else worked, like using WP-CLI to write a direct query to the database was the thing that worked best for me. So,  I’m very excited to talk to you about this, and everything that you’ve done for it, and then plans for the future. So why don’t we start off by telling us a little bit about you and about WP-CLI, and then how you came up with or acquired this idea, right? cause I think it was somebody else’s before yours, is that right?

Daniel Bachhuber: Yeah, the project started about five or six years ago by a guy named, by the name of Andreus. And then, you know, he worked on it for a little bit. And then another guy by the name of [Inaudible 2:33.22] also known as Christie picked it up was the maintainer for a few years. And I picked up maintainership after that. So I really got into it from my time at WordPress.com VIP. And the context there is, you know, wordpress.com VIP, you know, at that time was hosted on wordpress.com and wordpress.com is this massive WordPress multisite installation, right? Is huge, huge, tons, and tons of code. Every VIP client is a theme in the theme’s directory, right? So thousands of clients, potentially thousands of themes. And one of the kinds of aspects of working for wordpress.com VIP is running scripts against client sites. You know, an example is I want to assign category B to all posts with category A as well because their site is hosted on wordpress.com. And it’s shared tenant architecture, such that their site is sharing the same code base of, you know, all the other sites on wordpress.com. It required us, you know, VIP code Wranglers to run those scripts. And at the time, you know, VIP had dozens of these scripts that performed one-off tasks, you know, quite helpful, you know, cause he’d get a support ticket. You know, someone wants to do something, then he’d look in the bin directory and see if there was a script for it. And If there was a script for it, then you saved yourself two hours of time writing a new script for it.

However, the challenge at that point was that every one of these scripts had different usage instructions and different idiosyncrasies, and it was, you know, 15 to 20 minutes each time to figure out how it worked. And whether it actually worked for your needs or what, you know, it was slightly different than what you needed and you’d have to adapt it. And so that just kind of drove me bonkers up the wall. I’m an OCD, you know, kind of details oriented type of person. And I could not handle the fact that all of these scripts were so difficult to run.

So I wanted to standardize the usage instruction. And Thorsten OTT, another VIP engineer at the time recommended diet checkout WP-CLI as a project to kind of emulate. There was already the concept of writing custom commands so he suggested I write, you know, custom commands for the different things I wanted to do. And I ended up getting really involved, contributing to WP-CLI a lot of the bin scripts that were on the wordpress.com codebase. And then from that, you know, eventually Scribd, decided that you no longer wanted to maintain the BPCI and so I stepped in as the new maintainer. 

Joe Casabona: Nice, nice. So,  WP-CLI is an open-source project, right? Anybody theoretically can contribute to it.

Daniel Bachhuber: Right. Open source MIT licensed. You know, I have a lot of thoughts on open source that have really matured over the years, which is kind of interesting. I do believe generally in the statement of, you know, open-source is one of the greatest ideas of our generation, it’s had huge transformative impacts on every single industry already. And I think it’s very much underappreciated. You know, many huge businesses are built on open source code where, you know, whether or not that project is moving forward or not is not actually something that the company may even have visibility into. So they’ve created this dependency on, you know, some piece of code and community of volunteers and maintainers and that sort of thing that they just, you know, don’t have any interaction with. So, yeah, it’s an open-source, MIT-licensed command-line interface for WordPress. Anything that you can do through the WordPress admin, you can do it, the command line. And you know, like you experienced, you don’t really know what that means until you experience it and it’s just mind-blowing. It’s like, I used to do this, the web, like this, is bonkers, you know. And even when I use the web, now I have, you know, all the different URL patterns for the admin memorized so I don’t even, you know, I can bypass the clicking through, you know, cause clicking through is actually somewhat time-consuming. 

Joe Casabona: Yeah, absolutely. I mean like it really is… If you know anybody listening out there, I would encourage you to check out WP-CLI. I know that the command line Interface can be scary if you don’t work in it a lot, but there are some things I do there, right?

But right before this call, Daniel’s telling me how he’s hanging pictures and the one picture that was hanging up just fell. I’m going to have to like take a screenshot and include them [crosstalk 7:20.40].

Daniel Bachhuber: And its frame broke too.

Joe Casabona: Oh, man.

Daniel Bachhuber: This is the problem they had last with my last set of picture frames. And so I thought I got more durable, more durable hangers, and now I didn’t. And so I’m actually probably going to take the rest of them down because I don’t want to break more frames.

Joe Casabona: Oh man.

Daniel Bachhuber: It’s just, you know, to bring this back to the topic at hand, it’s just like getting destroyed by a bug. Like you think you’ve fixed the bug, you’ve pushed it to production, It works for five minutes and it’s caused all these other problems. But now you have to clean that up.

Joe Casabona: Yup. So actually that’s a great segue because you are one of the more developer-centric. You’re like a heavy backend dev, I would say.

Daniel Bachhuber: Oh, I do CSS too. Don’t get me wrong.

Joe Casabona: Okay, sweet!

Daniel Bachhuber: I do, actually one of my first jobs, I was digital media manager at CUNY, graduate school of journalism. And I did everything from server admin to the backend, to frontend, to design on the front end to print design, to teaching HTML CSS classes. 

Joe Casabona: Nice. Nice. And that’s, are you from New York?

Daniel Bachhuber: I’m from Portland, Oregon.

Joe Casabona: Okay.

Daniel Bachhuber: Well, out. You know, the outskirts of Portland, Oregon suburbs.

Joe Casabona: Gotcha. Gotcha. Cool. Very cool. So,  but, like I guess some of the things that you do for WP-CLI is very heavy backend stuff. So, you know, when you WP CLI,  and this is also really interesting too, what was that process like? Because almost all of my guests, yeah, I’m pretty sure all of my guests at this point have been working on projects and talked about projects that were their brainchild but this was one that you’ve acquired. So can you tell us a little bit about that process? 

Daniel Bachhuber: Sure. I think it goes even before then, because once I started contributing to the project, there was not, even an idea in my mind that eventually became the maintainer. You know, I was submitting a lot of pull requests and getting code reviewed and feedback from Christie. And now it was, I immensely appreciated that experience because I felt like it brought me, it brought my own skill set up, you know, way, way, way, way up. And it was also an opportunity to better understand how, you know, through that process, how he approached the project and thought of the project and made decisions about how to implement certain features, whether or not something makes sense to add as a feature. You know, all these different decisions that you have to be making on a daily basis that is very implicit, you know, judgment calls. There’s not necessarily a rule book that you follow or an easy way to make these decisions because the decisions too can have a long-term lasting impact for better or for worse.  So you kind of really has to develop that philosophy of the project and how the project approaches the problem that is set out to solve, or the opportunity that is set out to create and be consistent and true to that cause that consistency too, you know, consistency in how an application behaves is a key part of the user experience. You know, if your user’s going to be using your tool day in and day out, you know, they expect it to operate similarly even when it’s a huge, massive application that does many different things. You know, if there are little micro differences here and there, it can actually be a huge, you know, mental burden and cost to the end-user.

Yeah. So, you know, I spent a year just kind of under his tutelage learning, you know, how he was approaching the project. And it was a big concern of mine to take it over, you know, whether I would fulfill this same level of quality that he’d achieved, you know, in running the project. And I, you know, I’d like to think that I have, and I like to think that the ways that I’ve moved it forward have been, you know, net positive for the project. But that certainly a huge risk and challenge of handing off a project is whenever you’re handing it off to, are they going to, you know, cause there’s kind of an implicit pact that you have with your users for better or for worse, right? You’re releasing this software to the world. You’re releasing updates to it. You are developing a relationship with the users of your software. And from that, you build trust and, you know, hopefully, a good working relationship. And so it can, you know, in order to transfer that trust to someone else as an incoming maintainer, you have to have trust in them that they’re going to uphold the nature of that trust. 

Joe Casabona: Yeah, absolutely. And I mean, you see that when you hear, you know, one company is buying up some product that you love or something like that, you get worried that as an end-user, it is the product I love that’s going to change.

Daniel Bachhuber: Right. Right.

Joe Casabona: So, I mean, you know, it’s worth that’s definitely worth saying, you know, It’s just as hard as the original developer to make that decision. And hopefully, they’re doing it for the greater good of their users. So you took on this open-source project and I think that you know, something that we see a lot in the WordPress community is,  you know, people building big businesses around open source projects, but that can always be a challenge. So,  when you took on WP CLI did you intend to try to build a business around it and make it profitable so that you could put time towards it? Or did you intend on having it kind of be like a pet project?

Daniel Bachhuber: Sure. Certainly, in the beginning, I had no intention ever to try to commercialize it. To me, it was always this project that, you know, I really enjoyed and appreciated and, you know, thought it fulfilled a valuable role in the ecosystem. And I wanted to, you know, as a part of my way of giving back or whatever. And to scratch my own itch, I wanted to see the project continue on as it had. 

In the last year, that thinking has changed a bit in the sense that I’ve really come to appreciate it. So, you know, I spend a good amount of time on a regular basis maintaining the project. And I think that projects that last a long time and are considered healthy require the input of regular consistent labor, people doing the unsexy work that’s needed to keep the project healthy and move it forward. 

And so initially, I’d gotten into that and been able to kind of contribute on my own on a volunteer basis comfortably. You know, alongside my consulting business, it just, you know, I fit it in alongside all of my other work and, you know, would prioritize getting new releases out and that sort of thing. All the releases would be delayed by, you know, up to four weeks, you know, five weeks, if I had some other big project that was going on, just taking all my time. 

And in the last year, I’ve really developed this opinion that WP-CLI in order to be successful in the long term needs substantial commercial investment. Ideally in my opinion, from a few different players, because, well, it needs commercial investment because you know, it had received my own commercial investment over a period of time. And I think I benefited from that, but I can’t be committed to the project, you know, indefinitely, you know, 30-year lifespan. And when it’s time for me to move on, I want it to live on. I want it to be able to live on beyond me without having to, you know, hope, you know, like depend on luck that someone else thinks it’s within their self-interest to volunteer, you know, a huge amount of time,  towards the project.

So, you know, last year developed this opinion that it needs commercial investment. And I decided I’d start my own business as a way of being kind of the first one to contribute significantly to WP-CLI. And over the course of the year, the business actually evolved reasonably well. You know, it was maybe doing as well as the kind of like any other premium plugin sort of business could expect to be doing after a year. But I realized that you know, my own time is zero-sum. And at the point of like, oh a month ago in December, that the time that I spent on my business run command was time taken away from WP-CLI, the project, because in both cases like it wasn’t enough money coming in that it was like I could take away from my work to put into my business. And because, you know, they were on similar, but divergent paths that came to the realization that, you know what, like, as much as I want for this to work out, there’s no guarantee that it’s going to work out. And you know, I think I just needed to call a spade and end it as an experiment.

Joe Casabona: Gotcha. S\oO I guess we can, let’s get to the banner question here, right. And there’s a couple of ways that we can do this, right? And the banner question of course, is how did you build WP-CLI? which was a preexisting product that you’ve attempted to build a business around. So maybe you can kind of talk about your development tools and a couple of the deep dives into kind of the WordPress core to make it work. But also the things that you did to try to build a business around WP-CLI, what worked and what didn’t work? And then we can move into kind of your plans for the future of WP-CLI.

Daniel Bachhuber: Sure. So the first tool that comes to mind is a testing framework called Behat. And Behat is behavior or well, actually, I think it’s business-driven development. Let me just Google that behavior-driven development. I don’t know, I thought about business. Anyways, the point being might be familiar with, you know, PHP units in unit tests and unit tests is this particular unit of functionality. So for instance, a function that formats zip codes, right? You’d write a series of unit tests to verify that, you know, given all these different scenarios where some data is input by the end-user, you know, the function correctly transforms that data into X. 

So Behat is different in that your tests are actually written at a much higher level. Written in a way that, you know, if you have a form where credit card or a zipcode is, you know, an input field on that form, the Behat kind of, how the test would be approached. Perspective would be you’d write a test for the entire form and the filling of that zip code field would just be part of the bigger tests of the behavior of the form being filled out and submitted. And the expected behavior of, you know, when you submit different values and that sort of thing. So it’s a much higher level testing framework. And I think that it’s actually really worked out well for WP-CLI, the project in large part to, you know, how Christie set up initially. But it enabled us to, yeah, I think that build quality is a very important part of WP-CLI. You know, not shipping bugs, not shipping regressions, that sort of thing. And, or in, when you get to a five, six-year-old project, you really do need to have test coverage in place to have some level of sanity that you’re not just causing, you know, but random bugs, you know that no one gonna discovers for six months. And when they do, it’ll be, you know, a painful discovery. And so because of Behat, I think the project has been really able to mature at a healthy pace at a healthy clip. Because you know, all levels of contributors have been able to contribute to it. And it’s easy for the maintainers to determine, yes, this contribution passes existing tasks and adds some new functionality, and there’s new tests for that functionality, and so on. 

Joe Casabona: Gotcha. So that’s really cool.  Testing is something that automated testing I should say is something that has become very popular in the WordPress community in the last few years, I feel. And correct me on this analogy, but the unit test is almost like kicking the tires on a car, right? like making sure the air is in the tire and then behavior testing would be like driving, like going on a test drive with the car, is that it?

Daniel Bachhuber: Right. Right. Going on a test drive in the car on a snowy road, on a dry road, you know, on a rainy road. So on and so forth.

Joe Casabona: Gotcha. Gotcha. So, those two can definitely work hand in hand, you do the unit tests, you release the full form, and then you do the behavior testing. Is that?

Daniel Bachhuber: Yeah.

Joe Casabona: Okay. So with WP CLI and there not being a kind of a front-end piece to it, could you kind of maybe walk us through one of the behavior tests for that? 

Daniel Bachhuber: Sure. One of the ones I actually just wrote this morning in fact, there’s a series of commands around manipulating the object cache. So the WordPress object cache is,  it’s just the default implementation in PHP memory when it reads some data from the database, it’ll store that in a consistent way in PHP memory to prevent that, you know, when that same data is queried again from hitting the database again. So it’s just a, you know, easy-to-implement scaling layer. So WPC…Go on.

Joe Casabona: Oh, sorry. So just like you want to get the post with the ID 1, 2, 3, you grab it from the database at first and it’s stored in object cache so that every time you want to access that post, you’re not hitting the database, is that correct?

Daniel Bachhuber:  Correct. And so there’s a series of functions that, you know, you can call on your own code to WP_ cache_get, WP_ cache_ set, that sort of thing, that there are equivalent WP-CLI commands. So actually, Yeah. I mean they’re more or less the same, right? That, you know, WP_cache_get is the function, but it’s also the WP-CLI command. So the test that I wrote this morning, that there’s some behavior of the object cache in that you can save key-value pairs of data. But those key-value pairs of data can also be, as a part of groups and you don’t, aren’t required to specify a group. You can just use the key-value pair, but if you wanted to group your data, you know, in nodes for a reason that makes sense for whatever you’re working on, then you can do that. 

So WordPress’s behavior is that if you don’t supply a group, it uses the group by default. And when you don’t supply a group that also includes supplying an empty string as a group under the hood, it will change that to the default group. And so the messaging in WP-CLI was incorrect in that If you, you know in the WP-cache-set and your key was Fu and your value is a bar and your group was left blank, it would say successfully set, you know, object key in the group, you know, an empty string. Well, I’m OCD about these sorts of things. And so I noticed that and thought, “Oh! It would be more correct to display to the end-user that the empty group that they’ve provided is actually the default group”, because when they go looking for where the data is, you know, WordPress kind of equates those to be the same thing. So I wrote a series of Behat tests that when I did WP_cache_set and didn’t supply a group, it would end up in the default group. And the messaging, you know, was corrected to be such. And Behat, you know, just you’ve got to check it out because it’s so good. All of these tests are written in a very human-readable form. 

So even though you may not be familiar with how Behat works under the hood and how all this is happening once you become acquainted with the language, you know, when I do this, then I expect to see this. You write that out in English and then Behat executes the test suite for you. And, you know, if something is wrong with your code and your tests aren’t passing, you have a great degree of visibility into that. And not only that but because it’s automated, easily, runs it on every change to the code base and it’s just like, you know, it’s hard for me to imagine working on a mature project without test coverage at this point. Because I’m so terrified, you know, it’s easy to make ax at all mistakes if you don’t have tests covered. You just don’t even, you know, you may think the impact of, you know, these two line changes that you’re making, but you don’t truly know the impact unless you have test coverage for it.

Joe Casabona: Yeah, absolutely. And like you know, you make some assumption that X was working before I made the change, and therefore X is still working. But anything could have happened to X, we know. 

Daniel Bachhuber:  And to bring this back to running, an open-source project too like I think that tests are invaluable for a project, because if you want your project to be open to a variety of contributors, random drive-by contributions from people that, you know, decided that they wanted to fix some bugs or whatever.

You know, trust is a huge factor in that, right? Like, how do I trust this? How do I know that I can trust this person’s code and that the code that they’re submitting, you know, cause they’re coming by once, right? They’re gonna submit a pull request, you know, hopefully, they’ll see it through to completion. If it causes a bug and you have to deal with that bug three months ago, then it’s kind of like net neutral contribution to the project, right? cause it’s like, well, it’s great. You know, I love having new contributors, but if new contributors are just consuming a bunch of code, then it’s like my total amount of time and effort has been greatly increased.

And so with tasks as a part of the equation, you can really think through the contribution as a series of tests that, you know, you want to have passed. And if there aren’t sufficient tests, then you say, “Hey, please add some tests to this” so that we can have this conversation in a very explicit way, describing how that new functionality is expected to work.

Joe Casabona: Gotcha. And that makes a lot of sense. That’s really great to hear. I’m really loud. They were talking about the testing, because I think that’s, at least for me, that’s a big sticking point. Like I hate testing my code personally because, you know, essentially I built something, and then I’m trying to break it. But to kind of keep it on the open-source project route, like we said a little while ago,  making these things make financial sense,  could be tough, right?

Recently it was announced that you tried to do a few things to make some money to allow yourself to spend more time on WP CLI. And an announcement came out that it was falling under kind of the wordpress.org blanket, is that right?  

Daniel Bachhuber: Uhum.

Joe Casabona: Could you talk a little bit about as much as you can, how that happened, and then what that kinda means for the future of WP-CLI? 

Daniel Bachhuber:  Sure. So basically what happened is at the beginning of December, I came to this conclusion that you know, creating run commands, premium commands business isn’t going to work out. You know, I just don’t have a great degree of confidence. And part of that is the lack of confidence. They think it’s really hard to sell developer tools to developers because there’s this, unless it’s like something obvious, like an application that you can download. But when it’s like the open-source realm already, you know, people are either, there’s just a negative mindset.

And similarly, I found that when I was working on the premium WP-CLI stuff, it wasn’t as enjoyable because I had fewer users. You know, I didn’t have people asking as many questions. I like working in the open. I like being able to accept contributions from people and that sort of thing. So I just came to the conclusion, you know, it’s not gonna work out. And as a last-ditch effort, I launched this kind of like, I mean really the best way to describe it is like, give me money campaign, like very direct ask. Like how much is WP-CLI worth to you? If it’s worth, you know, a hundred bucks a year, then give me a hundred bucks a year or if it’s worth 1500 bucks a year, give me 1500 bucks a year. If it’s worth, you know, 7,000 a year, then give me 7,000 a year. And it was, you know, it was like, I’ll give this about like 10, 15% chance of working out. We’re working out to be able to raise a reasonable amount of money. And I haven’t made that number public because I think that there’s a lot of challenges like transparency reports. But at a high level, my goal is to be able to pay myself part-time to work on the project. And then also be able to hire. And this is still the goal to be able to hire a couple of other people to work part-time on the project.

And I think the part-time aspect is really important because I think that you need to be able to, you need to be solving problems in the real world and have real-world problems to solve. But then you also, need dedicated time to contribute those solutions back to the open-source project that you’re responsible for. I think a lot of open source projects actually struggle because, you know, their contributor base doesn’t really have the dedicated time to see this solution through, in the project that they’ve been dependent on. So that, you know, so like the Give Me Money Campaign, ran it for a week. You know, I’d kind of gotten to like a break-even point. You know, it was not great timing, to be frank, like asking companies for money at the end of the year when their budgets are pretty much done. It’s like, yeah, not the best decision-making on my part. but what it came down to is I actually don’t own the WP-CLI.org domain. 

And I was talking with Andreas, the original creator, about him giving it to me in some form. And he was on the fence about whether or not to give it to me outright. Or lease it to me for like a buck a year under some terms, because it’s this, you know like there are parallels in the real world. It’s like a park that I’m responsible for maintaining. And there’s like this, the original creator of the park that wants to make sure that the park remains like open for everyone to use and that the monetization aspects don’t hamper people’s abilities to use the park. And this, and there’s timing for this kind of negotiation was the same time that it was meant to take a vacation and like, just be able to mentally check out from work. So, again, not great timing on my part. 

And when I finally, you know, got to talking with him again, I was, you know, they kind of give me money, ask the intent for that only was ever to like, make enough money to be able to hire people to work on the project. It wasn’t to like operate an independent business. It’s like profitable that I’m going to sell. 

And so, you know, just kind of given the challenges involved, you know, as this is like, it doesn’t make sense to do this independently just cause like, even if I can like to raise enough money for the first year. Well, Give Me Money, like my goal was, you know, kind of bare minimum. And then I was going to like to run advertising on the site or something to make more money, you know? So I was just like, not going to work out. And you know, the WP-CLI being an official WordPress project has always been in the cars just like personally, I have liked its independence in the sense that like, I feel like it, that independence gives us the opportunity to operate at the intersection of everyone’s needs in commercial wants, and not necessarily be like influenced by one, you know, key stakeholder. 

But, I think I’ve gotten an arrangement, worked out with Matt now where like, I can still feel comfortable with that. But it also now has a long-term future because like, if I get hit by a bus like there’s going to be more people that can just kind of like pick it up. And you know, who knows how the project would move forward after that point. But at the very least, like I no longer feel solely responsible, you know, for the project. And there, I think it’s really important to acknowledge and appreciate that just because it’s an official wordpress.org project doesn’t mean that like I’m still fundraising like I’m a bit about a fifth of the way towards where I want to be. And WordPress itself is the creation of, you know, dozens of companies that contribute significant amounts of employee time towards the project, right? There’s DreamHost employees, there are GoDaddy employees, there are Bluehost employees, there are automatic employees. And a lot of that is kind of like, you know, coming from Matt’s ability to negotiate that with the companies.

And so for WP-CLI, it’s a little bit different from an experiment in that. The crowd, the funding will actually come from a variety of entities. Like I think I’ve gotten 60 individuals to contribute, you know, so far. And, it’s going to fund, you know, part-time involvement instead of full-time involvement, which I think Will lend itself more productively to the WP-CLI project. But at the end of the day, you know, behind every, you know, well-maintained open-source tool that we love is some company that’s decided that it’s worthwhile to contribute a significant amount of time and effort in investment into the project. And without that, then projects just kind of, you know, fall apart and aren’t maintained anymore. And you know, every one it’s like, I actually just started using Laravel Valet, which is amazing. It’s like so good. I love it. And that looked at the issue tracker and there’s like, I don’t know, 30, 40, 50 issues or something. And a lot of them don’t have replies and it’s like, “Does it make me feel super great to be dependent on this too?” That’s not being super actively maintained.

Joe Casabona: Yeah. I’ve actually heard some fodder about the people, like the gatekeepers who are like, that’s not an issue. And then just like clothes issues. And I don’t know if that’s Laravel, the project, or Laravel valet, but that does instill a lot of Happy feelings in me. 

But we are, we might be a little bit over time. This half-hour has flown by when we talked about a lot of great stuff. And I want to end with the question that I ask all of my guests, which is, do you have any trade secrets for us?

Daniel Bachhuber: Yeah. Actually, my favorite trade secret is time tracking because there was a time where I didn’t pay attention or keep track of how I spent my time. And now I do. And now I have much more awareness of how I spend my time and I feel much more in control of how I spend my time. And I think that is like the most important thing for long-term success in open source because open source is just like always going to be demanding of all of your attention. And, you know, you’ll feel obligated to work on it on the weekend and that sort of thing. And if you don’t have awareness of how much time you’re spending on open source, you really have no effective way of evaluating, you know, your kind of success in what you’re doing, I think.

Joe Casabona: Gotcha. And what do you use to track time?

Daniel Bachhuber: I use Harvest. It’s amazing. I love it. They only charged me 12 bucks a month and it’s like, you guys need to charge me way more cause I get way more value out of this 12 bucks a month. It’s got a little Mac widget thing that’s like money for login time.

Joe Casabona: Nice. That’s fantastic. Well, Danielle, thank you so much for joining me today. I really enjoyed talking with you about a whole bunch of things. I am sure the listeners did too.

Daniel Bachhuber: Hey, thanks so much.

Joe Casabona: Hey everybody. I want to tell you about a new book I wrote with my good friend, Matt Medeiros of Matt Report, called the Podcast Starter Kit. It’s a QA style book that tells you exactly what you need to get up and running with your own podcast.

I’ve had lots of fun over the last several months with How I Built It and I want to share what I’ve learned with anybody looking to start their own podcast.

In the book, Matt and I try our hand at answering 23 questions that you need to ask yourself before you get up and running. We also include several resources, our favorite equipment, and a checklist at the end. Head over to the podcastbook.com to check it out. It’s only $24 and it’ll save you hours of time researching the right tools, where to upload your podcast, how to run a good interview and a lot more. That’s the podcastbook.com.

Thanks so much for listening, and thanks to our great guests and fantastic sponsors. If you liked the show, please rate it and subscribe on iTunes in Google Play or whatever your podcast app choices. If you have any questions, be sure to reach out at streamlined.fm.

And finally, until next week, get out there and build something.