Being a Web Developer these days means you're presented with lots of tools, frameworks, and libraries to help you work. But where do you start? How do you know what to learn? And do you need to know it all? In the Season 1 finale, Brian Richards joins Joe to get deep in what tools there are and how you can decide what to learn.
Joe: (0:01) Hey everybody and welcome to another episode of Next Level Ops a podcast that explores tools, tips, and techniques for hosting and managing websites presented by Plesk. I'm your host Joe Casabona and this week I am so excited to share a conversation I had with my good friend Brian Richards about tools for the modern web developer. Now Brian and I are both web developers, mostly front end I think, probably, well definitely for me. Brian dabbles a little bit of both, and we've been thinking a lot about how the tools have been changed or have changed over the years. It can be pretty daunting if you want to start today or if you're ready to go to the next level but you're not sure what tools you should invest your time in. Well Brian and I, mostly Brian, helps clear up all of that for you. So, before we get into that conversation, a quick reminder, please subscribe to this podcast to get the latest episodes as soon as they come out. You can do that wherever you are listening to this podcast right now. So be sure to subscribe and let us know what you think of the show. All right. Now let's get on with it.
Jpe: (1:22) Hey everybody and welcome to another episode of Next Level Ops, a podcast presented by Plesk. My name is Joe Casabona and I am here with my good friend Brian Richards. He is an independent web developer who is running WPSessions. Brian how are you today?
Brian: (1:41) I am doing swell Joe. Thanks for asking and how are you doing today?
Joe: (1:45) I am also doing very well. Always a pleasure to talk to you.
Brian: (1:52) Likewise.
Joe: (1:53) Yeah. So, we’re going to be talking about modern tools for web developers today. I was tasked with finding a guest and I thought no one better than Brian Richards. Not only because we used to work together at an agency working on websites for Fortune 100 companies, but Brian also runs WPSessions where outside of building the website, he interviews web developers about important topics, tools, techniques, and things to help web developers grow. So, I think that we are well-positioned to talk about that stuff here. Is there anything else I missed in there Brian?
Brian: (2:37) I don't think so. No. That’s a fairly comprehensive introduction. There’s a lot more than I do that's totally un-relevant to this irrelevant even.
Joe: (2:49) Both. Both a little bit. So, let's start off. We are going to talk about modern tools for web developers and I think that the best way, we were talking about before we hit the record button, to structure the show is Brian and I will talk about our toolsets for web development and then we’ll talk about how you, you the listener, can level up, find good tools and the general philosophy behind finding that next thing to learn or that next tool to use. So Brian? What are you currently using in your web development toolkit?
Brian: (3:23) Well let's start with the most core aspect here to our religion of web development. Let’s talk about the code editor. I am currently using VSCode which has swept the world probably because it's free but also it is really well put together. Prior to VSCode I was a staunch fan of Sublime Text. I was using Sublime Text 3 specifically and I loved it because it's super extensible. You can just bring in whatever extensions you need it to change the behavior. That's amazing for a code editor and pretty commonplace for code editors for like the last decade. VSCode took this a step further I thought by automatically recommending packages based on what you're trying to do. for example, not too long ago I opened a CSV file and VSCode said hey! Would you like to install this extension that adds highlighting to the CSV file? I said yes and that was beautiful! But it also has a lot of the things that I had to bring into tools like sublime text built in. For example, code linting. And if you're listening to this and you've never heard of the phrase code linting I am so excited for you because everything in your development life is about to get so much better. I remember the first time that I discovered code linting and it was years into my development career, and I can't imagine going back now. To give you a definition for anyone unfamiliar, it helps you find errors in your code as you're writing your code. It will show you where you’ve inserted an illegal character to break your code and depending on the language you're working in, some of them are quite a smart PHP only recognizes that something is broken when it tries to execute the next line which makes a little hard to debug. But also depending on your settings will warn you about compatibility issues like when you're writing CSS. It says hey! This might not have great browser support or hey! You're using the important flag. That’s a bad idea. Maybe you should try rewriting the CSS to be a little bit more restrictive or a little bit more forceful without using that tag. So, code linting is amazing. There is a package for Sublime if you're still using that and lots of other code editors. The one for Sublime is called Sublime linter. For VSCode (it’s been so long now) I think it's built-in. But if it's not, you can search the extensions for linters. I know for sure you need to at least add the different packages you want to use for linting the particular code that you write. That part is not baked in. VSCode is for all kinds of languages and all kinds of purposes. But first and foremost I recommend that you find a code editor that you love and then even more importantly than that, you configure the code editor that you're using to do the things that you hate and to be more productive for you by changing the short codes and adding code completion and formatting things into the mix because those few changes will make any code editor better than the best code editor for you.
Joe: (6:49) Yeah absolutely on all accounts. I also use VSCode. I am a big fan of it. One of my favorite things is that since VSCode is made by Microsoft and Microsoft owns GitHub as it has a pretty tight integration with GitHub you can like save a file and then it will like commit it a repo which is pretty neat; or at least like save it and then you can commit right from the editor. And then there's like a lot of visual stuff which I'm sure we’ll get into Git later, but I'm a I'm a very big fan of VSCode. You mentioned linting, which I thought is really powerful. When I first learned Java, as I went to school for computer science and that's what we learned, we had IDEs that would kind of do that. The real-time syntax checking and compiling not built into every text editor, but I mean the linters like you said, based on how you configure it, right? It’s very flexible to use. Like with a CSS linter you can even check to see if like your properties are alphabetized and stuff like that. Am I making that up?
Brian: (8:13) No. No. That’s for sure. We worked at a place where we had to alphabetize our CSS properties which was my least favorite way of organizing them. But yeah, you can configure it to say like this is out of order. If you also are a big neurotic, the way I've configured mine is to wait 500 ms after my last keypress and then check if things are wrong. You can have it wait 0 ms, at which point you will want to light things on fire. So, I don’t recommend that. You could also have it be more delayed or just have it check on saves every time you save the file. If you're someone who compulsively hits command or control S to save your work as you go, like I am, that's basically as good as waiting a half a second. Essentially you don't want to be interrupting your thoughts as you’re trying to type. I'm sure we've all encountered forms on the Internet like this where you’re starting to type your email address and it’s like you need a valid email address, you need a valid email address. I’m like, I know that. I'm only two characters in. Chill out. So, also an aside, if you're making forms like that please also wait until the person has stopped typing before you tell them if they're correct or not so you’re not interrupting them.
Joe: (9:33) Yeah. Maybe like when the focus leaves that particular form field.
Brian: (9:36) Right.
Joe: (9:37) It’s reasonable to assume they're done or they think they're done.
Brian: (9:40) Yeah. So yeah, configure your linter the way you like. Configure the rest of your code editor the way you like and everything else is largely relevant. It doesn't really matter which code editor you use, which might seem like heresy. I've tried a bunch but just find the one that works for you and stick with it and ignore people who get excited about the next one and the new one. It took me two years before I tried VSCode out, not because I was reticent to do so, but because by that point, I had recognized that we as developers are often looking for the new shiny thing. Like ah yes! This will improve my workflow. This will make things better for me only to realize like I spent a day and a half reconfiguring this new code editor and guess what? I'm still just typing characters into an input on my screen. That part of the work hasn't changed at all.
Joe: (10:34) Yeah. I think that's a really good rule of thumb for everything, right? Because we do as developers like the new shiny. I was on Atom before VSCode and I can't remember what I was on before Atom, but basically every time there was a new text editor, people I either worked with or people in my coworking space are like have you seen this? No. I literally just switched to Atom. So, I switched when I became frustrated with whatever tool I was using. I think the same thing goes for like JavaScript libraries. I learned Angular and then a friend of mine who told me learn Angular who was like check out Ionic. Check out React. Check out Gatsby. I’m like maybe I'll check these out when like I need to check them out.
Brian: (11:25) I have a very common rule of thumb when going to investigate a new library. That is, until it is old enough to drive I'm not going to use it. Maybe not that extreme. 16 years ago, I would not pick up a library now; a web-based library from 16 years ago and start using it with excitement.
Joe: (11:49) How old is JQuery?
Brian: (11:51) It's closing in on that actually. I wouldn't sneeze at JQuery honestly. I don't use it, but if I needed to, I could dust that off and put it to work in my site. But in general, waiting at least two years before adopting a library is very helpful. I’m talking from the perspective of things that you're going to be maintaining for a long time. This is very true in Enterprise Based Web development, where Joe and I worked. This is also true for any client work that I'm doing. I don't want to put something brand spanking new in there and then find out that there are weird problems or that it has been abandoned when I need to come back in a year or two to make changes for a client. I’d rather pick something that has been supported for the past two years at least and seemingly going to be supported for the next couple of years. But even if it's not, recognizing that ok, this is well-established and anything that comes along brand-new after this is probably going to have guides for a migration path. Of oh! You are doing all of this in React? Well here's how you could do it instead using this tool. It becomes a lot easier, less costly to make those decisions. That is what I try to optimize for.
Joe: (13:09) Yeah. I think that's a really good point. I mean the same, you know if you see like these bigger projects or bigger organizations investing, I think React is a good example, right? Because React is something that Facebook has invested heavily in. It’s open source but now WordPress has picked it up and so it is less likely to be abandoned if these giant projects are using them. You know? I can't remember the last one that somebody recommended to me, where I am like this is probably going to be gone like tomorrow. But I don’t know. It’s funny that you mentioned JQuery. JQuery for me, my workflow for JQuery is always I’m going to write this in vanilla JavaScript. And then like a half hour later after not getting it right, I'm like I’m just going to use JQuery, which I should've done in the first place.
Brian: (14:03) JQuery turns 14 this year.
Joe: (14:07) Crazy.
Brian: (14:08) 14 years old.
Joe: (14:11) Wow that's wild and it still is pretty heavily used like everywhere. Great. Great. Well we started talking about libraries, but you mentioned your code editor. What one other like computer-based or like local based tools maybe are you using?
Brian: (14:33) I will I will rattle off a few. And for you listeners, I wouldn't take these necessarily as prescriptive. Like if you're looking for what tool should I use for doing this thing here is a good list. If you're listening to this years after the recording, which seems unlikely if you’re for looking for modern tools, just know that there is probably something that has replaced these or these are probably still good. So VScode is my current code editor. Sublime text was my code editor before that. Who knows what I’ll be using a few years from now. Hopefully I follow my own advice and stick with the VScode. So that's what I use for doing all of my code writing. For doing things like code cleanliness and like checking that my code is following standards, for PHP there's a tool called PHP code sniffer that makes sure that I'm following whatever standards are in place for the projects that I'm working on in the teams that I'm working with. PHP Mess Detector is also a similar but different kind of tool for checking the complexity in your PHP. And there are similar tools for JavaScript and for CSS that I don't actively use and I’m going to be honest with you, I don't have to write a lot of this stuff from scratch for the work that I'm doing currently. I haven’t followed along too closely with those. In most cases, if you're picking up a library, I recommend adopting whatever practices that library follows so that your code matches their coding styles. And it really doesn’t matter what your coding style is, as long as it is consistent because that is the number one indicator of bug density in code actually, is consistency and how you write it and format it. A bunch of studies were done a bunch of years ago that showed that people who are inconsistent in even just like the way they space their code, are more likely to have errors hidden in the code because they're easier to miss. They’re less obvious. So, adapt some kind of coding standards and just follow them. It doesn’t matter what they are as long as you follow them. They should hopefully help you avoid running into bugs.
Joe: (16:49) I like that. It’s almost like, there's a story, I think it's either Van Halen or Bret Hart or something like that. Bret Hart was a wrestler. Bret Michaels.
Brian: (17:03) There it is.
Joe: (17:06) One of those bands always had in their rider that they required like red M&Ms only. Do you know this story?
Brian: (17:13) It’s very common in the world of roadies and audio culture. They would request (I believe it was green M&Ms). It was just like a quick litmus test to see did the place where they were performing follow everything in their rider contract? And if those green M&Ms were missing, then they are doing a full check of everything else because they probably missed something else. That one is such an absurd standout request that you should at least get someone asking about it, if not just blindly following it.
Joe: (17:49) Because they would like pyrotechnics and other things. Like there were safety issues.
Brian: (17:53) Right. Exactly.
Joe: (17:54) They want to make sure that everything was red. Anyway, sorry. I wanted to include that because I love that story.
Brian: (17:59) Yeah, it’s a fun one. So, for source control I use Git. I think it's basically one, SVN is still kicking around, Mercurial has seemed to reach end-of-life. Git is ubiquitous and convenient. Some of the command line tools are a bit esoteric but it gets a job done. It does everything that I want to do. So, Git is wonderful. With that, I use GitHub which has continued to get better since Microsoft's acquisition. They are now essentially free for everybody. Free for individual accounts, free for teams to contribute and they have baked in tons of great stuff. The thing I'm most excited about currently are the GitHub workflows. So, you can trigger something on commit. When a pull request is opened, all sorts of different actions that can be taken within GitHub can trigger a workflow to do things. So in the WordPress world, if you're a plug-in developer and you’re releasing the plug-in publicly to the WordPress.org repository, there are tons of workflows that you can tap into so that when you push a new tag to GitHub for instance, it does all the bundling of packaging and shipping things straight to WordPress.org. You don't have to worry about also mirroring your work there, which is brilliant. For doing things for regular websites, this allows you to bring in continuous integration and continuous deployment. Running things like I mentioned PHP Code Sniffer, like that can be run on a pull request automatically and let you know other kinds of tests for integration testing or even unit testing can be run and flagged before you merge the code to master and deploy it. And automatically handling the deployment for you once you’ve tagged to release or push something to master, or whatever the workflow is, it’s brilliant! Prior to this, my most favorite part of GitHub was how well is supported peer review. So, you create some code, you make a branch, you share that branch or a pull request with your colleagues and they can comment line by line or on groups of lines, things that should change and be improved. And that has also only gotten better over time. Nearly real time responses when someone posts a comment to when you see that comment as feedback in your pull request. It’s bananas how well that works.
Joe: (20:34) Yeah. That's really fantastic. Is the WordPress plugin repo like driven by Git now?
Brian: (20:40) It is not. Nope. The WordPress.org plugin repo is still SVN which makes it even more impressive that these GitHub actions can trigger the deployment from Git to SVN to the WordPress.org repo.
Joe: (20:53) Yeah that's bonkers and amazing. One of the reasons I haven't made more open source plugins, aside from time, is just like SVN. I don’t know.
Brian: (21:03) Changing workflows midstream. Yeah.
Joe: (21:05) Yeah exactly. Cool. So, I think that there are a lot of really good tools you mentioned there. VScode, Code Sniffers, PHP code sniffer…um…GitHub and other source control.
Brian: (21:20) Yep
Joe: (21:21) Yeah.
Brian: (21:22) One more area that I want to touch on real quick before we shift gears is just your local development environment in general. How do you build stuff for the web when you are off-line? There are tons of tools to help with this regardless of what platform you're working with and where you're working. If you're in the modern JavaScript space, you've probably heard of most of these and are already using them. For what I do, I really love Laravel Valet for taking one directory on my computer and making it accessible to my browser. So, I took my sites directory, in that I made a www.directory and then any directory that I put in there becomes accessible as whatever the directory name is .test is what I chose for my TLD. So, I could have WPSessions.test as my local environment. This all happens automatically. All I need to do is make a folder and put something in that folder and I can access it from my browser via HTTPS even. So, Laravel Valet makes that super easy. You basically just type valet park in whatever that root directory is, and every directory you add to it gets to be his own domain. Zero additional configuration needed and it’s magnificent.
Joe: (22:40) That’s awesome!
Brian: (22:41) Yeah. There are loads of other tools that I've used over the years and things that are very specialty built like local by Flywheel for spinning up just a WordPress local instance and making it accessible at whatever URL you want. That's pretty cool and there are all kinds of other tools like those. Lando is kind of like Laravel Valet but also configurable. So, you have a file that you put in your project so that your coworkers and colleagues who are pulling down the project can then spin up a Web server that fits the exact specifications for that particular project, which is a lot like how Vagrant works. But it is a bit more lightweight and faster to use which is pretty neat.
Joe: (23:28) Vagrant is still like a just a black box to me.
Brian: (23:34) Yeah. It's a bit of a behemoth.
Joe: (23:36) Yeah Laravel Valet sounds amazing. I know our mutual friend Tom McFarland has recommended that before. But I was liking local by Flywheel. I actually have a blueprint, which is like a template in local by Flywheel for non-WordPress sites. So, it just like spins up something; no database, no directory. But Laravel Valet sounds better at least for non-WordPress development because that's real nice. Awesome! Well ok. So cool. So, we talked about doing the stuff on the computer and writing some code. Before we get into the how do we pick, where we learn from, are there any other tools or tips you want to mention here?
Brian: (24:24) Maybe one more passing one is becoming familiar and loving the command line. When I started, I couldn't string two commands together and now I love working inside the command line. The shift happened when I realized that I could customize a terminal window similar to how I customize my development workflow. So, on my Mac I stopped using the built-in terminal app and switched to iTerm 2. And there are lots of other apps that you can find. I like this one a lot. I switched to using Zshell instead of bash, which is now the default actually in Mac OS. Also, terminal has made its way into Windows which is fantastic. Then I did some things to enhance it. Most notably using Oh My Zsh, which is a library for Zshell that adds some better tab completion and checking if the command you’re typing is a valid command even before you press enter and realize like oh no! Nothing I typed there is going to work. I have to start over. And then combining it with tools like Homebrew for easily installing packages that I need for web development which is so much better than trying to install them separately and then … I could talk for hours just about command line interaction. So, I'll stop here. Switching to a custom terminal app like iTerm 2, using a different shell specifically, Zshell for better completion and just all kinds of really nice stuff for actually interacting on the command line. Then a tool like Homebrew for quickly installing packages and updating packages so you can bring in things like the exact version of PHP that you want to work with, or the exact version of an npm that you want to work with, or Ruby, or Xcode or whatever. It’s just a really nice package manager.
Joe: (26:27) Nice. Ditto on that, on everything you just said. And as an added bonus if you're doing work in public, people look at you like you have like a superpower. But that is neither here nor there. Awesome. So, with our remaining time, we have about 10 minutes left, let's talk about the philosophical side of things, right? Because as you mentioned there are a lot of tools there's a lot of stuff to learn. Back in my day all I needed was HTML, CSS and Notepad. That's not really the case today. So how do you kind of pick and choose your battles or what to learn and what to invest your time in?
Brian: (27:06) Yeah. So, I am of what I think is the minority, but maybe not the minority, in that a lot of the modern processes and tooling that we brought into web have actually made things worse. Like we are actively purposely, maybe not purposely, but we are actively making things worse by bolting on things that should be making things easier. Build tools, like using NPM and all the packages that you can get from NPM are a great example of this. It is a common trope to say like oh. Just delete your node modules directory and start over. And if you try to navigate that directory, it's miles deep of things that you said that you need that brings in the things that they need and inside of those they’re referencing other things that they need, all the way down. But one of the benefits of working with a package manager is that it really makes it easy to spin up a new package, I’m sorry, a new project, because of all of the things that you might need for that project can just come along with you in a config file. So, there's a trade-off there where you get a lot of convenience and you can also trigger build processes for automatically for example taking your JavaScript and minifying it and compressing it so that it’s a tiny package that gets shipped out to the web. That's amazing! Or tools like Gatsby, which is built on top of React, which takes what was otherwise a dynamic website and making it a fully static website, or a pseudo-static website. Just recently Gatsby released what they call incremental builds where only the things that have changed from your Web server, perhaps a private Web server, is what gets rebuilt and redeployed statically as basic HTML, JavaScript, and CSS. Which is huge! It means you can take a site that has thousands of pages, or tens of thousands of products and serve it all statically; with no database, with no expensive infrastructure, and with no caching processes necessary. It's brilliant! So, my general philosophy is to use as little stuff as possible. You could for sure still write HTML and CSS in Notepad and sprinkle in a little bit JavaScript and ship that to the web. At least I assume Notepad is still available in Windows. Maybe you actually can't. Maybe Notepad is not available. But you know, just a basic text editor.
Joe: (29:39) Right.
Brian: (29:40) But using purpose-built tools improves things tremendously. So while I just spent a minute or two downplaying NPM, there's a lot of stuff that is just easier to do courtesy of having it available. You just need to be careful in what you're doing. Be cognizant of what you're doing so that you can best leverage the stuff. Hot reloading is another example. Impossible to do previously where you save a file and it’s automatically updated in the browser. But now you can just hit save in your code editor and in almost real time see those changes happen in your browser with no additional keystrokes or nothing else. It's amazing! So, the tools that you get are handy and can be dangerous. It's a double-edged sword. There’s my basic guiding philosophy; be careful in what you're investing yourself into.
Joe: (30:38) Yeah absolutely. I would agree 100% with that. I'm like super minimalist when it comes to stuff like this. If I see like a bunch of instructions to like get a WordPress theme working, then I am like well I am out. I don't have to install NPM or do some NPM install thing to work with a WordPress theme. Which is, that story is based on a real thing that happened to me and it didn't work obviously. So definitely be intentional. It’s just like if you are familiar with WordPress and you go plugin crazy, like that’s not the best thing to do. Just think about the tools you're using and use the purpose-built ones. There are also great apps like CodeKit. CodeKit is one that is available on the Mac that will do some of the things Brian mentioned like minifying and hot reloading. Like those are all things that you don't necessarily need to mess with like a config file for. Then there are more advanced things but just kind of take it one step at a time, right? Don't like get the whole build tool boat when you're just setting up like a landing page.
Brian: (31:59) Yeah. Get the right amount of tooling for the tasks in which you're trying to accomplish. Then knowing which tools to look for is the entire battle. So, where do you find the tools that help make your job easier? How do you know that they actually work as advertised? Why should you trust them? When can you trust them? I mentioned earlier like waiting a couple of years on a coding library. That’s not necessary if you’re just trying to experiment and learn new things. Pick that up. Have some fun. See how it works. I did a project a couple of years ago where I wanted to experiment with Vue.js, Tailwind CSS, and the WordPress Rest API which were all new then and are not now. I created a bingo site. It generates a random 25 square bingo card with some data that I stuffed in a database. That was the Rest API piece and styles it to look like a bingo card, keeps track of which squares you have selected, lets you know if you won at bingo or not and the appropriate times. It’s a great way to experiment with a library in a very low risk fashion rather than like hey! Let's try to use this on this project. Have you worked with it before? Nope, but how hard could it be? Pretty hard probably.
Joe: (33:18) Yeah. A lot harder than you think.
Brian: (33:20) Yeah. So, finding the library and learning about it, as I said, is the biggest part of the battle. I find things that are useful by following people who are smarter than me on twitter. There are lots of very good developers who are very prolific in sharing what they learn with the rest of us. They are essentially learning in public which is my favorite thing. I try to practice this but I'm also largely embarrassed when I make mistakes and so I sweep those under the rug, which is not useful for people who are trying to learn the same thing as you. So, take it from me, publish your mistakes so that people can see them and recognize like oh ok. Here's a stumbling block. Let me also learn now to navigate around it. So, following the smart developers on twitter is a good place to go. The people that I follow is a great list, I think. So, if you're looking for that you can grab my twitter handle from the show notes. It's risen, but it’s spelled RZEN. There’s a lot of really smart developers in there, and even more that I don't follow that I probably should. Codepen is a really great place to find people doing interesting things on the Internet. Sometimes it’s a great source of like here's an example that I can use often a great source of wow! I didn't know that was possible! How do they do that? Oh, that's cool. That triggers entirely new ideas for you and when you're working. Websites like CSS-tricks and frontendmasters are really great for finding new information and learning how to implement different things. So, that's usually what I do I. I am like who’s interesting. Who’s doing neat stuff. What are they doing? Who are they talking about? What's their source of inspiration and then falling down that rabbit hole and then going maybe I should open my code editor tomorrow and try some of this.
Joe: (35:19) Yeah. I love that I will link to all of that stuff in the show notes over a Plesk.com/podcast. But if you are like me, you like books. Books are maybe not the best way to learn web development, but at least the newest and latest web development. But a Book Apart is a really fantastic book series. They're very short modern books, single idea, less than 100 pages. I'm a big fan of that book series, so if you’re looking for good books that's a good place to go.
Brian: (35:57) The book Clean Code by Robert C Martin is something I recommend constantly. It's another thing that I read way too late in my coding career, ahh not too late but way later in my career, that I wished I would have found earlier that dramatically improved how I approach writing code and expressing thoughts and ideas via code. I could not give it a higher recommendation. If you only read one book about coding, I would recommend that it be Clean Code by Robert C Martin.
Joe: (36:30) Yeah. I had to read that for school, an excellent book there. So, I have one thought before we close out about publishing your mistakes. I think that this is really important to do. I gave a live workshop where I upgraded my e-commerce site to WordPress 5.0 when it was in beta to show people what the upgrade process was like and I completely fell on my face. Like it didn't work even a little bit and it wasn't working at the end of the workshop. But what I did was say this is unexpected. I made it very clear was doing this live and I hadn’t done a test run. I just talked through my thought process. What am I doing now? Why am I doing this? What am I checking? Then I did a follow-up video later on what actually happened. I thought that I…well… I just lost that whole audience. But a lot of people wrote to say hey great job! This was even more useful than if it was like a super clean upgrade because we saw what could go wrong and how we might troubleshoot it. So, publish your mistakes. Learn in public. I think that’s great advice.
Brian: (37:50) Amen!
Joe: (37:51) Awesome! So, we are slightly over time which is to be expected when Brian and I get together and talk. But this has been great Brian. Where can people find you?
Brian: (38:02) So, I already mentioned my twitter handle twitter.com/rzen. You mentioned I run WPSessions.com. The WP there stands for WordPress though the content isn’t exclusively about WordPress. It's for people like me and Joe who use WordPress who need to broaden our minds and also learn about other aspects of web development. And then through that, I run a couple of virtual conferences. One is called Wordsesh.com for WordPress professionals. The other is called Woosesh.com for
people who work with WooCommerce.
Joe: (38:39) Awesome. Well thank you so much for joining us today. I really appreciate your time.
Brian: (38:44) I am glad to be here. Thank you for inviting me.
Joe: (38:48) Thanks so much to Brian for joining us this week. I loved this conversation. Obviously, Brian’s a good friend but I also loved talking about web development tools and so we both kind of got to go through our own toolkits and things like that. So, I hope you really liked this episode. For all the tools that we talked about and more show notes you can head over to Plesk.com/podcast. If you liked this episode, please consider subscribing. Give us a rating and review on Apple podcast because it really helps people discover the show. Thanks so much for listening to Next Level Ops. Until next time, remember to take it to the next level.