Programming Throwdown - 134: Ephemeral Environments with Benjie De Groot

Episode Date: May 24, 2022

134: Ephemeral Environments with Benjie De GrootDownloadHow do you test changes to your web backend or database?  Many people have a "production" and one "development" database, but the development database can easily become broken by one engineer and thus unusable for the rest of the team.  Also, how would two engineers make changes in parallel to the development environment?  What if you could spin up hundreds or thousands of development databases as you need them? Today we have Benjie De Groot, Co-Founder and CEO of Shipyard to explain ephemeral environments and how virtual machines and containers have made massive improvements in devops! 00:00:15 Introduction00:00:24 Introducing Benjie De Groot00:01:26 Benjie’s Programming Background00:06:34 How Shipyard started00:09:17 Working in Startups vs. Tech Giants00:19:28 The difference between Virtual Machines and Containers00:26:17 Local Development Environment00:40:27 What is a DevOps engineer and what does it entail?00:45:42 Zencastr00:50:12 Shipyard as a company00:55:29 How Shipyard gets clients01:06:48 Farewells     Resources mentioned in this episode: Benjie De Groot, Co-Founder & CEO at Shipyard:LinkedIn: https://www.linkedin.com/in/bueller/Podcast: https://www.heavybit.com/library/podcasts/the-kubelist-podcast/Shipyard:Website: https://shipyard.build/Careers: https://shipyard.build/careers/LinkedIn: https://www.linkedin.com/company/shipyardbuild/Twitter: https://twitter.com/shipyardbuildCommunity Website: https://ephemeralenvironments.io/GitHub: https://github.com/shipyardHeavybit:Website: https://www.heavybit.com/LinkedIn: https://www.linkedin.com/company/heavybit/Twitter: https://twitter.com/heavybit                 If you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Hey everyone, we're here with Benji, the co-founder and CEO of Shipyard. His expertise, let's say, is something a little bit further away from mine than normal. So I'm kind of excited about this. Always a great opportunity to learn something new in the field of software and engineering. It's a big field. And I think the stuff we're going to talk about today is something that, you know, for me, at least I studied, you know, programming in college, you have a CS degree. And when I was there, you very get in a very skewed view of how software development works. You're like one person or two people team, you think you got it figured out. And then you show up in your first job. And

there's, you know, dozens of people on on the team and everything you thought you knew about how the world worked is just wrong. And so I think a little bit today, we're going to understand how in the real world, some of the complexities of building software happen and as well as even past that. And so happy to have Benji here. Welcome to the show. Hey, thanks for having me. So let's start, at least I traditionally like to start off by saying, what was your sort of first experience with getting into development or programming or tech in general?

Do you have like a formative moment? If not, I mean, that's okay too. Yeah, I think my formative moment was when my dad did something, I can't remember what it was, to my Commodore 64 so that I couldn't play the archery game. And I somehow figured, I can't remember what it was, but I just remember I figured out how to get around something by typing a bunch of stuff. And there was definitely no Google in the day. So I was very proud of that accomplishment. And basically, I caught the bug at a very, very, very young age of being like, Oh, wow, like everybody's equal in the digital world, you just have to figure out the best. And so I would say that's when I really started. And then it probably took off a little bit more. And I will say that I

am officially, I'm not a millennial. I'm not a, what's the other one? Yeah, I am. I'm an Oregon trails generation. I don't know if you guys have ever heard that term, but I think, Oh my gosh, the game's amazing. Yeah. So if you know the game, yeah, exactly. If you are worried about dysentery and you're hunting squirrels, then you are in this in-between generational thing. Now, did you play the Apple one or the one on Windows where you could click to shoot the squirrels? So I played, so in my day, I did play a little bit of the really early Apple one, but that was because my mom was an art teacher and she got us a free old Apple IIc like 10 years

after they got them out of the classrooms. I don't know. Someone was like throwing them out and they have a computer kid but in school i played the there was like an early macintosh one so i think technically i was playing oregon trails 2 um very on topic for this podcast by the way oh yeah this is so pertinent um i'm glad that we could go through that you gotta have a shared history with people. It's all right. Yeah. It's good. It's good. And then,

so how did you kind of end up, I mean, now, now this is your, you know, kind of your career and your entire, I mean, did you go to school to study engineering or programming or what did your, what's your kind of path take?

Yeah. So I actually ended up going to a UC Irvine computer science school and I studied computer science there. And I did not realize it at the time, but I had a spectacular education. And I really learned a lot. And one of the things I'd highlight, because obviously, I've worked in this field for some time, and I have a lot of some of the probably my smartest friends are ones that have not gone to school. There's probably some exceptions to that, but, or the most effective engineers that I know at the very least. But I will say that for me going to school, it gave me some foundational stuff that I use every single day in every single

conversation around, you know, technical decisions and just understanding, you know, how CPUs work at the very bottom there with assembly language and just all the different trade-offs. I think I learned all of that from computer science school. And I do hate assembly. Don't get me wrong. I really hate Lisp. I really hate Lisp. But I had to- Oh, don't talk about Lisp. Lisp is the way to get lots of feedback on the show. I have to tell you, I haven't listened to the back catalog but i know i know some airline company wrote the reservation system in for in lisp in 1990 and that's why everyone says lisp is a real language it is a real language sorry i don't think it's not a real language but i just all right just to be clear veggie is talking and not jason arise so please send all the mail to him yeah i am the one

set no i'm not saying it's not i my issue is is that recursion makes my brain physically hurt and parentheses also make my brain hurt so i just have a double name too yeah you know i feel like i agree with that one of the things that's interesting is excel is so easy which is all about recursion and functional programming but i think you know i was thinking about this the other day this is just i guess very serendipitous know, I was thinking about this the other day. This is just, I guess, very serendipitous. But I was just thinking about and talking with some friends about why is Excel so easy when functional languages are so hard? And one thing that someone pointed out, which I was really interesting, is, you know, with Excel, you see all the intermediate results. Like usually people don't write giant functions.

They'll have small functions that'll output to cells, and then those cells will go into other cells. And so it's sort of like you're at any point in time, you're like tracing through your program just all the time. And we think that might be why Excel is the only program to really get functional languages to the masses. That's a good point. You know what else you just made me think about also is it's also a GUI.

Like there isn't a GUI for Lisp. Or not when I was, I was actually Schema, I think. Yeah, right. But there's no, like you have that immediate feedback with the cells. So there's kind of a GUI for functional in that regard, if that makes sense. I actually wrote my first neural net in Excel and I actually am really good at Excel. So it's ironic that you bring this up because I love Excel or Google Sheets, whatever. Yep. So how did you get from neural networks in Excel to Shipyard?

We'll use that as a segue. Oh, yeah, that makes sense. Well, that was back in the day, my computer science days. I call out to my professor, Dr. Frost. That was actually his name. I love calling him out. He's a great professor. So yeah, that was my 102 AI class I took a long time ago.

