Brendan: Hello, and welcome to PodRocket. I'm Brendan, I'm on the engineering team here at LogRocket and joining me today is Chris Weichel, who is CTO of Gitpod and one of the hosts of the DevX Podcast. I love developer tools, but I guess makes sense working at LogRocket. And so, I'm really excited to hear what you're doing at Gitpod and some of your thoughts about the developer experience. Chris, thanks for joining us, how are you doing? Chris Weichel : Great. Thanks so much for having me. Pleasure to be here. Brendan: Maybe before we dive into Gitpod and all the nitty gritty, goodness there. Tell us a little bit about yourself, and your background, how you ended up at Gitpod, and what attracted you to the problem you're solving there? Chris Weichel : So my name's Chris, based in north Germany, and that is also how I ended up at Gitpod. I came from... My previous gig was at a startup at Bosch, building IoT devices, and I was looking for an authentic startup experience, like a spinout that comes out of a multi billion business. It's just not the same as five people in a room. And so, I ended up joining a company called TypeFox at the time, from which we then spun out Gitpod two years later so, that was about two years ago. And so, this is how I ended up at Gitpod. Brendan: And you were, I think one of the first couple of employees there, kind of just starting from the ground up, what was that early days experience like and what has it been like to watch the company grow over the past couple of years? Chris Weichel : Yeah, that's right. When I joined, it was basically the second engineer on the team dedicated to building that product, the prototype at the time. It's been really exciting. We started with really essentially a few people in a room and have since grown to 65 people spread across 22 countries with teams that have 16 hours of time zone difference within the team. Well, depending on which direction you count it. So massive changes, but really, really exciting. Brendan: So, you must be... I mean, you're all in on distributed teams and global scale. That must be a real challenge from a process perspective to help teams with that much spread work effectively together. Is there anything you feel you're doing that's working really well that makes those teams effective? Chris Weichel : So, I think it's getting that trade off between async and synchronous right. So, we really put a lot of emphasis on asynchronous work. And at this point it's really turned into a superpower because we write so much down, onboarding folks is easier, and it also means that discussions get actually more effective. It's just more effective if you have people write down their thoughts ahead of time and then bring them in a room rather than have everyone in a room devolve into a former group think and not come out the other end with any actionable conclusion. So, getting that trade off right and having people write things down, and at the same time knowing when it's time to bring people in a room, because there are situations... Your production's on fire, you got to solve that. You're not going to be writing notes and docs. You're going to be sitting in a Google Meet and they're going to be solving this out together. So, knowing when to pairing people together and when to write async that's really is really key. Brendan: Yeah. And, and I think at LogRocket, that's something we've thought about the distinction there too, and tried to build more asynchronous processes as we've become a remote team during COVID. And I think one of the other things that's valuable there is it lets people who don't already have all the context, do research and read and get up to speed and contribute to something that maybe if it was just a half hour meeting in the room, they wouldn't have enough context already in their head to contribute to that conversation. Chris Weichel : Absolutely. It also makes the entire process much more inclusive just because we are separated across well, time and space. You don't get these opportunistic encounters where you bump into each other on the hallway and you have a conversation, "Hey, we're working on this." And you don't get that. So by writing things down and we have a policy where pretty much all documents are open within the company. And so everyone can go and read up on what's happening at their own commons and become part of the conversation if they want to. Brendan: And obviously, as CTO, obviously you are playing a big role in setting this vision for the engineering team and the product. What does your role look like? And what do you do day to day? Spend time on podcasts? Chris Weichel : Yeah. I spend time on podcasts. It is a wild mix, really. So, I come through the ranks, so to speak. So there is still a lot of IC in me. And at this point it's almost an indulgence to go and do that because more often than not, it's not the most impactful thing I can do with my time. That said, I do make a point to spend at least a day per week to really get into the nitty gritty of code. Other than that, I usually start my day catching up with what happened in the other time zones while I was asleep, going through Slack, emails, PRs, understanding that. And then there is a lot of context. So I think a good part of my role is distributing context and ensuring alignment. Chris Weichel : So making sure that the left hand knows what the right one is doing, and then making sure that teams who should be talking to each other are talking to each other. And also not just by me spending my time on bringing folks together, but also through organizational development. So a good part, I think, of the role of the CTO or at least at Gitpod part is connecting the technical with the organization. You cannot build technology without the people and you have to evolve both at the same time and getting those things connected I think that's the key bit. Brendan: Speaking of building a product, let's talk a little bit more about Gitpod. What's the pitch? If I'm a developer, what does Gitpod, let me do that's that's hard right now and how does it fit into my team's workflow? Chris Weichel : Gitpod takes the pain out of setting up and maintaining a development environment. So before you can get to working on code, before you can get to building or fixing whatever it is you need to do prior to Gitpod, you would need to download a bunch of tools, you would need to sit there and wait for yarn to download the internet. You would need to build your code, run your tests, and then you might be able to start working. And then you figure out that your code extensions outdated, and you got to go and update that. So there is all that pain that comes with setting up a properly working development environment. Chris Weichel : We've all seen those super outdated READMEs when you join a new company and you go, "Ah." Yeah, this doesn't work like that anymore. We're not doing that Gitpod takes essentially that README and turns that into code, which means that within literally within seconds, you can get a fully working development environment on pretty much any project that includes the tools that you need to work. That includes the tasks that you need to run, and those tasks can even be run before you open your development environment. So by the time you're ready to work, what used to take three days now takes 30 seconds. Brendan: And so if I'm a developer, I have my existing local dev setup, it's crusty and frustrating for whatever reasons, what do I have to do to get it running in Gitpod? Am I encapsulating this in a Docker image? Is it like more of a build spec that I write just to define how to build and run an environment? Like how does that set up work? Chris Weichel : Yeah. The Docker image is spot on so that's a good part of it. So, what Gitpod will give you is essentially a container running in the "cloud." And the... A good part of that is the user land that you bring, which is essentially a Docker image. And you can bring your own, you can have Gitpod build it, you can use one of the ones that we provide. On top of that though a good part of good part is that it's contextual. So you say you go to github.com, you go to a PR that you want to work on, you prefix that URL with gitpod.io/#, and then Gitpod knows that you want to work on this PR. Chris Weichel : So it's going to clone the code from that branch. It's going to run the tasks that are relevant to this branch because the configuration lives alongside of the code, it's going to use the right tools again, it's basically pulling the right Docker image. And so, a good part is this combination of the tasks that you want to run and the Docker image that you want to use combined with the contextual part that Gitpod brings. Brendan: And so, one of the things, that's always, maybe not challenging, but just a workflow frustration with, you've got a poll request review to do. You're also working on your branch locally and you have to, maybe there's a database scheme by migration in the poll request. And you have to pull that down and get that running. Then go finish that review, go back to your code that you were working on to begin with. And it sounds like part of Gitpod's value prop is that basically can take that problem away from you. That you can just get a local environment for a branch without disrupting whatever you're working on. Chris Weichel : That's exactly right. So Gitpod's... We don't want to prescribe the ID that you're using. One of the IDs that we offer is VS Code in the browser. It's not the only one. And you can do this with any IDs. I just choose to use VS Code in the browser. And so on any given day, I'll have 10 tabs open. Each of which is an individual development environment set up for this task. And once I'm done with that task, I'll just close the tab and forget about that workspace. We call those ephemeral workspaces. So, you create a new one from scratch for the task that you want to work on. And afterwards you're just going to throw it away. And you're never going to worry about that environment again. Chris Weichel : So there is no conflict drift. If I mess up some Git operation, chances are I'm just going to close the tab and try again. And so, you also don't have these context switches that you just mentioned, where you would need to update your local working copy and then make sure that your tools are still correct. And that all other state that you need to still correct, all of that stuff just goes away. It's essentially a tab in your browser or well, a session in VS Code on your desktop and a saved session, JetBrains, whatever you want to use. Brendan: Right. And especially, I guess, for people who aren't just writing code all day, but who are maybe in roles, whereas you said getting to touch the code and get into the details as more of a luxury in your day to day. Keeping that environment up to date gets more challenging when it's not what you're doing all the time. And so that's an easy way to jump into the code, see what you want to see, review something, leave your thoughts and then jump back out and know that you don't have to leave that environment behind. Chris Weichel : Absolutely. So not just for the developers that really need to get into the nitty gritty and really hash things out. Also, for folks like I just want to quickly browse the code base. I'm just going to open a Gitpod workspace. I'm going to search through my stuff. I have full language service support. It's a proper environment, right? So I can easily navigate my code. We've also seen QA people loving this because if they need to reproduce something, they get the same environment that developers get and they don't need to fast with setting this stuff up. They're getting a link clicking on that and they're ready to go. Brendan: So this seems really cool, really powerful. Must be really complicated behind the scenes to make this all work and to make it feel seamless from the perspective of users, how does maybe at a high level that we can fit into a podcast time length, but how does this all work behind the scenes? What is the core technologies that you're leveraging here? Chris Weichel : So the... At its very cool it's Kubernetes. So essentially a workspace is a Kubernetes pod and then a host of additional tech in between to make that reasonably secure and also to provide functionality that you wouldn't ordinarily find in a Kubernetes container. So within a Gitpod workspace, you can, for example, run Docker or, you can do things that you would expect to do on your local machine, like sudo apt-get install, something like that. So at its very core it's Kubernetes with, let's say a lot of optimization sprinkled on top, and that's front loaded by this contextual understanding where we can interact with different code hosters, like GitHub, Bitbucket, GitLab, where we can understand what do their URL schemes look like? How do we need to interact with them to understand which context you're coming from. Brendan: I guess, as I'm thinking about you describe that and the challenges' security seems like it must be one of the hardest things to do because like worrying about container escape is something you're thinking about anytime you're giving users any form of control of containers in like a CI or dev environment. Do you have a dedicated security team? Is that something all engineers at Gitpod work on? How do you approach the problem of making sure that it's not just secure when you start, but it stays a secure platform, an ongoing basis? Chris Weichel : That is indeed a good part of what we do. So we're really on top or trying to be on top of specifically Linux, kernel CBEs and within the container space. And on that note this year has not been a good year so far. There's been a lot going on in that space. So we're just really adamant and have optimized our internal deployment process in the way we react to this to be really quick when it comes to, CBE comes out, we got to fix that. And at the end, it's the individual product teams that carry this burden. So we've very deliberately chosen not to make this a central team's responsibility because it misaligns incentives, you get into a situation where the security team basically needs to ask the product teams, "Hey, please, can I deploy?" Or the security team becomes a burden for the other teams. Chris Weichel : Ideally, you'd want to, if you had a security team, and this is a discussion every once in a while, that we're having you'd want to build that team so that they make it easy for the other teams to do the right thing. But that coupled that by not absorbing the other teams from, "Hey, we have a security team. You don't need to partner with that anymore. You don't need to be on top of what's happening." so we very deliberately want to keep that within the teams also because the technology stack that the different teams work on is very different. Some live on TypeScript and Node, others live on essentially the Kernel, others live on Kubernetes, Go. So different areas to cover hard to centralize. Brendan: Yeah. Sounds honestly really similar to how people talk about DevOps teams in a lot of ways, right? That those teams exist when they're done well exist to accelerate and empower other engineering teams versus being the just rebranded analog of the like ops team that you would throw your code over the wall too. And, obviously easier said than done, but I like that parallel. Chris Weichel : Yeah, it's very hard to not even inadvertently devolve into exactly this misalignment of incentives where suddenly you've created this one team and everyone else goes like, "Hey, there's a team." It's called even that. I don't have to worry about that anymore and so it becomes that other team's problem and that other team doesn't necessarily have direct impact and it's not necessarily... Doesn't have enough agency to actually affect the changes they need to do in order to actually solve that problem. And that's just a frustrating situation for everyone around. Brendan: So you've built this platform, you've solved all these interesting security and architecture problems. And now you have customers trying to run their code and run their environments on Gitpod. And there are some really exotic architectures for Git repositories and local development setups out there. I think at LogRocket, we're a little bit guilty of this with multiple layers of emulators and just a whole bunch of things going on to reconstruct our production environment for developers to work on locally. What are some of the interesting challenges or problems that you've had to solve as customers have wanted to run different or more complex or more stateful types of environments in Gitpod? Chris Weichel : It starts with, where does my code come from? Sort of the monorepo versus multi repo, I guess, setup. And both of them come with their own set of challenges. So at Gitpod we run essentially a monorepo and for monorepo you already have the challenge that you might need multiple configurations and then which one do you pick. For a multi repo setup you hardly ever want to work on one repo in isolation, but you want to pull them together and you probably want to connect them with the same configuration in that case. And so for this case, just lately, we introduced multi repo support where you can link multiple repositories and have them cloned into one and have a joint configuration. So, navigating the layout of the different repositories that's one bit that's challenging. The other is the duality between what do I run in production and what do I run in my development environment? Chris Weichel : And most applications nowadays don't fit on a laptop. They're... You can try something like minikube or kind, but chances are your 32 gig Mac is going to burn down non the less. There we've seen two trends so far. One is where folks externalize this preview environment into some other service. So for example, you run, I know, say a GKE cluster and you just deploy to name spaces, and you have some CI process that makes that happen or use something like Okteto or Gardener to set up your preview environments and you connect to them from within Gitpod. And because you can provide secrets and the tools, you still get a great experience that way. So essentially you externalize the heavy lifting into other services, and specifically in the Kubernetes space, this is something that we've seen a lot. The alternative is use something like Docker Compose, or essentially a shed of shells scripts that, duct tapes Docker containers together. So essentially Docker really is essential than if you want to run this within that workspace, and that's what we've seen used a lot as well. Brendan: Yeah. And I guess the ability to connect to external environments also is probably very helpful for things that are data intensive. Where you might have a terabyte of test or staging data that you really don't want to try and seed into your local Docker Compose database, but you still want the flexibility of that preview environment. Chris Weichel : Yeah. We've seen people use, for example, FUSE FS and tying in S3 buckets that way, or using SSHFS, things like that to tie in large external data sources. Brendan: Yeah. So it seems from a strategic perspective that a lot of what you're doing is trying to give customers enough control over their environment, where they have the flexibility to bring in these tools and scratch their itch and solve these really specific or use case local problems. Chris Weichel : That's right. We're very much... Internally the way we phrase that is integrate don't dictate. There is a lot of work that's gone into making developer tools work good on essentially a laptop. So for us, a good surface here is trying to act like a laptop. And so that's also the analogy when we try and explain, Gitpod think you want to work on something, someone hands your laptop, that's perfectly set up for that task. Once you're done, you close the laptop and you hand it back. And then for the next task, you get another laptop that's perfectly set up. And so we want to behave like this laptop. Workspaces should act... You should be able to do whatever you want to do on them. And you should be able to integrate with whatever you want to integrate with. Brendan: Yeah. As we're talking about this, I'm feeling this sense of circularity in my career where, when I started as a developer, I had my one EC2 machine and that was my sandbox. And I would SSH to that machine and I would, check out whatever branch I was working on and that had a database connection. And that was terrible for a lot of reasons. And you had to update your own sent to own packages. And then everything came back local. And we were doing local dev with Docker Compose on our laptops and that's been the last few years. And now it feels with Gitpod with codespaces, like there's a lot of products now that are trying to take development almost back into the remote or sandbox world, but with an entirely new toolkit. I'm curious, do you feel that's being driven more just by the availability of tooling? Is that being driven by the complexity of applications that now people are running and trying to emulate locally? Is that being driven by the changes in development teams or processes? Why are we seeing this trend now? Chris Weichel : I think that really depends on the perspective you're looking at this from. For one, there is the, it's now possible angle. for example, Cloud IDs have been around for a while. We all know Cloud 9, for example, but they haven't really felt like something you want to replace your local environment with. And this is why they haven't seen a lot of uptake, but with the advent of VS Code or Eclipse Theia, the more technology has been created to make something like that possible. Kubernetes also really, like good orchestration platforms are really instrumental to making things like that happen. So we're in this technological, time technology crossover, sweet spot to make things like that happen. The other is we're seeing that exactly the complexity of the tooling that we as developer need to use is growing. And also the tasks that development teams get is ever increasing. Chris Weichel : Like we just spoke about how we expect from our teams to also handle security to a great extent. There is also, Q and A, there is docs, there is even support, there is on call. There are so many things that we expect from developers and product teams that we need to do whatever we can to make their job easy and to be able to live up to those expectations that we place on them. And so reducing this tooling, complexity is paramount. And the third category that's really interesting is there are companies who've for a long time already have run their development in virtualized, almost remote, if you, so like environments, specifically virtual desktop solutions, Citrix and the likes. And usually you would find this in very regulated industries, banking, for example, the finance. And here, we're also seeing a trend where they're trying to move away from these VDI solutions just because they don't provide a particularly good experience. And so they're trying to move to something that is more modern. Something like Gitpod. Brendan: Yeah. And as I alluded to a couple minutes ago, I think this is a space that's starting to get some heavyweight players in it. GitHub has codespaces, which is a first part of offering that hits a lot of the same notes around frictionless developer experience, remote environments. What do you see as Gitpod killer features or key differentiators that set you apart from the other companies in the space? Chris Weichel : Yeah. When codespaces came along, I still remember the day when we heard that this was going to happen. And then when it finally happened, it is actually a really great validation. It validated a lot of the things that we have been doing before. And it was great to see a heavyweight player like Microsoft throwing the weight behind this idea. And so it also helps really educate the market and tell people, "Hey, this is going to be a thing." So in three or four years, if you join a company and they, "Yeah, when you got to install this locally." You're going to be, "What do you mean got to install this locally." It's like, imagine joining a company today, and they're telling you that they're not running CI. You're like, "Wait, I'm supposed to build this on my machine." And it's going to be like that as well. Chris Weichel : So there's been that validation. What differentiates us? First of all, we're, we're truly open source. So we build in the open, the company is very open. All our code is on GitHub. We have an awesome community around, around Gitpod. And so we really come from a lot of... There's a lot of open source pedigree in the company, in the folks that founded the company, in the folks that have joined since. And so we really embrace and are proud actually to be out in the open. And that really is a differentiator like codespaces, this close box, you can buy this, you can give the money, you can get a service, but you don't really know what's going on behind the scenes and you have little impact over what's going to happen. Chris Weichel : There is also the flexibility that you get with Gitpod. We don't need to sell Azure compute. We need to sell you a service that solves your problem. And wherever you need to run this, this is where we try to run. So there's the integrate side on what can you do once you have Gitpod running, but it's also making Gitpod work for you. And so for example, Gitpod can be self hosted. If you need to run Gitpod, say for compliance reasons within your own AWS infrastructure, you can. You can take Gitpod self hosted. You can run that there. Chris Weichel : And then also the whole thing is based on containers. It's based on Kubernetes, it's based on things that people know. So A, contributing to it is easier, but also running it, operating it is easier. And lastly, we're very happy to integrate with any IDE that folks will want to use. We have no stake in the game, so we'll, again, it comes back to integrate don't dictate. If you want to use, Emax use Emax. If you want to use JetBrains, use JetBrains, want to use VS Code be my guest. Brendan: Yeah. You said community, which is a little bit of a magic word for our podcast here. It feels like it comes up with just what everyone we talk to. And I think that's maybe a nice Segway to talk a little bit about your interest in developer experience and in building developer communities. You're hosting a podcast focused on it. It's something you've talked and written a lot about. Maybe if you could just start by telling us, what is your idea of what developer experience is and why it matters and how Gitpod is tied into to that vision. Chris Weichel : So, developer experience is essentially user experience for a specific role. It is the experience that you as a developer have when you do your job, when you do your work and that's more than just, how does that CLI feel? Or how many hoops do you do? I need to jump through to deploy to production? All of that is part of it, but it's also, "How can I navigate this landscape of tooling, the docs, the tutorials that sit around it? Where can I go and ask questions and also how am I guided through this? Do I need to read up on every minute detail or is there a process, is there a tool that can guide me through getting stuff done?" And this is tying this back to Gitpod. Chris Weichel : This is how Gitpod sits in there. What Gitpod does is it really lowers the barrier for people to become developers and to grow as developers and to enter new fields that they hadn't known before. Just because it removes a lot of the friction that comes from having to configure this and jumping through all those hoops before you can start with say a new framework. It also enables folks to become developers to whom this otherwise would've been inaccessible. So we have members in the community who started coding on essentially an Android phone connected to their TV and a Bluetooth keyboard. Chris Weichel : And the only reason they were able to actually work on this is because they could get a fairly compute, fairly powerful workspace that was running in the cloud rather than on their phone. And so, to me, that's also part of developer experience is, we usually think about this in a commercial context and show that matters a lot. There's also the developer productivity aspect to this, but it's also lowering the barrier and making it accessible so that others can maybe overstressing that those two words can experience what it is like to be a developer. Brendan: And I think there's also, as you're thinking about that relationship between the product and the community of people who use the product and support each other, that seems like also a really important part of the experience, is there a way to connect to other people who are, are having the same experience or who are interested in solving the same types of problems. And so I know that's something that I think you feel like you definitely have, and you're proud of, but I'm curious how you bootstrap that as a product. Does that come from your open source roots? How do you go from, I have an idea to, I want to build a community of developers around that idea. Chris Weichel : So in the beginning, when we started Gitpod, it was closed to us basically. We had our private repo. This is where it sat in. We had basically GitHub issues that he could comment on. And there was some traffic in there that was happening. What really kicked it off is when it all became open source, about three years ago, all of this, got out in the open, we made that very deliberate decision. We want to be out in the open. We also want to not just share our code, but we also want to share the way we talk and think about things and want to put that in the open. And so, a lot of the product discussion and prioritization and how are we going to do X and Y basically happened out in the open, on issues, like good open source project would. Chris Weichel : And I think that was a good part in building the nucleus of a community. And then we've gone through several iterations on modalities where people can connect. So we started with a forum essentially, and the GitHub issues. And then now move to Discord where there is a lot of where there's a lot of conversations going on and people just hanging out and talking about it. And this really has helped grow this, grow the community. What also helps in this case, I think was very fundamental to it is to have great people who really deeply care about building a community. And so in our case, Pauline Narvas, who co-host the DevX Podcast with me, she's really excelling at that. And it is she's really, really passionate about building a community and making sure people feel welcome and creating avenues for people to join. And I think without having someone with that level of drive and passion for building that, no matter how open you are, it's going to be hard to rally people around and make them feel welcome. Brendan: And maybe going, reaching back to the beginning of our conversation, I think there's also something to be said about incentives, where if you make it, someone's full-time job to solve this problem of bringing people together and thinking about the events and the modalities that can create community and do experiments and try new things that investment from the company into its community also, has a big role in carved in that it's something that has an organic element, but it doesn't just come out of nowhere. Chris Weichel : That's right. You can't just put a forum up and expect that people will come and be a part of this. You got to make sure that they get value out of it, that they feel heard that there is that they are not just talking to an empty space. And you also want to encourage your own folks to join that community. So a lot of Gitpodders are really active within our community and do enjoy that a lot. Brendan: I think we're becoming infamous for closing our podcasts with some version of this question, but it feels especially apropo because we were just talking about that inflection point in developer experience and developer environments changing. If you look ahead in your mind, maybe 10 years from now, what do you think developer experiences is going to look like? How are we going to be building software? Nobody can hold you accountable to this prediction. Chris Weichel : I would hope so because I'm sure to get it wrong. I think what will happen is we'll see a lot more automation. We're going to see a lot more automation from... To the likes of Copilot, where, sprinkle machine learning magic dust on things, and you get a much better experience. We're also going to see that trend of automation going to continue. So remote deaf environments, I'm sure in 10 years way before that actually will be a standard way of working. What I think is going to be interesting is how the whole no code thing is going to play out. And what new forms of problem and solution specification will come around. And this also ties back to the machine learning side of things, the question will the developer be obsolete at that time? Chris Weichel : I personally don't think so because problem specification and also verifying solutions, et cetera, are still very, very hard. What I think will change a lot is, or might yeah... Will change is how we talk about those problems at what level of abstraction and what level of detail. And with that, to some extent, I think that it's almost going to separate into two types of development, if you so will. On one hand, there are those that built those tools and that really get into the nitty gritty and understand how these things work. And then there are those that used them. And lastly, isn't there that saying the future's already here, it's just not evenly distributed. It's like that. I think there are going to be some areas where this is going to be more where we're going to see that more than in others. So for example, I would expect that embedded development will trail this compared to say mobile app development. Brendan: Yeah. Chris, thank you so much for joining us today. Really, really enjoyed our conversation. What would you like to plug or point our listeners to? Chris Weichel : We actually spoke about the community already. I think this is what I want to plug. The Gitpod community. If you try Gitpod, if you have any questions about that, if you want to go to talk to people who really care for developer experience, there's even a developer experience channel in all this code, go and join those. It's awesome people. I think that's what I want to plug. Brendan: Oh, thank you again. It was great to have you on and we'll see you online. Chris Weichel : Thanks Brendan. Speaker 3: Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.