Highlights of the chat with Diego
- Stepping into WooCommerce with a Currency Switcher Plugin [05:03]
- Starting as a software developer in 1995 [08:00]
- Trial and error as a developer [11:26]
- Thinking like a physical engineer [13:06]
- Better communication between the core team and developers or users [16:42]
- WooCommerce.com, bigger and better structured [23:10]
- Taking on customer support yourself [26:37]
- Scaling from one to fifteen plugins [33:08]
- Working and growing with the collaboration of developers [36:28]
- A good developer is a lazy developer [44:47]
Thanks to Our Pod Friends
Mendel: Ladies and gentlemen, welcome to Do the Woo. I'm Mendel, and with me is my co-host Noëlle. Noëlle, who do we have as a guest today?
Noëlle: Hey, everyone. Today we have as a guest Diego Zanello. He is the founder of Aelia known for the Currency Switcher plugin. Diego, welcome to the show.
Diego: Hello. Thank you for having me.
Noëlle: Can you tell us for the people that don't know, how do you Do the Woo?
Diego: Well, it all started 2013 almost by coincidence because I had a very tiny, very, very small WooCommerce shop myself and I tried to sell some products which were also software. Nothing related to workplace. It was just a user. And I needed to have, to be able to accept payments in Euran dollars because I had basically 50/50 of the audience. And even though people don't realize it, there are 300 million people in Europe. Many of them use the euro, so they wanted euro. And so I started looking for it. I was a user, just a user, really. No experience with WordPress at all. And they asked, I asked the core developers, I asked other developers, they asked all the experts I could find, and surprisingly, I only found closed doors. Like, "No, it is not possible. Not now. Not ever."
And so this was weird to me because that's weird. It's getting a popular solution. Was still 1.6. Version 1.6. I said, "But what it mean it cannot be?" And I started being, since I had already plenty of experience in IT and software development, say, "Well, maybe it's not cost effective. Maybe it's harder. Maybe there are restrictions, but not possible ever is weird. I mean, it's a software in constant evolution."
So, okay. Faced with the challenge I developed it myself. And five hours later, I had a prototype working and I put it on my website. Of course, as everybody knows, nothing works because you didn't know what you're doing. So plenty of issues. And then people started seeing the feature and they discovered it was a huge user base that wanted exactly the feature. And all of them got the same answer that they got. "No, not a way, no chance. No."
So, okay. I started giving it to other people, collecting feedback, and then people started asking me to pay for it, to sponsor the development. And then I realized that it was a market for it. I asked if they would be interested in incorporating the core if other developer would like to take it over. Like, "No." "I have no other workers available. Would you like to carry it on?" And everybody said, "No, no, no. That's a dead end. It will not work." So, okay. Plenty of people wanted to have it. There was a lot of demand. So we put 11 months of heavy work on it there to do the first commercial version. 11 months, on average 18 hours a day. Not kidding. I tracked them. And I had the product live.
Plenty of people started using it. Huge feedback, plenty of bugs, plenty of challenges, plenty of clashes with the code developers because it basically cheats the game and they didn't like it much because it was like, "You're into using a lot of things that cause issues with other solutions." And ever since, it became one of the most important multicurrency solutions. And now there are plenty of alternatives, of course, but it took about two years before any other developer tried to do the same because it was hard. It was really, really hard.
So basically, my occupation is developing software. I'm a user as well, but mostly I develop solutions for WooCommerce. So my way to do the Woo is developing solutions for WooCommerce and integrating APIs, other services. So mostly backend because I admit I am completely bad in user interfaces, design things, that this is really not my field. It would take me too long to actually get the eye for aesthetics. So I delegate these kind of elements to others. So mine is coding, coding, coding, and talking to customers because I always believe that every developer, doesn't matter what you do, front end, backend, you must also participate in customer support. So the era of not always stay in my closet. I keep pressing keys. No, doesn't work. You need to talk to customers. You need to talk to people because otherwise you develop code that doesn't help anybody. You just, you do it for yourself, but you don't know the user wants it.
So what I do is talking to people a lot, helping people a lot, and writing a lot of code. So it's, let's say a third of each. So gathering requirements, developing code, and supporting customers is a bit of a balance, while still remain a user, but I get basically the site run by itself right now. So it's mostly developing the solutions that the customers use.
Stepping into WooCommerce with a Currency Switcher Plugin [05:03]
Mendel: So Diego, that's awesome to hear how you're doing the Woo now and how kind of stumbled into this Currency Switcher, which it sounds like that's the story, right? You stumbled into it. But how did you get involved in WooCommerce in the first place? Where did that come from?
Diego: I needed an eCommerce solution and I was looking for it. Okay, I had a very idiotic blog. I really call it the way it was. It was just like a diary, a public diary because I was going through a phase. But then I had the website. I was too cheap to buy a new to make it so I recycled the website into an eCommerce. And I needed an eCommerce. And so, okay, I had worked with Magento and it was beyond the master and it was huge, heavy, slow. So okay, okay. Know what, is there anything I can plug in?
So the workforce had plenty of plugins and then I stumbled across WooCommerce. It worked. It was simple. I checked the features, and it was actually very easy to use.
Mendel: And would you mind sharing what you were selling?
Diego: They were just plugins for another platform. But the thing is that they never sold anything ever really, ever, because at the time, basically, to be honest, I did it because, to be clear, my employer was a pain. So he needed to find a way to get something to pay the bills. So I had skills that along with the employer, I produce something for this platform. However, the platform is marketed completely different. Like the paying customers go for the pro-hosted version. So basically, the company that gives the platform also sells the plans. And the community version, everybody expects everything for free. Like not even a dollar. Nothing. They don't want to pay for anything at all. So you can try to sell something, but the market is just not there because whoever has budget, pays for the hosted version so they don't need to buy anything. So basically, I did all the work. It didn't really work out.
So it was generating zero revenue and all the people were interested in world to see prices in euro, so that's where I got sidetracked into that completely by chance, I would say. But the good thing is that I spotted the demand. I was really asking myself, am I the only one here? There are 300 million people in Europe. Am I the only one who uses euro? Anybody else? So I went on the forums. I went on Facebook, and that's how we moved from using WooCommerce to extending WooCommerce. And I tell you, version 1.6 was like one of these American gladiator courses. You have to jump from one obstacle to the other because it was still very, very rough at the beginning, but it was still having so much potential. That's why I gave it a go and it worked out at the end.
Starting as a software developer in 1995 [08:00]
Noëlle: So to backtrack a little bit further if you don't mind, You said you developed plugins for other platforms. How did you get into that? How did you obtain the skills needed to develop those plugins and eventually Currency Switcher? What's your background?
Diego: Well, I've been working as software developer since 1995. So basically, I never went to college. Could not afford it. Then I got drafted in Italian Army. Well, excellent, amazing. After finishing the service, was a year, there was the issue that my family could not cover the college and I needed to find a job. So I had to like that, it's something that people, many people don't know because every... In Italy is a bit different. We have high schools that actually teach a trade. And so after you finish high school, well, you don't see it, but behind... You don't see it. It's up there. But my title is actually equivalent to an engineer. That's why I actually am an engineer. Here in Austria it's recognized as engineer. You can't use it to go to a master, but it's still an engineer.
So basically, you get out of high school. It's a very packed five years of training. So I started automated system, mathematics, physics, chemistry, and computering system, databases. So when I finish high school before the year that I served in the army, I already had the knowledge, the basics to work as a software developer.
So I worked for several companies that, too many to remember, and I had luck/misfortune to work as a consultant. So my company would send me to a steel factory, to a chemical plant, to a winery, to a bakery, to automate, to do business software, to do accounting, to do implement solutions of all sort of things, and always customer facing, which is actually, I hated, I tell you at the beginning. Because all the time, the VAT. "Well, we don't care about the VAT." But this thing, when the wine is calculated, all this input that you need to process to rip out solutions.
So it was really stressful, but I got exposed to so many realities, talking to people who did not speak IT at all. And there was no internet at the time. They really don't know. If you tell them, "Start the PC," what does it mean? That was the kind of level I had to talk to. I was there to train the people with the basics, gather the requirements, translating into our technical stuff, train the juniors, and actually do the implementation, support the code.
So I had seen so many realities, and that many of them are a lot heavier than eCommerce than the internet. Nowadays we have blogs, we chat. I dealt with automation, factories with machines were the size of a tank moving tons of steel. So you can't make mistakes, so you have to make sure that you listen carefully, you understand what you're doing, and it has to be done. So you can't possibly give a customer, "No, it can never be done." "It's not why we are paying you. You have to do it."
So I had to gather all the experience. And then when I finally landed on the WordPress, I had so many other experience behind, then whenever it cannot be done, well, for sure it can. This is the only thing I know, it can. I don't know how, but it can. This is the only thing I know.
Trial and error as a developer [11:26]
So nobody wanted to actually take the challenge. And so, okay. As always, I try myself. So I went into the documentation. I read what a plugin was, and the first step was blank file, plugin header, "Hello, world." That's just what it echo. Oh, it works. Okay. But I don't like function programming. I'm an OP developer. So how do we use classes?
So I started putting classes, making mistakes, going by trial and error, and I made a prototype that did nothing basically. The only thing I wanted to make sure that I could use my programming skills as I had them in that environment. And then it worked. And there you go. Okay. Then I started dealing with, I labeled at the time, Captain Hook, because this is what WordPress is. Action, filter, filter, action. It's all hooks. So I didn't know any of them. What is an action? What is a filter? So I started looking, tried to run my head around this kind of known necessarily linear programming, because in normal application, when you have a greenfield project, if anybody's familiar with it, you design the software and you just call function. You call features. You do operations. You're don't have events fire all over the place so you intersect, and then you return the control. It's very difficult to follow the flow.
So that was the biggest challenge. Writing down on a piece of paper, and I write with pencil really, this goes here, then this comes up, then it fires again. Why? Doesn't matter. How do we prevent the firing twice? I can't. Okay. How do we deal with the firing twice? So all these challenges were the difficult part.
Thinking like a physical engineer [13:06]
Mendel: So it sounds like you were really using part of your engineering mind, almost physical engineering, right, to determine how the software system works?
Diego: Yes. Yes. Let's say, in this case, the body dies, but I tell you, you automate, I don't know it's called in English, but it's all right. It's a machine that lifts coils of steel which are 50 tons each. What happens if I press the button twice? Oh, I open the claw. It falls down. Okay. So you have to think, how do we make sure that I don't do the same operation twice when the thing is lifted in the air? So this thing is actually people die if you do it. So you have to consider what happens if the guy is just thinking about whatever, what we watch tonight in the TV, press the button without thinking. This is something, why would you do it? You lift it. So you have to put all this safeguards. And this was just automatic.
And the thing is that I needed to follow out, where do I have to put the safeguards? What could happen if an event is fired twice in a row? Which seems something, yeah, what could happen? I tell you what can happen. In my case, I'm dealing with currencies. If you convert the same amount twice, and you go from the Danish Krone to Europe to euro, your amount goes from a hundred to two to 0.2, and then you're selling your products for peanuts. It's nobody dies, but you can imagine that the customer say, "You know, I just sold my whatever machine for 10 euro, which actually cost me 2,000." And then I have to tell the customer it was a mistake. Yes, of course the customer know it's a mistake, but it's administrative work and you can't have a thousand customer doing that.
So it's a minor issue compared to still squishing people, but still, you have to make sure that you don't do operations that are not supposed to be repeatable. So all these elements that you have to take into account, WordPress has so many of them because it's the drawback of the ecosystem. If I write a plugin and Noëlle write a plugin and Mendel write a plugin and we all work our own way, and I fire an event, and Noëlle uses and fires another, and Mendel fires another, fires mine again, we go to a chain of events that will never end.
So this is unpredictable. And how do I know that you're going to do it? I can't. There is no way. So he need to think what would happen if somebody like passes the ball from me to you to use the other and then back to me, and it keeps going on, and then the site crashes. And they cannot tell the customer, "I don't know." "No. What do you mean you don't know? You develop this thing." But you think about this situation. There you go. You should have. So that's why all this kind of exceptional circumstances had to be taken into account. This was the biggest challenge with an ecosystem.
Mendel: And this is what the core developers were worried about this, right? They're thinking, "Well, here goes Diego. He doesn't really know anything about WordPress or WooCommerce yet. Right? Developing in it at least. And he comes to us, and he says, 'I really want this feature.'" And they say, "No, no, no, no. This is not easily solved, and we're not going to put it in core because it affects too many plugins, and there's too many use cases and things like that." And so then you go off and you build it, and they say, "See Diego, we told you this is difficult." And you say, "Well, it's difficult but not impossible because if we take each intricacy, and we go through each thing, and we iterate, and we iterate, and we iterate, then it's going to work.”
Better communication between the core team and developers or users [16:42]
So I'm really curious, and then I think Noëlle has some things to say, but I'm curious about how do you think about how they reacted? Because I know this is a common thing, right? Plugin developers, or even people in the community, they say, "Man, this is such a... This is a feature that everybody needs. Everybody needs a payment processor, right? Everybody needs taxes within certain countries. Not all countries, but within certain countries or certain municipalities. We should probably have currency switching if they're selling internationally." But your response may have been a little disheartening, or the response you got may have been a little disheartening. Does it make more sense now after going through this process, do you think that there's a better way to create, I guess, easier outcomes or better communication between the core team and developers or users.
Diego: The core team changed completely. And not just in methodology. A lot of people have been removed. They went to other endeavors. And one specifically, this one, one of the most unpleasant moment that they had, there was one of the core team developers but he wasn't a core team developer at the time. I pointed out that it was because of my solution he had developed a plugin, a payment plugin, that did not work properly because there is this thing that a lot of people don't realize if they don't have experience in development. There are a lot of things that work by coincidence.
Example, there was an API in WooCommerce, a REST API that used to work fine. Then they created the legacy API too. Then the three, then the new API two and three. Now the new API. The legacy worked perfectly fine. Then the new API stopped working, caused an issue that only occurred with my solution or another equivalent multicurrency solution was in place.
So first reaction was well, it works without that plugin. The plugin is something, there's something wrong. And I knew that it didn't because I don't understand how can it be. Doesn't even take part of it up. So I spent hours and I wrote eight pages of record and I found out that the glitch was in the new API because the way it was designed, basically, when you wanted to modify a product, you wanted to modify an attribute, it would actually trigger all the hooks and events on the product and save all the attributes again. So basically, you want to change a stock, it would actually recalculate the price and save the price. I said, "Why do you load the whole product and all this thing?" The old API used the old calls update make up, so there was no such thing. There were no hooks, no triggers, nothing.
So this was actually a design that my solution exposed. It was a glitch. Why it works without mine, because you are triggering a price that is not going to change because there is only one currency, and you save it back as it was before. But when you start introducing other plugins, not just mine, discounts, volume, volume pricing, user role pricing, anything that would change a product price, then you will see the issue.
And this took me hours while taking the blame that was me. Actually, if anything, I exposed the issue that was working by coincidence. And now that I created a condition in which the data may change after you load it, then they realized where the glitch was. And there was something like this with a plugin, as I said, of a core developer, that there was a mistake in the plugin. In many payment plugins, they would take the currency from the settings. However, there are three currencies in WooCommerce, the base currency, the active currency, the older currency. They may or may not be the same. In a single currency environment, they are, again by coincidence, but in a multicurrency they may all three be different.
So what he did, was taking the base currency, so passing the wrong information to the payment processor. And so if it's a small glitch, with this failure you can fix it. This guy got furious that they dare to say that he made a bug, he was introduced a bug. "But it is. You're taking the wrong currency." "No, there should not be more than one." "Yeah, but there is." "But there cannot be." "There is. There is even a filter that change it on the fly." We went on for a day. I still have it recorded, a day of arguing.
Then I told him, "You know what? You change this, it works." Silent. And I said, "Okay, I don't hear from this guy anymore. Luckily, it's done. It can happen." Three weeks later, we welcome the new core developer, that guy. I said, "Are you serious? Now I have to deal with it?" We had a bit of clashes. Years later, we had clashes over the course of the year sometimes. Diverges in opinion. Six months ago, he wrote publicly that he wanted to thank me for not having given up in the constant evolvement in the WooCommerce community, help improving the core, even though I sent no more than two comments to the core of WooCommerce. Because I'm very busy with the clients, I don't really have much time for core contributions. So I didn't really write a lot of code for the core, but the same person with whom we argued about the fact that I changed the game, and he, what I was supposed to, he personally sent me in publicly some thanks for having helped them.
I was completely unexpected because he replied on a public comment that I wrote, says, "Thank you for this. But I would like to point out that this you did not cover." And I was expecting again, you and your exceptions, I was expecting like, "You always have to go in there. Ah, but there is this arbitrary stuff. You know, we're kind of getting tired." Instead, he actually he thanked me for having done it for so long because provide the feed back that you don't see, that you as the developer, you don't think about everything. People from the outside, they tell you, "No, there is also this." "Ah, okay." So actually, this became so much more positive. It's a lot better as an environment.
WooCommerce.com, bigger and better structured [23:10]
And also, I believe after they got acquired by Automattic, the resources are more, there was a bigger team, so there was also much less stress and not so many people doing everything. Because if you are a couple of people doing everything, you can't do everything in the double with everything. I add the development, and the support, and the new feature, and everybody wants something. I only have 24 hours a day. And after a while, you get tired. So it's a human thing. Like, come on. Let's keep it to what we can do, not everything.
Now that they are much bigger team, they're better structured. They have more resources. There is more collaboration. So it's a far better experience for the users and for the developers as well. So it's a lot easier to work together. There is still room for improvement, which I'm still in touch with many of the core developers and a lot of the staff for the support team, because there is still plenty of room to establish a construction collaboration, a protocol, to communicate more, let's say. We using a standard to say, because everybody's a bit still independent.
But I think that if I have to compare 2013 with 2021, where there is no comparison. It really, people who start today, they have no idea how hard it was back then when there was only a few people and there was too much to do, so there was this resistance. I am also guilty of that when they ask me, "I want all these 300 features." Yeah, you know, I also would like to sleep. I can't implement everything for everybody. So they had to make choices. And I'm glad that they made the right one. So overall, I am very happy about the progress that we are going through.
BobWP: Hey BobWP here and I’d like to take a moment to thank to of our Pod Friends for their support of Do the Woo.
If you are looking for a plugin shop you can trust for your client sites, check out IconicWP. They have you covered for extending variations with single and linked variations plus custom fields for variations. Or perhaps you are looking for more power with your cross-sells, upsells or checkout optimization. Looking to add delivery slots to your store, they can take care of that. And lastly, help you clients by adding WooThumbs for customized image galleries and adding videos to your store. As you can see, for your next Woo build, it will be worth it to check out IconicWP.com.
Black Friday is almost here and you want to make sure those product pages are optimized. On Nov. 4 Yoast is offering a free online workshop, "How to optimize your product pages for Black Friday”. As you are helping your clients prep for Black Friday, or even if you are running a sale yourself, you will learn about the product page must-have SEO optimizations, psychological tiggers that work, how to increase your changes to get featured in "Google Shopping", and the benefits Yoast WooCommerce SEO brings to any Woo shop. You can find it on Yoast.com under events.
And now let's head back to the show.
Taking on customer support yourself [26:37]
Noëlle: So I'm curious, you say you have 24 hours in a day and about a third of your time is spent on customer support. And when I once needed support on your plugin and it clicked for me that it actually was you talking to me, I was quite amazed because it's not something you see often. So why is it that you feel so strongly? Because one could argue your time is valuable. You could easily hire somebody to do it. Why do you feel so strongly about doing it yourself?
Diego: Because unless it's a minor thing, I assume that nothing is, by default, nothing is minor by definition. And unless it's a minor thing like "Where can you find my license?" Okay, it's easier. There is like a canned response because it's easy. Step by step, there are plenty of thing. But I never liked delegating to people say that they can give an answer like, "I don't know." And I believe that every developer should be involved and stand by the product that they make. And if there is any technical question, the developers must be involved. Even if it's not immediately, as soon as they have the time, because they need to know what people think about what they did, because it's not something like, "Oh, I write the software the way I want and take it or leave it." "Okay, leave it. Fine." "No, I want you to use... " "No, you did it the way you want. Take it or leave it." "Okay. I leave it." "Yeah, but why? You don't want to talk to me, that's fine. I leave it. Bye."
So it's sort of the thing, when the people say you work for yourself. No, you don't. Unless you hire yourself and pay yourself with your own money, you don't work for yourself. You work for your clients. So if you want them to use a solution, you don't have to make a solution that works for you. You have to make a solution that works for them. And you cannot get second or third-hand information and get a clear idea. So speaking directly to people is the best way. And as the architect, I must know what they think. That's why I worked a lot to make sure that the support queries are reduced to a minimum, to the point that actually it's not even needed to have dedicated people full time to answer them. So when there is a query even that arise on the weekend, it takes me five minutes. Why can't they just answer them?
And also it's easier for me to say, "Oh, you can do this." They're happy. It takes me five minutes, really. And they're happy. And instead of having on Monday the 50 queries that arrived on the weekend, which many of them will get canned responses, but I have to get through them. So why do I have to delay an important conversation with somebody who might want a custom project, a big custom project? Sometimes we get them. Why would I want to delay it just because I have to tell them, "Sorry, there was a link. Sorry, yeah, the link was broken. Yeah. Okay. We migrated the website. It was a glitch in October. We just renewed the website completely redesigned. And there were a couple of broken links that I missed because I also, I'm the one who signs off everything, and okay, I missed the broken links. Oh yeah. I fix. It takes five minutes."
But it's important to show that you are there and not just somebody possibly from a sweat shop paid peanuts just to fob you off. Because I had that experience myself, and I ask a question, and it felt like... What was it, the film? Like The Best Exotic Marigold Hotel. It's like, "The contract is not in your name. I need to talk to your husband." "I understand. He died." "Sorry, Madam, the contract is not in your name. I need to talk... " "I understand. He died." "I tried to fix it. The contract is not in... " It was like a drone. And some people, okay, they have to make a living, but you can't put... You put everybody in a terrible situation. Like the person is reading a script. The customer doesn't get the answer. You could have answered in five minutes. Instead, you spent 20 in repeating like a parrot. And I don't like that at all.
So I actually, I was guilty of being too efficient. When I started selling my plugins, my response time was 25 minutes over 24 hours. You could write to me at 3:00 AM, 3:30 you had the answer. The thing is that I realized maybe it's too much. They can wait a couple of hours because there was no critical issue though. This was not a matter of life or death. So I said, "Okay, that's fine. Let's set human office hours." And everybody was happy with that. But at the beginning, I had this thing like as a customer, I was so demanding myself, and then I was so disappointed that they never get that kind of level of service and say, "Maybe I am too demanding and I'm promising too much."
So I toned it down a bit to balance also the stress, because if you burn yourself out, it doesn't benefit anybody, and I found a good balance. So let's say I have the opportunity to spend a third of my time in the customer support because I still have very few of these customers are going to require direct intervention. And still when I develop other features, they don't take so much time to implement because I have a framework behind it. So it's not like I'm delaying features to look after the customers. So I can do both and still bring the product on.
And another thing that I want to thank the WooCommerce core developers, they finally adopted a development cycle that has no breaking changes, which is... Okay, Okay. There are some sometimes. It's inevitable if you want to evolve, but on average, there are basically zero. There is once maybe a year, twice recently. At the beginning, version 1.6 would break when you upgrade to 2.0, then would break again 2.1, break again 2.2. It was a disaster. So basically cost and breaking changes, it was really hard to keep up. Now they can finally stabilized and they created this smooth the release cycle very often, very frequent that basically, I see WooCommerce 5.9. Okay. Let me run the test. Pass, pass, pass, pass, pass, pass, pass. Okay. Compatible. I almost expect it. I'm not saying that you should not do any testing because I do all the time, but I wouldn't say, "Okay, if I would forget the testing, 90% it would work anyway."
Scaling from one to fifteen plugins [33:08]
Mendel: But Diego, you have a problem, and your problem is that you have more than just one plugin. I mean, you have a lot of plugins. Okay? So this is kind of a super human thing, right, that you're like, "Oh, well, I'm going to support all these, and I'm going to make sure and test them, and I'm going to make sure and market them well, and all this stuff." So can you talk about scaling from 1 to 15, right? I got the number right, 15?
And are you using automated unit testing? Do you have other people that are developing? How big's your team? How does all that look? Because I think a lot of people, they want to get to the point where they're selling a lot of plugins, right? That they're a plugin company. Somehow, that's what you've done. It looks like you have some of the stuff in the same vertical, right? Taxes per country, and prices per country, and all that stuff. But then you started to push out into other things, right? So tell us about that. How did that all come to be and how do you manage all of that? I'm assuming it's not just you, but maybe you're superhuman. I don't know.
Diego: At the moment, I don't have full-time employees. I have collaborators that help me with some technical issues, mostly with integrations. And most of the work is done... If you look at the solution, there are four core plugins that I developed and I'm basically the main developer behind them. I do 99% of the coding, which is the Currency Switcher, the Tax Display plugin, which is powerful but also quite simple. The Prices by Country is also fairly simple and follows... It mirrors the Currency Switcher in some ways. So the code base is common in many of them. And the EU VAT Assistant is something that I made public just because I had to and because I was pinched by the VAT/MOSS rules that this European Union introduced 2015.
The others, say secondary plugins that work, but there are integrations with other platform. For example, Dynamic Pricing, Product Add-ons, and AffiliateWP, and Subscriptions Bundles. So a lot of the success of those is working with their developers because this plugin is that, okay, they are a lot, but they are fairly small. They do a lot of important tasks, but there isn't a huge amount of coding behind many of them. What they do is bridge... That's why they are free as well. They are bridging my solution with the other plugin that they... They have to communicate. So there is a lot of collaboration with the developers who created the target plugins. So a lot of communication with, now they have been absorbed. I lost track of all their acquisitions. One was Mike Jolly with the product Add-ons and the Dynamic Prices. Subscription was Prospress.
We worked together to fix a bug 2014. We worked for six months. And then again, in 2018. Bundles and Composite Product is somewhat warm from Greece, Athens. And Bookings, I don't remember who developed it because I have too many contacts.
Working and growing with the collaboration of developers [36:28]
But the key to this is working with other developers, not necessarily employees, because you can't do everything yourself. Even if you had a team of 20, 30, 50 people, you can't. You really can't. Because you are not the one who created the target. Like I am not the one who wrote WooCommerce. I have no idea how half of it works because maybe I never had to use it. I don't know. I never used, I never had to touch the queries, or I never had to modify the analytics or WooCommerce admin. So you have to talk to other developers. So my team is also the community itself. And if it weren't for that, I would never have been able to even do half of what I did.
So I didn't aim too high. I'm not really, even though I have been successful, I am not much of an entrepreneur. I'm really an engineer at heart, and I would not have been able to do everything myself, figuring everything out myself, hacking things myself, fixing things myself. It's too much.
So helping each other in finding a point of content and a middle ground to work together was the key for everything. Because many of my solution would never have worked if the other developers would not listen to me. And they say, "You know what? We don't care." Because a lot of developers originally, they did that. "WooCommerce is a single currency. We don't care. Bye. Jog on." Yes, but it's becoming jog on. "Okay guys, sorry, we can't do that because... " "What do you mean we can't?" Then of course the community said, "What do you mean we can't? Why? What's the purpose of it?" The community is not supposed to say, "We can't," and then change, they back-paddle. Says, "Okay, you know what? It may be we can work in one way. Can you propose a solution? Can we discuss it?" So there was a lot, a lot of back and forth with the authors of other solutions.
And once you find a point of stability, so you share experience. You share your point of view. For example, when I told them, that was one of the biggest clashes. "Are you done with breaking changes?" And one of the developers says, "We break whatever we want." This was 2014. "Yes, but I can't choose you all the time you break something." "We do whatever we want." The developer is no longer employed. I haven't heard from him anymore.
And then after, there was this person who worked... Yeah, I have to find his name. I remember because he was employed by WooCommerce a couple of years ago. He actually introduced the same philosophy that I had. Breaking changes only when necessary and only for the purpose of avoiding them in the future. Like we make a groundbreaking thing now, and then we stabilize and we stop it. And so they did with the WooCommerce 2.7. Yeah, 3.0. With 2.7, 3.0 it became stable, almost completely stable. So there is very little work to make a plugin work with the new versions. So you can automate most of the testing. You have to script some of the human testing because not everything can be done with PHPUnit, for example, because PHPUnit tests every component in isolation. But as soon as you add another plugin, you're throwing a wrench in the whole testing. So there you go. Does it work? Yes. In a vacuum and with no friction and no interference, it works. Okay. This is not a real scenario.
So you have to use other tools. There is one that I like, and I'm still trying to tweak it. It's called CodeceptJS, which basically simulates what the user does like clicking. Now I click there and then add it to the cart. And then I click there. It's actually a functional testing as if you were doing it by hand. And it's far more reliable than testing a class in isolation because, okay, let's try to run the same CodeceptJS on a test environment where I installed a gazillion of other plugins. I click and it crash already. Yes. Why? So? And then you have to start finding out why it crashed.
And to me, the key to make everything work, and you said, I am not super human, but I still do a lot of the coding myself. So I, most of the code you see, I wrote it from a blank file. One of the key is again, collaborating with developers and doing this... How do you call it? The being an evangelist. There are many developers who are on this called the Rimera Web. Another one was themeComplete. Another one was called RightPress. They're all unofficial. They're not in the WooCommerce marketplace, but I spent a lot of time talking to them like we are doing now to tell them why I developed this solution and how do I see them? And this was actually the hard sale.
Dear Rimera, dear themeComplete, dear whatever, let me tell you why you should modify your software to work with mine. This was actually the sale. And the first reaction. "Why should I even think about that? It works. Who are you?" And I tell them, "I am telling you, I tell you how easy it is. I give a proof of cost. You see how easy it is, and it's don't we forget. I promise once you do it, you will never think about it again." "Okay. I give you an hour." I explain to them, there you go. They did it, and all these people have solution, done work with WooCommerce up to the latest version.
My multicurrency solution and others as well, I have nothing against competitors. It's a good thing to have competitors raise innovation. And they never, we never hear from them. Never once. This wholesale thing broke with multiple currency. No. It has been working fine since 2014. And this add-on product, working since 2014. And this User Role, working since 2014 and never wrote a line of code with that. So why didn't break? Because we work together to prevent it. So this is the idea.
And the biggest resistance is again, that they have to approach somebody. That could be Mendel. That could be Matt. "Let me tell you why you should do more work to save me work." And this is actually how it comes across sometimes. Say, "Why would I even talk to you?" Like, "I don't want to do extra work." And then they realize that if you listen to me, it's very little work because it is. Objectively, it is. You do this, you write this 10 lines of code, you forget about them, and you reach a broader audience, which is easier to answer your customers, "No, they're not compatible. No, they're not compatible. No, they're not compatible." So you are actually giving a negative message. You could give a positive one with very little effort.
Some developers are open to that. Some others, not so much. Some of them are still fairly, let's call it conservative. As we put it, we always did like that. We don't want to change the product. Okay. Don't change it. Can I tell you?
So sometimes customer ask me, "Can you write an integration with that?" "Yes, I can." there was Amelia Bookings. It's becoming very popular. And I wrote an integration for a customer, which took about 16 hours to debug the code, to investigate the code, and exactly 25 minutes to implement. And again, implement and forget. Do like, he will never have to touch it again. Why? Because it will not. Unless the Booking plugin changes significantly, it's one line of code. It one filter. We just have to find a way where to put it, because it was not very well documented at the time. And then we discussed the solution with the author of the Amelia Bookings. Now they have a knowledge base. They put it there in their support team. So the support question doesn't come to me anymore. Again, they just ask them. They give them the snippet. It works.
A good developer is a lazy developer [44:47]
So a lot of the work is not handling issues; is preventing them. So this is my philosophy as I always tell my trainee, the juniors. I said, "A good developer is a lazy developer. Why? Because you don't want to do things twice. You're too lazy to do things twice, so you do them right once and prevent problems from the beginning." So it sounds like a contradiction. If you're lazy, how can you work properly? You work properly precisely because you don't want to do the job twice. So it's difficult to get into the mindset, but then once you have a network, and this is one of the thing that basically saves my bacon as you will say, is that I'm in contact with everybody. And some of people are more pleased than others to hear me, to hear my voice or read my emails, but there is a network now behind the solutions that you see, and that's why they are so successful.
Mendel: You should change your Twitter name to the outspoken engineer, right? Because everybody knows they've heard from you, they've heard some of your feedback, and it sounds like you've really done a great job getting out there and going from zero to, with no knowledge of how to build things in the WordPress or the WooCommerce ecosystem, to providing a lot of value out in the world. So I think that there are a lot of people that are probably very happy that you've taken on the challenges that everybody else would've had to take on if it hadn't been for your help. So that's super awesome.
I wanted to give you a chance to just let people know as we wrap up the show today, how to find you so that they too can communicate so that you can create some more collaborations with other people out in the world as they listen to this and probably have more questions for you.
Diego: They can always find me through my website, which I also have my other contact details, which is aelia.co. It's CO because the com was taken by a shipping company. And they are not using it. It's in France. I was in front of their headquarters asking if they wanted to sell it to me, but they didn't. So it's aelia.co.
Mendel: I have faith that in a couple years, you'll have that domain. You'll convince somebody. You'll know somebody that knows somebody that can convince them. What is your email?
Diego: My email, it's Diego@aelia.co. I always say CO because call people on this account. So Diego@aelia, it's A-E-L-I-A for the no Latin speakers, dot CO. And it's my personal email, which I can't use for support for multiple reasons, because we have a support portal for that. And I am also on Twitter with a handle that my children gave to me. My little girl who has called me the dad that makes business. So I'm businessdad on that. So on Twitter, I can be found as businessdad. And maybe my daughter were here. I haven't seen her in two years because of sad things, but I hope she will see and she will hear this. And yes, on Twitter, I interact with people as well.
And I'm also part of the WooCommerce Help & Share Facebook group and the WooCommerce Community group. I interact with users that have normally difficult questions because there are plenty of other developers that help them. So when I can, I help them there too. I am part of the... and many other Meetup groups, like WooCommerce Austria, WordPress Austria, London. So if you look for my name Diego, you will find me very easily. If you look Diego WordPress, you will find me on LinkedIn. You will find me on Twitter. You find it everywhere. So I'm a bit like parsley. I go on every dish, except pudding.
Noëlle: Diego, thanks so much for being on. It was a pleasure chatting to you and learning more about what you do.
Diego: Pleasure to be your guest.
BobWP: Hey everyone, thanks again for tuning in to today's show. I would like to give one more shoutout to our two Pod friends. When looking for some exceptional Woo plugins for your clients shop, do check out IconicWP.com And don't miss the free online workshop on by Yoast on Nov. 4, "How to optimize your product pages for Black Friday”. Just find their events on Yoast.com.
And of course you can always stay on top of our episodes by subscribing to Do. the Woo on Apple Podcasts, Pocketcasts, Google Podcasts or your own favorite podcast app. So until next time, keep on Doing the Do. How to optimize your product pages for Black Friday”.
Sign up to receive email updates
Enter your name and email address below and I'll send you periodic updates about the podcast.