But what ended up happening was I graduated school and I actually did a startup in Los Angeles. This is back in the day when it was just like MySpace, AOL, and my company. And it was actually a language translation company that was using very early neural net stuff. This is a long time ago. It did not work very well. It kind of worked, but it didn't work all the way. For language translation. But the takeaway there was that, to your point, I showed up.

I had a startup. How do I host this stuff? How do we do all these things? So that started my DevOps journey, let's say. And back then, it was like writing bash scripts for Linode, I believe, I think EC2 wasn't even out, I want to say, but maybe it was just beginning S3 was around. I remember I used S3 back then, and then ended up moving out to New York and doing a bunch of other tech startup stuff, co-founded one or two things. I'm also like VP of engineering. And throughout that entire career, I was always

owning the DevOps responsibilities for my various companies that I was working. That encompassed everything from Puppet, Chef, Ansible, Salt. I mean, then later on dot cloud docker became docker kubernetes terraform the list goes on and on so actually one question there is what made you go the startup route and not go into big tech like microsoft or one of these companies like like what what was your thought process there i mean when i was in my day or in our day maybe you know i was you know i was microsoft was the bad guy back in the day which is crazy to me because microsoft's a good guy now which just it just blows my mind when i think about or maybe there are worse guys you know maybe it's no but i mean but microsoft has ubuntu built into it you turn on windows 10 now and like ubuntu you just click on a button and you're in ubuntu yeah that's very true

and that to me i learned that like i haven't used windows in i don't know 10 years 15 years something like that but i learned i was on a friend's computer and i was trying to help them with some docker stuff and i was like can you just like download a virtual machine and give me like Linux or something? And he's like, oh, I have it. I was like, oh, oh, you did. He's like, no, no, it comes with Windows. I was like, what? And so ever since then, I've been like, holy moly, everything's changed. It's great. But yeah, sorry. What was the question? Oh, yeah. The question was like, okay, maybe, you know, look at the ecosystem of big companies. You have Microsoft, you have Google, you have Apple. And you chose

to forego the giant corporations and go start something like start a startup or go into the startup ecosystem. And so I was wondering what made you go that route? I think that I just kind of have a little bit of, I don't like cushy things i like being challenged i like kind of like clawing and scraping i also you know microsoft didn't recruit me so maybe if they did i would have i don't know i don't think i would have to be honest with you i really did not like microsoft when i graduated school sorry to everybody but i like them now there are probably a few big large tech companies that i probably shouldn't name that i would never work for these days but microsoft's not one of them actually. And they're great in the space that we're in, in the CNCF cloud native world. Microsoft's been awesome lately. I can't

believe I'm doing a Microsoft commercial all of a sudden somehow, but anyway. But yeah, no, I think for me personally, I like having the opportunity to contribute across the board. And I think that the more of a corporate career path that you take, the less opportunity you have for being creative and finding things that you're more excited by. There's more risk and there's less financial stability, that's for sure. But that's never been a big issue to me. Yeah, that makes sense. I mean, one thing I noticed... So Patrick... Actually, Patrick, have you ever... We'll jump to you later, but this is my first time working for a company that isn't at least like, I don't know, 50,000 people or something, right? And so one thing I noticed about the startup I'm working

at now is that everyone in the company is working on the same thing. I mean, even if you're in legal or finance or whatever it is, everyone at the end of the day is trying to get one product out the door. And that, I think, is really something I didn't expect that I really enjoy. I just enjoy the fact that everyone I talk to is working on this thing. And it's not, oh, this person is trying to make like a hot air balloon with Internet. And this other person is trying to do an advertising you know you know marketplace and and and so legal is just like you know trying to you know satisfy all these different people and at any given time only one of them really really matters to to all these cross-functional teams and so all of that kind of disappears when you're at a more focused company.

Yeah, I've only ever worked at a massive corporation. So this is an experience that I have not yet, not yet have. That's a great observation. Yeah, I mean, I definitely think that when you all are kind of struggling on the same topic, that cool things happen. And so I've really enjoyed that throughout the course of my career. That being said, of struggling on the same topic that cool things happen and so i've really enjoyed that throughout

the course of my career that being said i never wanted to do a venture-backed company ever again and myself and my co-founder peter we kind of became these high-priced kubernetes devops engineers in the new york mostly in the new york ecosystem also some la companies in james francisco companies and basically to kind of skip a little bit forward to answer your actual question we were basically going around helping companies in their transition from either traditional you know bare metal or some level of vm to to getting onto the container train specifically around the kubernetes and the production stuff and basically a lot of we saw we started seeing a lot of patterns and we kept kind of having to build the same software and And it was very typically, I wrote this, some DevOps engineer wrote a bespoke way to deploy

environments themselves for the various stakeholders at the company, production, staging, maybe some other stuff there. That person has gone or that person has moved on or that person is sick and oh my God, my hair's on fire peter benji come save us and then i would get there and be like oh my god this is all done completely wrong i have to redo the whole thing because this is my bespoke version of this but i know what i'm talking about versus this other person and there was actually an instance where we did that move and then we moved on from that company and that same company brought us back because they hired someone that tore out our stuff and we put it back in. So the DevOps space and the SRE space were very opinionated. But the problem is that there's just way too many options. And consulting shop forever. We kind of built our internal tool, which Shipyard, the first iteration of it was like kind of an exoskeleton for us to rapidly support people. Some of our customers ended up seeing,

literally seeing these not very good looking interfaces and like, hey, can we click that button? We're like, yeah, sure. So then we started doing that. Then all of a sudden, we kind of had this like quasi product that was very, very blue and tapey for our existing customers. But it was pretty cool. And then, you know, hell has to freeze over for me to take another VC dollar. And then in March of 2022, I think we all remember that. Got some preemptive term sheets, blah, blah, blah. Next thing you know, we're a funded company.

But that's turned into a great decision. And we've been able to build a really cool product that we're super proud of. So that's how we got to Shipyard, to answer awesome great story great story all right well that that's actually a good setup segue for i think what i i'd like to dig in on so people i guess you know i can't speak for everyone because i predate people learning to program by doing javascript as like even really an option or even before really doing Python. So for me, I resonate with, you know, Oh, a bare metal build system, right? I'm, I have GCC and I can compile my C program and, you know, I have my computer, but one of the things that I think

even before, before scaling up a team that you run into is, Oh, Jason compiles and I compile, we have two different versions of gcc two different compilers and all of a sudden like our binaries don't behave the same way right we don't have i guess the term is like hermetic build system right like all of our things aren't self-contained in such a way that like maybe his libraries are different than my libraries right and with c maybe this is a little less of an issue. You don't tend to have tons and tons of dependencies. But okay, so I kind of started it bare metal.

You have like your computer running your operating system and your compiler compiling your source code. Kind of take us from there, from like what your observation is. And it doesn't have to be on that. Maybe if it's for JavaScript, I think there's some analogies there as well. But like, how do people sort of move up the pyramid or move up the stack of saying like hey this is like

a single user focused thing to the rest of the life cycle after that sure yeah that's a that's a it's a big question but i'll do my best we can take it in parts yeah no no well we're talking about my school days you're you're doing c plus plus and c so i'm feeling a little insecure so i want to like remember something from my compilers class to sound smart but i don't know if that's going to happen so okay so at the core you have a gate no only nand gates that's what i mean so let me just talk to you in adders all right so so yeah so i the one big, a big difference here is that between compiled language and a lot of the stuff that's happening in the world that we're in and, and sorry, so Shipyard,

the world that we're in is we are helping applications. So typically SaaS applications. So, okay, great. All right. These are, these are web based typically, sometimes mobile applications, database, application logic, maybe an inference engine. So this is not for compiled programs, really. Actually, Shipyard is not at all, but it's a good analogy. So it's more for interpreted stuff there with Python, JavaScript, that type of thing that you're talking about. But in general, I think the

connection between compiling to an application delivery is pretty straightforward. And what the common practice is today, I could talk about the old practice, but the common practice is to use something called containers, and typically something called Docker. I believe, I'm sure you guys are familiar with that. Yeah, these are words that I've heard before. These are words that you've heard before. So what a container is, is it's sorry, what a Docker, I'll just start with a Docker file. What a Docker file is, is it's literally a list of commands with some smart caching in there. So it's like, use Ubuntu 20, not npm install, what is apt get, whatever. So you literally write this out in your Docker file, so that you have those

libraries, because dependency stuff is, I think think i think naming and dependency problems and cache and validation are the three unified things oh man there you go yeah it's like the three so so you basically get your dependencies you're in this file and there's some really smart caching stuff so that it can be faster to to bring your image which is is where your container lives okay i don't know if I'm doing a good job of explaining what a container is, but it's basically a way to encompass your operating system and all the necessary libraries

that that needs to run a given program. And so let's just take the example of Python. You might need certain pip packages for whatever reason. So I would have a Docker file that's a containment of that. And then I can mount in my code, my Python code, right into the so that's kind of the way that you encapsulate various things. Now, you might have that, you might have a Python application, you might have a node application, you might have a Rust application, you might have a Go app, we maybe even have a C++ application, they all can be contained in their own containers. That's probably a good way to do it. And then you need something to orchestrate turning those on and off. And so what that means is that you have things like Kubernetes, which are a scheduler or orchestrator. And those things can turn on and off the various

containers that I just described to you to help orchestrate their ability to use each other. So just say I had a Python application, I have a container for that, but it needs a database. I have a second container that's my Postgres data container. And then the orchestration piece, okay, you guys can see my hands, they can't, but the orchestration piece says, hey, make sure that database is up before that application, Python thing is up because they can't talk to each other is that a decent high level overview yeah i mean i think that makes sense so for people who and we've covered some of the stuff with containers before on the show but just just as a reminder not forcing people to do the entire backlog so the difference between i think most people kind of know what a

virtual machine is and a virtual machine is running a version of all of the things on your computer on your computer so its own hard drive its own memory its own cpu we won't get into some of the nuances between emulation or not but but basically running an instance of everything and wrapping it all up and then you could run multiple vms and they can switch between each other you could save the state so unlike your normal computer it's completely software controlled. Going from a virtual machine to a container. What what kind of advantages are you unlike? Like, why is that been the migration for people to move from one to the other? Sure. Sorry, that's a great question. So with a virtual machine, you have a full snapshot of the operating system, and the application code, right? With containers,

and the way that you do that is using the hypervisor. So it's actually at the hardware level. So there is some major security benefits to having a hardware layer for security, but it's never perfect. Heartbleed, for example. So nothing's perfect. But with containers, what you're doing, and this is probably a really good thing to explain,

sorry about that, is that you have the operating system as a shared resource. So it's actually living in a virtual machine at the bottom, like if you use if you turn on Docker desktop, there's actually a virtual virtual machine at the very bottom, that is the shared resource. And so then your containers are very lightweight, sit on top and just have the layers on top of that operating system that might not exist. So Redis might need a cryptography package and Python needs a authentication package. I don't know, but they're both using the same underlying OS in the container. So there's security disadvantages to containers to be clear,

but there is a shared resource thing. So what you get out of that is much lighter weight. So like if I want to stop my VM and send it to you, like that could be, depending on what it is, a four gigabyte file, right? Like the image. Whereas with a container, it's literally just the application definition. So I send that over to you. It's just a little file. And then you might have to pull some other layers or build some other layers that you

might not have, but you're not building Ubuntu and you're using it as a shared resource. So they're a lot, they're a lot more portable and you have these shared resources underneath. So it's a lot more efficient. So you can have, so instead of having to carve out an entire operating system for each one of those services I described before, there's a shared one at the bottom almost always. And then there's just the packages on top that are they are gated from each other but there's security issues there so sure so then so okay so it's composable and we can compose a python package and a redis and then the python can talk to the redis so we can serve serve our website and have our you know data store that we can we can write to so then then you talk

about kubernetes so k Kubernetes isn't for orchestrating the composing of the containers into one. I don't know what the term, what is the term for like, you have the collection of things and you want to orchestrate them with Kubernetes. I don't know. I don't have the right term for that.

So I mean, it's basically, it's a Kubernetes cluster that contains a bunch of pods. Pods are basically containers. And then those containers are typically, or sorry, pods are typically in what is known as a namespace. So your cluster can have n number of namespaces. But there's some like, you put all your pods in a container, they can talk to each other automatically. And if you want to break out of that namespace, that's a whole

other permission thing. A large part of the Kubernetes and CNCF ecosystem is all about security controls. And what's known as RBAC or Role Based Authentic I don't know what the AC stands for. RBAC. I know what it does. I should know that. Role Based Access Control. Thank you.

That was a test. You passed the test. Good job. Okay. So, all right. So we're orchestrating all of this. And this seems like I probably, as the developer in the role I am today, I probably care about this awfully late. I'm probably really far along in having my application up and working. Just personally. Because this isn't something that I've done before.

So I imagine you kind of explaining the narrative of how you got to where you are. This isn't uncommon that people sort of build up their stuff. They start running multiple instances, maybe with some sort of load balancer. I'll see, I know something. Load balancer up in the front distributing, and then realizing, oh, hang on. This is actually a nightmare to sort of keep up and running. And then you sort of start bringing in tools like Docker and Kubernetes. But add a whole

new layer of security and sophistication. When I look at those tools, I don't really understand, you know, necessarily what they do, because they're solving a problem that isn't a problem I relate to yet. And I think that's likely where you were sort of getting at where companies get themselves into a bit of a mess, and then call you in and say, Hey, we need help with the mess. Yeah, that's right. So I think a modern approach, probably in the last five to six years, and this is, I would say, completely thanks to Docker and that ecosystem, is that these days, if you're writing a web application of any size, you almost always try and start off with a container.

That's not true for all enterprise, and there are exceptions to this. And especially if you're doing like real low level stuff, like I don't think it would make sense. But you typically want to get as close to production locally as a developer as possible. That's always kind of the overarching goal. It was not an accessible goal up until kind of this Docker thing. And it's still a little flawed. But yeah, you might want to just install these packages locally on your desktop. And then when it's time to share the application or collaborate on the application or host the application, then it's just like, where do I go? So the typical pattern that we're starting to see today that I've said, I would say over the last three years is pretty typical, is you have a situation where you develop something locally,

you try and containerize it to some degree, as a, there's a lot of developer pluses out there, if you will, that kind of do it themselves and kind of get that little bit of orchestration going locally. But then how do you get that into production? And then all the intermediary environments in between, that's kind of where Shipyard comes in for all of this stuff. Okay, awesome. So this word environments in between, and I guess we might have cued that in

by the name of the episode. But all right, what here, this word environment, what is that? What do you mean by that? Sure. So when I'm working on an application locally, that's my local development environment, right? It means that like, I can make it work locally, I have I turn on Postgres, I turn on Python, whatever,

then there are other environments in the typical software development lifecycle of most companies, especially on the application side. And they are typically high level development. So this is a shared place where all the code is living for all the developers to go look like in the web, in the cloud somewhere. Then there are typically some versions of testing environments and then staging environments and then production. And that's just like a high level version of this.

And so the idea is, is that as you're working on a feature, you start locally. Once you feel on a feature, you, you start locally. Once you feel good about it, you put that in a shared space, maybe get some feedback from another developer, maybe do a code review. Once you're happy with, with the code that you've written, then you would merge it into the main branch. And then once that happens, then it gets hopefully into some type of staging where other stakeholders look at it typically, sort of, they're supposed to, and you run some tests. And then once you're happy with that, you release it out to the world through some system. Now, all of the thing I just described to you is what's known as, and I know you guys

know this, is CI. So, you know, continuous integration. And there's a lot of tools for that that are basically the shepherds of all this stuff. Personally, we use CircleCI and GitHub Actions, but I've used Jenkins and Travis and Argo and Flux over the years. There's a lot of good options here. Buildkite's another great one that I like those guys a lot. So yeah, so that's kind of what these environments mean.

One thing that might be obvious here is how do you know when to merge and deploy a new environment is a big challenge for internal DevOps and also development teams. And then the other thing there is, should that be manual? Should that be automatic? And so there's a whole, and the whole point of continuous means that it's supposed to be automatic, but that is a very hard thing to achieve internally at software teams, typically. So I understand in the production environment you have users stimulating your application doing things hopefully hopefully have customers and they're they're using it for things in this sort of staging i guess this is

where traditionally i would sort of you have either qa scripts or people going and simulating you know interaction with the application and then in sort of development is it it's the developers who are going in and sort of like pushing buttons and clicking things and getting databases set up is that is that roughly like how the each of the that's that's exactly right i mean and it's it's bespoke for every organization and that's part of the problem. It's like there is no one way to do this. There's a lot of different versions. I would almost go as far to say that literally every single software application

has its own unique version of every single thing we just described, except for those using Shipyard, then there is some commonality. But literally every single application has its own little nooks and crannies and little knobs that you need to tweak to actually make it work and that's all that's typically contained within the devops person's brain or who's ever responsible for that and they already have so much stuff to do that's kind of where the problems begin from an efficiency perspective and velocity perspective that makes sense so i have some feature up and it needs like some state in order to be

able to to be tested i mean is this is this kind of like where we end up needing something a little bit more sophisticated is like hey i want something to be in a given place to demonstrate to someone else it works or to debug an issue. From what we've talked about so far, that seems like a lot of effort for me to go curate a specific something into the state ready for demonstrating my stuff or having it work. You know, I'm adding something

to the end of the checkout process. So you need someone to go pick something off of a page, add it to the cart, enter their information. But, and then you can show me, that's a lot of work for someone else to do to approve a PR or whatever. Is this the kind of stuff where you begin to start to run into issues with sort of like how everyone sort of shares these things around? Or where do people start running into the downsides of just kind of one-off doing all

of this? So, I mean, the place to start here is with the software development lifecycle in general, right? So typically, a product person works with a designer or UX person and says, Hey, I want feature x, I want this blue button to do this when you click it in the existing application. Eventually, the design for that gets over to a developer, and it's kind of thrown over a wall, the developer creates the feature. And then at some point, that product person gets to see that feature. So that's the first problem. The problem is, is that a developer could work on a feature. And two weeks later, they're getting feedback, hey, that's the wrong color blue, or when you click this, it's supposed to do that, not this. So then there's this huge developer

context switching cost. Because as a developer myself, and I'm sure you can speak to this, like when it's in my brain, my mental model is all filled out. No problem. The second it's out, like it's like, oh God,

I don't even know why I named it. Like I don't even know what I was doing. Don't worry for any Shipyard customers. I am not programming anymore. So that's rest assured. This is not a problem for Shipyard. I have no longer, I haven't had to commit to the- You had it taken away from you, huh?

I literally have not had to commit to the co-base in six months to protect our customer. But- That's not entirely true, but somewhat true. But that feedback loop being very long is really taxing. And it's a stop and start type situation for the developer. It's also super frustrating for product people. Now take that one step further. So you have a product person that says, Okay, this is the right color blue. But then there's a QA engineer

or automated QA test or auto manual QA tester that another two days later is like, Oh, hey, like this broke this other thing that you didn't realize. And you're like, well, I just fixed this other thing. And I moved back to my other feature. So the whole point of shipyard and ephemeral environments in general, it's really a methodology where as soon as it's off of my fingertips, and I'm ready to commit this and share this with a developer or anybody like that, it should be asynchronously available for all these other key stakeholders to look at and give feedback so that everything just gets tighter. It's much tighter feedback loop. And then also product people aren't frustrated. QA people aren't doing the hurry up and wait, which is very typically their lives. And so it just all becomes kind of synchronous. Now,

the other big pain point there is that if you wanted to do this without ephemeral environments, or at least good stage, well, without ephemeral environments or at least good stage, well, really ephemeral environments, you can, people do that, but that looks like, okay, product person, I've got a 45 minute screen share with you. We're now in a remote world anyway. So I've got a 45 minute screen share with you. You're going to give me feedback, but you're not even really able to click on it. Typically you can tell me what you want me to click on and then, okay,

well maybe I'm more creative than that. So I'm going to use something like N grok, which is great. I love N grok, but even if I'm using N grok, which is a reverse proxy that can get you. So I can, if for those that don't know,

N grok is a great tool. You can turn it on locally and it kind of tunnels out to the world. Great here. Product person use this N grok link, but guess what, you're still running off of my local copy of it. Oh, actually, that's why I didn't know about that. Yeah. And then I can't do development because you need to test this thing. So I'm going to break what you're doing. So the solution here is giving everybody their own environment for every feature, multiple stakeholders for the same feature so your next point getting

state right is the next huge challenge and the idea here is that you need a database with information in it or the application's not going to work to your exact point so replicating that data across all these these different environments and also it being sane like you can't just use stuff from six months ago you got to keep it up to date sync it across and then also giving well so now shipyard comes in and this is a feature that we're very proud of and people love there's like a data dashboard where you can actually cherry pick hey i want the state when i was working on this feature from two weeks ago i want to use that for this new pr that i'm doing

and vice versa so again without seeing my hands moving around i think the sound is smart but it's really cool so so you kind of like allow people to define oh just make up another term whatever you like allow people to find up like a bundle of data and say give it a name and be able to use that in multiple places. Yeah, that's basically correct. Huh. And then the, so more than, okay, I kind of see now. So the Docker file and everything is a piece of the puzzle. We have to describe how the thing builds, but it's only one piece.

There's all these other bits and pieces that need to get brought in. And even teaching Docker itself how to go to, and I don't even know how that works i mean i guess i should imagine it was like hey i have a pr i'm working on but it needs to know hey i need to go pull that specific version of the code not just the code checked in or the tag or the latest it's like it needs to go to a very specific variant of maybe multiple code bases and pull them all in pull some data down get it all up and running so that many different people could come and like try something out. Yeah, that's that's exactly right. And yeah,

we do have support for multi repo, which is another feature that we love not to plug shipyard too much. But yeah, there is two big things here to talk about just for your users is there's there's mono repo, which have all your code for everything in one big repo. Or what we're seeing a lot these days is multirepo. And people call that, I think they call that polyrepo. Also, it's another term people use where you might have your front end code with React in one repository, your backend code in Node in a different repository, and then another service in Rust or whatever. Coordinating all those to be on the right SHAs and the right hashes and getting

the right, all those things is very challenging. It's doable. So let me be clear, like this is a, this is something that people have been doing within Google for, I don't know, 15 years, more than that. And large engineering orgs, but they have dedicated, you know, 100, 200 person DevOps teams that focus on that. So really, what what's happened here is that because of technologies, we're on the backs of giants on because of technologies like Docker, because of stuff like Kubernetes, which is all under the hood for everything shipyard does, to be clear, now this elastic compute that you get by being really fast to turn on and off, and it being smart, you can now do these types of environments very quickly and turn

them on turn them off because that's the other part we didn't even talk about cost controls like you don't want to have these environments running when no one's using them because it's expensive and wasteful so yeah so what shipyard is doing is kind of helping give devops people um they can focus on being an sre for production, not for internal tooling, because this is becoming, this is pretty much expected tooling for any decent size software SaaS company. Like say you're over 15 engineers, like you need to have multiple environments. Honestly, once you're over four or five engineers and you can't just like do a quick screen share, that's when you start running into like really bad releases. Yeah. And one other thing, maybe not the best time to bring it up,

but I'll tell you anyways, is there's this concept of testing within our SaaS world. I'm sure you guys are more than aware. And there's unit testing. And then there's also what's known as functional testing, or more specifically end-to-end testing. Or I'm sorry, integration testing is what I meant to say. But end-to-end testing,

where it's literally there's frameworks like Cypress or Playwright or selenium where they like have a fake browser that just clicks on buttons for you and you can script it so it literally brings up a browser and it's like a human and that's what i think jason you were talking about that earlier like the scripted qa stuff so you have the scripted qa stuff so if you have ephemeral environments you can run those tests before a huge... I make my PR, Shipyard create... This is what we're seeing and this is what we're doing ourselves and a bunch of customers

are doing. There's case studies you can find on our website. But you bring up a PR, that PR automatically has end-to-end tests run against it. So before I even bring in my product person, or my code, my other developer for code review, or my QA person for manual QA, I already have a clean bill of health saying like, I'm not wasting any humans time, because I already know that all the things I expect to work still work. And if they don't, great, the developer gets feedback right away, they either update the test, or they update and they fix that. And the only way to do real end-to-end testing is with production-like environments,

so full-stack environments. And that is a difficult thing to do. So you have to build that in your CI platform or use ShipGrid. So there's a lot of moving pieces. I'm beginning to see the picture of where the intricacies lay and why you might think at first like oh just one more little script or one more little thing but then like you're pointing out I mean we've had this before someone's like oh hey I have a Jenkins machine and there's like all these builds didn't get cleaned up because something hung or whatever and so they're just left suspended eating up eating up space let me just go write one more script to like anything exceeding you know 14 days and then someone has a job that they expect to take yeah it's just yeah it's a never-ending ending battle it's like it's like you like like the

the carnival thing where the gophers pop out of the holes that's oh hack them all that is that is a very good description of a devops person's life and i am a devops person so i can say that so okay actually this this may be a good a bit late to have that conversation but i think it's a bit interesting as well this is a term that i've seen pop up a lot more recently than maybe when i first got started but this this like role of saying devops or i think we alluded to before SRE, like a site reliability engineer. Is that SRE? Okay, good.

I got it. Something like that. Like these are terms that for like when I was starting, they weren't an option. They weren't, you know, what people would do. We knew of like sysadmins,

people who would like, you know, come to your computer and help you get your stuff and make sure everybody's developers had all the software they need. And you know, that, that kind of stuff. But what in your mind, like what is a DevOps engineer and what does that role really like mean and what does it entail? Yeah. I mean, so it's changing right now as we speak, I would say that the sysadmin that you're speaking of was, you know,

back in the day they were responsible for that sun box with the 128 processors that you only had two turned on for or whatever to make sure that pets.com would stay up and quickly people kind of realized okay sysadmins like they're good at what they do but like understanding real time systems and like what's like ch mod is not the only thing that you need to do so there's other skill sets that they're developing, but really this is a different, like you don't want someone that understands all of these like intricacies of keeping a production system up also dealing with like, Hey, I forgot to reset my password type thing.

So a role was kind of created the DevOps role. I mean, I don't know the numbers on this, but I would guess like 10 or 15 years ago is when it probably came to some level of prominence. And that is like assist sysadmin slash developer because you also need to have a bit of understanding of application code because you need to be able to be like well this is failing here i'm looking at the log i have to jump into the code base and see if there's something obvious here and so it's kind of just like a developer

operations sysadmin type role that's what a a DevOps person is. And so they're kind of responsible for everything. Or ideally, they're responsible for all your infrastructure to make sure that all works, which does include, hey, I'm a new developer joining company X, I want to make like, how do I start developing that day, that kind of became a little too encompassing. Because if I'm worrying about new developers turning off, like being able to develop, then I'm not worrying about production being efficient or going down or not going down. And basic, I don't know when this happened, but Google released the SRE handbook. I want to say eight years ago, maybe it was more than that. And they coined the term SRE,

that's site reliability engineer. And those folks are responsible for making sure that the site itself, if you will, so production, is reliable. The way they do that is with SLOs and SLAs and SLIs, which are little measurements of saying, I have a service level objective of having the database not be down more than five nines or whatever. And so my job is to keep it that way. The SRE is a DevOps person that's focused on production is kind of how I think of it, but that never holds true because SRE then ends up being like, well, I know how to fix

production. So I probably know how to fix your local development environment. And I might know how to fix, I definitely know how to fix staging, but it's going to take me a second. And like, remember, what these people are doing, it's always, it's never a quick thing, right? It's never like, oh, I have to change this one line of code and everything's fine. I have to change this one line of code and then all this stuff has to trigger, rebuild. Oh, you know what? This data is corrupted i'm gonna have to move over a 400 gigabyte postgres volume mount over there

that doesn't take two minutes that takes a while and depending on your iops i guess but it could take a while and guess what as a devops person or sre like i gotta make sure that doesn't get corrupted in the rsync so the point is is that that the DevOps life is a one of patience and a lot of focus and SRE life. So what I think is happening, what I see happening is you have SREs becoming real, just SREs, SREs, just focused on production, which is definitely the model that Google kind of prescribed to us. And it's a really good, you should check out the SRE handbook. I don't think you can Google that one pretty easily, obviously. And then the DevOps person is kind of like, how do I turn on Postgres correctly without causing a problem?

How do I orchestrate the application so that it works well? And ultimately, there is a huge lack of DevOps people in this world right now. And there's a huge need for them. And so that's kind of where Shipyard came from. Yeah. So Shipyard's role, help me here, is like to empower DevOps people or replace DevOps people? Well, I think empower DevOps people to be SREs for production. Like that's kind of the way that I look at it. The truth though, is that what we've built is what I have wanted to build every single time I've ever joined a company.

So there can be a little friction. I'm not going to lie. I get it. I have empathy for that. But ultimately what we've seen is that everyone, all the DevOps people we work with, once we've convinced them that our stuff works the way we say it's going to work and that the application definition is as simple as we say it's going to be right now, that's Docker composed. Just we can talk about that later. But once we

build trust, they love us, but they're definitely skeptical at the beginning. And it is a tool that everyone kind of wants to build. Like that is like the whole point is like, Hey, I make a change and automatically everything goes up and it's awesome and anyone can use it and then when they're done using it automatically goes down so it really is kind of you know it is the cool like it's what we all want to build so there's a little friction there but i but ultimately it works out. I'm going to jump in here and interrupt our interview today to talk about our sponsor, Zencastr. Zencastr is an all-in-one podcast production suite

that gives you studio-quality audio and video without needing all that technical know-how. It records each guest locally, then uploads the crystal-clear audio and video right into the suite so you have high quality raw materials to work with. Jason and I have been using Zencastr for programming Throwdown for a while now and it's a huge upgrade over the way we used to do things. It's so much easier and more seamless to have everybody join a Zencastr room and get individual audio streams for each participant, which allows editing and

mastering to go much more quickly. It just also feels like a better experience for all involved. I'm so happy that we have this new solution instead of the way we used to do things back when we first started. If you would like to try Zencastreroom to make your own podcast, you can get a free trial by going to zen.ai slash programming throwdown that's zen.ai slash programming throwdown back to the podcast and then so and then we can leave this topic but so devops people how do people kind of get into that i mean you were saying that you kind of self-titled your your that's your current roles like more like devops do people kind of get into that? I mean, you were saying that you kind of self-titled your, that's your current role, like more like DevOps-focused, this kind of thing.

Like you talked about being a background, you know, computer science, he's your family, this stuff, now you do DevOps. Is that a typical path you see people take? Do people come the other way? They start more like operating system, sysadmin, and then they add in some developers, a mix of both. Like you said, it's an under, I think I've heard that before like it's a under service role currently like it's a lot it's really hard to find these people that have the right mix of knowledge what is your take there if someone says that

sounds really interesting what's the what's the right thing to go sort of google look at think about go to school for yeah i'm very torn on this one because underneath it all i feel like being a sysadmin is the key but also without that developer knowledge it's not as powerful so i think that what i would always say is just find a repository i'll ship you if you go to github.com slash shipyard we have got a bunch of starter applications that are like flask, Postgres, whatever. But there's plenty of other options out there. And just get it working. If you really want to be serious about your career in DevOps land, I think having a basis of understanding Linux is probably the more challenging thing to pick up.

So you probably want to maybe start your focus there. But also, it's really about curiosity. It's like, it's like, if you're good at dealing with problems, and you want to deal with problems, DevOps is a great role to be in because you just run into the weirdest operating system level problems, you run out of pages, kernel, pointer, you don't even know what stuff your problem you're having i think to be a good devops engineer you have to be a decent developer and a good system admin guy that's or admin person is what i would say that's a great observation i was trying to tell to people this like it's kind of interesting even the amount of operating system knowledge you're supposed to learn as a developer is sort of i don't, not counterintuitive,

but not obvious in the start. Like, Oh, everyone should learn programming. You sit down and write a Python and okay. Do you know about apt get? Can you apt get install pip? Like what now I'm on windows. Where do I go? And it's like, Oh wait, hang on. You know? And we've gotten better at some of that stuff, I think collectively. But I think it's interesting that even now I would consider like I use Unix environments or Linux environments routinely, but I would not by any means dare to breathe the word like proficient or expert as like my ability, despite having been, you decades in the as a programmer that's that's because you have experience so people who put expert or are the people who just haven't learned how how little of an expert we actually are at everything yeah i cannot agree with that more

the longer i get into my career the more i realize I don't know. So, yeah, I think that's a good observation. Well, cool. I mean, I think we're going to sort of like call that a pretty good coverage of the topic at hand. So let's talk about Shipyard as a company. Can you tell us a little bit about like Shipyard as a company? I know you talked about some recent changes and some things like are you guys growing? Are you hiring internship? What's it like to work there? Are you remote? Are you in office? And that was a big topic, but just sort

of give us the give us the pitch. Yeah, so okay, so the pitch is shipyard get an ephemeral environment on every pull request or coaching. So that's, that's the thing. But yeah, so we're a funded company, VC backed company, we've actually got some great investors. We're about 10 people. We are growing. We are hiring. Please check out our careers page for that. We are actively hiring. We are on Twitter at Shipyard Build. We also have a community site.

Actually, this is a good one called EphemeralEnvironments.io. I hope you put that in. Ephemeral is... I learned how to spell it, but it took me like 10 years. It'll be in the show notes. People will just be able to click on it. Great. And that's... So what that is, is that is a community site. PR is welcome. I learned how to spell it, but it took me like 10 years. It'll be in the show notes. People will just be able to click on it. Great.

And that's, so what that is, is that is a community site. PR is welcome. And the whole idea here is that, as I mentioned, like ephemeral environments is not a new paradigm. It's just becoming an accessible one. And we're a part of that, but there are other people and other companies trying to work on this and just other open source projects out there. So these are kind of best practices of how to become ephemeral, how to use it, what to do. So you should check ephemeralenvironments.io. Our website is shipyard.build. Yeah. And so we're doing well. I had some really early success with some awesome design partners that we're really

thankful for. And yeah, and we have a free trial now, actually, soon to probably be a free tier but i'm not going to say officially but we're working on that remember every one of the environments i'm sorry every one of the organizations we have or maybe i didn't tell you this gets its own cluster we're very very security focused we have a bunch of regulations that we have to make sure we're on top of sock to um hipa all these other itar. So we're really good about we would try to be really good about security, but you can never be perfect, obviously. Yeah. Any other questions about shipyard that cover everything? No, I mean, I think what, what would you say if someone was saying, you know, maybe I apply to be like, what is the thing that you would say you would look

for them to be interested in? Like, what would they be passionate about that would make them a great fit? Yeah. I mean, high level efficiency is something that's important to them. Like understanding how broken our software development life, or maybe broken is not the right word, but slow and arduous. People that want to automate, people that want to help people move faster or companies move faster, which is a very cliche thing to say, but it's true. And then the other thing is, is like, look, we are in a critical path for all of our customers. They depend on us every day. So understanding that we're actually, you're going to have a lot of responsibility. You have to have a passion around DevOps to some degree, or at least making good software and

enabling product people and QA people to do that. That's kind of what we're looking for. But ultimately, you know, people that are curious and just want to make things is really what it comes down to because every day, you know, we're spending time on calls and planning and all these things. And the whole point is, is that our entire product is built off of customer feedback of being like, Oh, hey, like, this is great. But like, can I look at my logs and Datadog? Like, yeah, sure. So we build out this Datadog thing. And then all of a sudden, all of our customers want our Datadog integration, you know, just the whole point here is that we have some really cool at the precipice of, of software development getting a lot faster and

we're just trying to help push it along and so people that are a little empathetic to the pains of of other software development teams is another big thing we look for and remember or maybe don't remember i'm telling you we dog food shipyard with shipyard so we food shipyard with shipyard. So we build shipyard with shipyard. I was going to ask that actually. Yeah. So we are, we are definitely one of the larger users of shipyard. We're not actually the largest user anymore. We haven't been for six months or so, but for a long time, we were the largest user of shipyard from a builds perspective and the commit perspective and a business perspective. And so when we screw something up, yeah, we're going to know before everybody else. So we work hard to not do that, but also, you know, being able to react

quickly and cool under pressure is another big trait that we like to have. I had a question, a bit of a non sequitur, but when you talked about being the biggest, the biggest consumer of shipyard, it kind of made spark this, which is, who do you go to when you want to acquire a customer? Because I feel like this is something I've often wondered, never really asked anybody. Clearly, you're interested in developers, but something like Shipyard, it's not like an IDE like Sublime where you can go straight to developers and say, hey, give me 15 bucks. And so you kind of want to target the sort of, let's say, VP of engineering or CTO or something. But then that person is so high level that it might be

hard for them to grok what's going on. And so I feel like a lot of companies that have an enterprise tier, who do you go for? Who's your ideal person on LinkedIn when you want to try and acquire a new business? Yeah, that's a great question. So the term that we use in startup land, because I'm learning all this, yeah i am yeah i'm now the ceo is icp or initial customer profile is the term that we're supposed to use and nice that's yeah and that's something that that we're constantly iterating on and developing um so the way that shipyard has kind of put our company together is we had this very early with some early customers for the consulting side of the thing and then we raised some money and

we've been super heads down building out a fully fledged platform so there was a lot of work that we didn't even realize stability is the most important thing features is then very important as well so we've been super heads down we got a bunch of great design partners and that's we use you know what's known as founder led sales for the most part there, there has been some other different top of funnel stuff there. And then we signed all our design partners and now we're figuring out the go-to-market and the ICP. But I think you hit the nail on the head where it is the VPs of engineering or the directors of engineering and whatnot. And the trick there is that the other departments

that we talked about are kind of getting frustrated because they're not seeing features early enough. And you have to find the people that it's trickling back up to, but that are also the decision makers. I will say that most VPs of engineering and directors of engineering and even CTOs, for that matter,

have a pretty good understanding of environments. And it's just a matter of explaining oftentimes replacing half-baked solutions frankly or underbaked solutions maybe is a better way to put that but yeah so finding those people and that's what we're working on so you know it's one of the reasons why i'm on your podcast you know customers welcome but uh yeah totally yeah we're working on that and that's the stage of the reasons why I'm on your podcast. Customers welcome. Yeah, totally. Yeah, we're working on that. And that's the stage of the company that we're at. We're figuring out our go-to-market as we speak. We've had some early success and now it's just a matter of figuring out where to keep. Personally, I don't think LinkedIn is a good place because as a DevOps person or a

VP of engineering, I never read my LinkedIn messages. I think I could change that at some point. Well, the free tier is interesting because you have potential for some bottom, I think that's what it's called, right? Bottom-up marketing. Basically, you put out the free tier, you get a coalition of developers to use it, and then now you have this, what's the term for this? Anyways, but you have a coalition of people at the company who are all in alignment there, and then they can motivate leadership.

Right. It's called an internal champion. It sounds like you've done all these calls I've had with all leadership. Right. It's called an internal champion. It sounds like you've done all these calls I've had with all these VCs. It's awesome. No, we're actually a member of a... And if anyone's doing, especially developer-focused software platform, you should check them out and maybe, I don't know. But there's a VC fund slash incubator thing called Heavybit.

And some of the best dev tool companies have gone through there. We're very fortunate to be in there. And they very much... What is it, Dane, one more time? I'm sorry, Heavybit? Heavybit. Okay, just for the... We'll put it in the show notes.

Sure. Well, okay, then you have to put all my investors in there. They'll get mad at me, but whatever. Okay, you just email us. We'll put it all in there. No, don't do that. This is not advertising for investors. But I will say that Heavybit has been instrumental in... if you can find don't put in the show notes but if

you can find heavybit.com but they've been instrumental in kind of helping guide us through this whole bottoms up adoption thing where you reach out and you have a product that developers can use and that that's whose shipyard is for it's for developers that that don't want to focus all their time and devops people that don't want to focus all their time and DevOps people that don't want to focus all their time on these internal environments, but they still need them. And so you start from the ground up, you get these people bought in and then they're the ones

that bring it internally into their companies for the long tail thing. Cool. Thanks for explaining that. I was always curious. And yeah, I think you covered it really well. Great. Anything else I could give you my sort of answers to?

We could do all manner of opinions on world events, tech talk. No, no, no. I think this has been a great episode. I think this is an important topic. I learned stuff. So I'm thankful you came on. And I mean, it's great to see people out there building products to help developers and development just go better and faster. And so excited to have you continue to do that so that all the products we use are just going to be magically better. I mean, it's not magic, but it's true. We've seen some really cool numbers lately where we have one team in particular, I was on a call with them the other day, and they are doing 50% more tickets since they started using Shipyard

over the last like six months. It's unfair to say that's all Shipyard because I don't know, but I do know that that feedback loop is getting shorter. Tickets are getting done faster. So 50% velocity increase, that's pretty cool. We're still figuring out where that is. Other feedback we've had a lot is on the whole testing thing where the customer success team likes using Shipyard. They don't use Shipyard, but they love

people using it because a lot fewer bugs are getting through because one of the problems with testing is that you get so many false positive tests that you just end up ignoring your tests and everyone does it everyone does it they might lie and pretend like they don't but everyone does it but if you can test earlier and transfer the ownership of that failing test earlier on the cycle then all of a, those tests become much more reliable. And ultimately, testing, unit testing, end-to-end testing, it's really about confidence. You're never going to be perfect, but it's like, as a developer, am I confident that I can get this out the door and move faster? And the end result is that customer success people are dealing with a lot less tickets. So that's another place that is a very good thing. And

then the last one, just to pitch Shipyard, is cost control, because people do have environments, but they just get left on for months at a time. And so we monitor the environments, we keep them on when you're using them, we turn them off when you're not. And remember, this is container, so it's very quick to turn these things back on. You just click a button, and then you stop using it, it goes down. So cost control very quick to turn these things back on you just click a button and then you stop using it goes down so cost control security all these things this is what shipyard is oh one thing i did not plug i forgot to plug i am a co-host of a podcast called cube list sorry if that's i hope it's okay to no go for it yeah yeah totally so yeah so cube list is very cncf kubernetes focus but that's cubelist.com and you can check it out.

I co-host that with Mark, the CTO from Replicated. There's also a newsletter. But in general, our goal right now is to try and just get as much best practices out there because we've just hurt ourselves

and shot ourselves in the foot so much. Bringing it back to the experience thing. You know, I don't know everything, but I know a lot of mistakes I've made over the years, especially in the software development lifecycle. And so we're trying to help fix as many of those as possible man your episode list has pictures and everything like i don't know man

i think i take it backward i have to edit that out like you're making us look bad over here oh man we got scooped i'm just teasing just teasing no it's great i i don't do it i don't do it it's the the mark and the replicated guys are great and actually again for some reason heavy bit is great as well they help us we're part of their catalog of podcasts and stuff like that but jason we need vcs man we need vcs it's official all right i'll let me know i'll have it wait but shipyard.build is the point of the whole thing. So everyone. So actually one thing, if we have a lot of folks in college, you know, I looked at shipyard.build earlier today and, you know, a college kid looks at $500 a month and says, you know,

I just can't do that. Right. So, so I know the free tier is coming. So should folks wait for that? Should they should do an email? If someone, if someone really wants to try shipyard, what's the next step for them? Like someone in college? So right now we have a free trial

and you get the full experience for 30 days. If you're in college and you want to try it out, sign up for that. If we see you have good usage and you reach out, we'll make sure that you don't. We'll make sure that we get you early access to the free tier. Let's call it that, but probably a little bit even better than that.

We want everyone using this. We want everyone learning. But the thing to keep in mind also is that if you're a college student that's just using it for yourself, I'm happy for you guys to do that. But really, it's for the college students that are working on a project with multiple people that there's a lot of value there. So all you need is a GitHub account, which is free, and sign up and reach out.

And yeah, I think info at shipyard.build is the best way to do that. But there's information in the console. And also kick the tires. Like you find bugs, you find stuff like that. We're happy to have you in there and we'll find a way to let you keep access. Cool, yeah.

I mean, one thing that i really like you know if i had to do my phd over again i would well i would cry and i would i would lose a lot of sleep and a lot of hair but but once i've gotten over the trauma i would i would use a lot more ci cd and like dev tools because i found that near the end of my phd you know i had to get this journal paper done and i needed to gather a lot of results. And especially at the end of your PhD, you're not really trying to invent another new thing. You're trying to write a paper, like survey kind of papers that try your method 2000 different times and have a lot of nice graphs and data and all of that. And the bad design decisions that I

made, you know, in the first level were really kind of catching up with me. And I think that having a, you know, having a tool like Shipyard would have helped, you know, kind of keep some of that technical debt under control. So yeah, if you're doing a doctorate or, you know, if you're working in a lab or even like a senior design project, you know, anything that's involved you and several other people, I think that it could be great to, you know, get on tools like this. Yeah. That's, I mean, I wish there was some CIC stuff back then, but yeah, it becomes a, yeah, it becomes, it becomes kind of, it's become standard practice to protect you from yourself. And also just, I mean, the whole reason we program is

because we had to type the same thing twice and we're like because we had to type the same thing twice. And we're like, I can't type the same thing twice. I need to spend two days writing something to do that for me. Stop, stop, stop. No, no. My heart's getting torn asunder here. Well, I mean, hey, we all went to computer science school. Wait, I have a question for you.

What was your PhD in? Sorry, I just didn't know. Oh, yeah. My PhD was this crazy idea of like trying to play Go with the neural networks. It'll never work. It'll never take off. I did. My Excel-based neural net was not a PhD. It was a class that I took, but it was to play Go. Oh, very cool. Yeah. Similarly, you know, my Go rating is something like 27 Co or something. So I was like, well, this can't stand. So I got to create a computer to actually play good Go for me.

And you literally did a PhD on it. Yeah, pretty much. That's cool. That's super cool. All right. Well, I could talk to you about this stuff a bunch. We should have. Yeah, I'm happy to come on your show and talk about computer Go, definitely.

Yeah, that would be great. Yeah, absolute pleasure yeah thanks for coming on benji i appreciate this has been a great episode and thank you everyone for tuning in and sticking with us every episode and engaging with us as we learn and explore and uh we should have a tagline dang it that sounded like it was almost cool learn and explore with Jason and Patrick. All right. Till next time.

Thank you everyone so much for, for supporting us on Patreon and on, on audible. We really appreciate your time and, you know, look forward to the next episode. Thanks everybody. music by eric parndollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute transmit the work to remix adapt the work but you must provide an attribution to to Patrick and I and share alike in time