The Changelog: Software Development, Open Source - From WeWork to upskilling at Wilco (Interview)

Episode Date: July 24, 2022

This week we're joined by On Freund, former VP of Engineering at WeWork and now co-founder & CEO of Wilco. WeWork you may have heard of, but Wilco maybe not (yet). We get into the details behind the tech and scaling of WeWork, comparisons of the fictional series on Apple TV+ called WeCrashed and how much of that is true. Then we move on to Wilco which is what has On's full attention right now. Wilco has the potential to be the next big thing for developers to acquire new skills. Wilco aims to be the ultimate simulator to gain new skills on a real-life tech stack. If you want to skip ahead, you can request access at trywilco.com/changelog — they are moving our listeners to the top of the waiting list.

Hey friends, this week on The Changelog, we're talking with Onfroyd, former VP of Engineering at WeWork, and now co-founder and CEO of Wilco. WeWork you may have heard of, but Wilco maybe not yet. We get into all the details behind the tech and scaling of WeWork, comparisons of the fictional series on Apple TV called We Crashed, which you may have seen, and how much of that is actually true. Then we move on to Wilco, which is what has On's full attention right now. Wilco has the potential to be the next big thing for developers to acquire new skills.

Wilco aims to be the ultimate simulator to gain new skills on a real-life tech stack. They are invite-only right now, but if you want to skip the line, you can request access at trywillcode.com slash changelog. They're moving our listeners to the top of the waiting list. Big thanks to our friends and our partners at Fastly. Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. This episode is brought to you by Sourcegraph.

With the launch of their Code Insights product, teams can now track what really matters in their code base. Code Insights instantly transforms your code base into a queryable database to create visual dashboards in seconds. And I'm here with Joel Kortler, the product manager of Code Insights for Sourcegraph. Joel, the way teams can use Code Insights seems to pretty much be limitless, but a particular problem every engineering team has is tracking versions of languages or packages. How big of a deal is it actually to track versions for teams? Yeah, it's a big deal for a couple of reasons.

The first is, of course, just compatibility. You don't want things to break when you're testing locally or to break on your CI systems or test systems. You need to have some sort of level of like version unification and minimum versions afforded. And all of that needs to be compatible forward. But the other thing we learned was that for a lot of customers, especially, you know, engineering organizations that are pretty established, they have older versions of things or even older versions of like SaaS tools they don't use anymore that they haven't fully removed because they're like not sure if it's still in use or they lost focus on that.

And they're spinning up old virtual machines that they're still paying for. They're using, you know, old SaaS subscriptions they're afraid to cancel because they're not sure if anyone's actually using it. And so getting off of those versions not just like saves you the headaches and the risks and the vulnerabilities of being on old versions, but also literally the money of, you know, older systems running more slowly or the build times or, you know, virtual machines and SaaS tools that you're no longer using. Before you had this ability, we talked to teams, there are basically three ways you could do this. You could slack a million people and ask for just like an update point in time. You could have sort of one human and one spreadsheet where like it's somebody's job every Friday or every two weeks to just like search all the code and find all the versions and write it down in a Google Sheet. Or there were a couple of companies that I came across with in-house systems that were sort of complicated. You had to know, you know, maybe

Kotlin, but you didn't know Kotlin. But if you want to use the system, you had to learn Kotlin and you'd have to sort of build the whole world from scratch and run basically a tool like this with a pretty steep learning curve. And now for all three of those, you can replace it with a single line source graph search, which is basically just the name of the thing you're trying to track and the version string in the right format. And then you have templates that'll help you get started if you're not sure what that format is. And then it'll automatically track all the different versions for you, both historically. So even if you start using it today, you can see your historical patterns. And then, of course, going forward. Very cool. Thank you, Joel. So right now there is a treasure

trove of insights just waiting for you living inside your code base right now teams are tracking migrations adoption deprecations they're detecting and tracking versions of languages and packages they're removing or ensuring the removal of security vulnerabilities they understand their code by team they can track their code smells and health and they can visualize configurations and services and so much more with Code Insights. A good next step is to go to about.sourcegraph.com slash code dash insights. See how other teams are using this awesome feature. Again, about.sourcegraph.com slash code dash insights.

This link is in the show notes. Well, we are joined by someone whose name I literally cannot pronounce. So I've been allowed to call him On, like he's always On. On Freund. On, welcome. Thank you. Thank you so much. That wasn't too bad, by the way, with the name. Very impressive, Jared. Good job. I've been Thank you so much. That wasn't too bad, by the way, with the name. Very impressive, Jared.

Good job. I've been practicing for minutes now. Behind the scenes, listeners, we've been practicing how to say his name and it is hard. I can actually confirm that really happened behind the scenes. Yes. Two letters, very hard. It's always, you know, the simplest things are the hardest, right? It's like software.

Yeah, it's true. Like that's a one point story. And then you get into it and you're like, oh, it's more like a 13. I like it. I like it. Dovetailing right into things. So let's get right into it. You're with Wilco, a new startup helping people to upskill, which I think is also maybe new

tech jargon. I don't know. Has that one been around a while? But I'm starting to hear more and more people talking about upskilling, which I just thought was learning. But help us out. Maybe they're on is upskilling like this new, cool learning lingo? That's a good question. I actually, now that you're saying it, you know, maybe we invented the word, maybe we didn't, but we thought it was existed. But I think what really differentiates upskilling from learning is that learning is usually focused on theory, whereas upskilling is more about the skills and bringing them up. It's how you take your skills and take them to the next level rather than learn some new theory.

Yeah. I guess it also kind of implies there's some sort of skills in the first place and you're going up from where they are, where sometimes learning can be like from a complete scratch, complete baseline. Correct. Yeah. Okay. Dude, I mean, this fast forwards a little bit,

it kind of rounds out all the skills you want to build to be a good developer. So not just writing code or understanding computer science or different aspects, it's communication. It's a lot of different things that come into play as it's sort of layering So not just writing code or understanding computer science or different aspects. It's communication. It's a lot of different things that come into play as it's sort of layering on like a cake. You're learning. Exactly.

It's all the stuff that you learn by experience, not the stuff you learn in college. Well, speaking of learning by experience, you had a heck of an experience as the vice president of engineering at WeWork before this startup of yours. WeWork's been in the news. It's been fictionalized. Oh, you've heard about it. Yes. Actually, what's funny was I was pretty ignorant of WeWork. I just thought like it's a startup that does co-working for a very long time until it hit Apple TV Plus with Jared Leto and Anne Hathaway. And I'm wondering how ignorant am I of it still to this point, having watched the series? Did I learn anything that was real or was it just all inspired by true stories? So I think the series was actually really good. Not a big fan of the Hulu documentary, but I thought the series was really good.

But it still is fiction it's you know it's based on a real story but it is fiction yeah characters have been merged eliminated made up butchered made up timelines have been completely mangled you know things that happen in 2014 show up as 2019 and vice versa, or things that never happened at all are there. I think it's a good show. I think that they managed to capture some of the spirit, but not all of it.

Will there be a season two, or does it conclude? Did you watch the whole thing to the end? I watched the whole thing to the end. I do not believe there's another season because the story was kind of over at the end right yeah well at least you know the what we know already has already happened right and it's done it was it was actually funny we have a whatsapp group of we work alumni and someone wrote something about not watching it and no spoilers please and everyone is dude, you know exactly how this ends. That's awesome.

Well, the fictional version of it. Sure. Yeah. But, you know, you shouldn't expect any plot twists if you've been through the ride. Yeah, I suppose. Yeah. The overarching theme is sort of set in stone based upon reality. Yeah. Hopefully. Hopefully. So it's interesting is sort of set in stone based upon reality. Yeah.

Hopefully. So it's interesting seeing where you're at now with Wilco and what you did there. How much parallels? Did you go through the pains that Wilco now solves there? Scaling? I think one of the big things with, as Jared was saying, understanding what WeWork. I almost call it WeCrash now just because. I'm sorry.

But I do know it's WeWork, I almost call it WeCrash now just because I'm sorry, but I do know it's WeWork. You know, WeWork was more of a real estate company than it was a tech company, at least from the outside. And having been in your position while there, was it a tech company and what did you experience there to sort of take into what you're doing now? How much translated to what you're doing now? So I think that these two things aren't necessarily mutually exclusive, right? So Uber is a ride sharing company and a tech company, right? Amazon is a logistics company and it's a tech company, you know, ignoring the AWS section and looking just at the commerce part of Amazon.

And just like Amazon, just like Uber, WeWorks technology is what enabled it to work at scale. And there is absolutely no way you can open the amount of desks that we were, you know, bringing to the market every month without really solid technology that does everything from finding the neighborhoods that you know should be the next locations uh managing the real estate process from prospecting to contracting and all of that the build out the day-to-day operations and then of course things like the member network that every member had access to with the app that actually let them do everything. But just thinking about a day, the first of the month,

and you have 30,000 people coming in and moving into WeWork that day, you just can't do it without the right kind of tech. And sometimes that tech is invisible. Like your key card that you walk into WeWork, you get it on your first day. You don't even need to do anything to activate it. Use the app to activate it. And then it just works. And it works in your building.

And it works when you change companies or when you change buildings. And it works when you book a room in a different building. It just works when you need it to. And it doesn't work when you book a room in a different building it just works when you need it to and it doesn't work when you don't like it doesn't give you access to buildings that you're not supposed to have access to right that sounds super simple that actually got us invited into you know hotel conferences because they can't get it right like how many times have you checked into hotel got up to your room realized the card doesn't work went back down and then they insert it into this machine that reprograms it

and we work hard never goes through reprogramming ever in its entire life cycle even when you return it you know switches to someone new so a lot of internal tooling really right a lot of bespoke brand new innovative brand new because nobody had really done what you had done at WeWork at scale. Like, sure, you've had office buildings with access and shared desk spaces and whatnot, but not at the scale globally like WeWork had been in comparison. Exactly. No one has even managed a real estate inventory at that size with that model. Right. So, you know, the hotels have what's called PMS property management systems. And we looked at a lot of them. They, you know, we couldn't get them to work for our model. It just,

it doesn't fit. And even hotels, you know, when they go through mergers, you know, let's say Hilton buys a property somewhere. Now they have to integrate all the systems. That's actually really complicated in itself. But then every property is kind of like its own domain. Whereas at WeWork, you wanted everything to be part of the same system. Like a guest at a Hilton doesn't book a room somewhere else and has to go seamlessly with the same key card the next day, right? But at WeWork, everything is connected. So just managing that scale, managing that model, nothing like that ever existed before.

And you see that in other co-working space companies where they might do well on the first building, maybe second one, third one. But then you realize that those buildings are actually running on the hustle and grit of the founders. And it's really hard to get over that, you know, five building hump, definitely not 10 or 12. Right. Yeah. What was your time period there? So I joined in the summer of 2014. We had about a dozen buildings. My employee ID, I think was 114 or something like that. Pretty early then.

But we were less people than that because not everyone stayed. It was a very different company than what it became when I left in October of 2020. And it went through crazy highs and crazy lows. And eventually you could say I did nothing at the company because it ended up being worth the same as it was when I joined in 2014. So I contributed nothing to society for six years. I wouldn't put it like that, but I get what you mean. So one of the things that the We Crashed show portrayed, which I love your take on, in light of some of the things that you're talking about,

the things that you worked on while you were there, of course you were not doing nothing for six years. You built a lot of things. And there was this plot line where it was like Adam Neumann had to continue raising more money. And he had a harder time raising money around a co-working real estate company than he did around like a software startup company. Because of course, VCs want to invest in things with like huge margins, right? And so he had like this whole, it's like, it's a tech

company, it's a software company. And the insinuation from my take of watching the show was like, but he was kind of making all that up and it never really was and i'm wondering if in light of what you've been telling us like does that sentiment offend you or do you think it's like made up whole cloth or what are your thoughts on that it does because it's you know it's close to home and it's one of the most inaccurate parts of the show so okay, the whole show is Adam talking to Masa sometime in 2017, I think, or 2018. And then making up a technology department for the company, calling it WeWork Labs. Right. Now, WeWork Labs was a completely different thing, by the way, which I also did at some point and loved and had nothing to do with technology.

It was a startup program for members who were running their startups. Like an incubator? Not really an incubator, but more like an ongoing program where you can get more than just real estate. If you join WeWork, you get more support and access to investors, help with BD, et cetera, et cetera. Oh, I see. So that was WeWork Labs. And it was a great program. We've had like 87 locations worldwide, and we were helping quite a lot of startups. So it was like a customer perk, like it was a perk of their customers.

Exactly. Okay. Oh, that's cool. Yeah. But WeWork technology existed since way before i joined you know when i joined we already had like nine developers or so when i left uh or let's say before the the whole show uh show um so before the show we were think, a thousand developers at some point. Wow. That scale right there. Dang. That scale. And it's not as if, you know, Adam said, oh, we need a technology department.

Let's hire a thousand people. You know, that grew organically. Right. Over, you know, from sometime in 2012, I think, all the way to 2019. So you said nine when you began in 2014. Is that correct? Yes. And it was founded in 2008.

So that's right. That's six years of growth before you joined. I mean, rough founding date. 2010. Okay. Google says 2008. So I was based on Google's. When did WeWork get founded? So it says 2008 in Soho. So 2008 was GreenDesk. That was Adam and Miguel and a third partner. Okay. The third partner ended up buying Adam and Miguel's share of GreenDesk, and they went on to start WeWork. That was in the show? That was in the show, yeah. Yeah. Okay. Okay. So let's just say 2010 then. So you got four years of business growth and the need for technology. You got nine developers when you begin. That's in 2014 and a thousand in 2020. Is that accurate? Yeah, but also we've had a dozen buildings

when I joined in 2014 and we had about a thousand in 2019. Yeah, the scale is insane. So, you know, a developer per building, that doesn't sound too bad. I don't know. Right? I would say, yeah.

So we found on your on we work technologies blog matt star went through the history of we work.com uh this was written back in 2017 so and i think you're thanked for helping contribute or something to this post and it's a nice kind of run through of that's just the.com like the technology behind that started off as wordpress and there was a new wordpress theme yeah then ruby on rails then there was like we're rewriting the whole thing and it was like now it's node.js and that's the stack site generator like there's this thing was like iterated on almost just like thrown out and started over it sounded like i'm sure you had something to do with that as well was that part of your job there yeah so i mean obviously when you make it sound like that it sounds like all we did was just rewrite the website, but, um,

No, not all you did, but like somebody was doing that work for sure. Right. Someone was doing that, but the goal wasn't to rewrite the website. It was just, you know, the website, our front facing website went through several changes of a brand. And many of those brand changes were also an opportunity to rewrite the site in a way that we thought was more maintainable. Yeah. And B, also a big part of joining WeWork happens on WeWork.com. So this was actual business logic, you know, on the website that was going through a lot of changes. But it's not as if, you know, every one of those iterations, we went ahead and said, all right, let's dump everything we've done so far and do something completely new. It was more iterative than it might sound.

You know, we have this back end working. We have a new brand. Let's use the opportunity to maybe switch over to a static website on the front end with an API. What's today is called Gemstack. Right. But back then, I's today is called Gemstack. Right. But back then, I don't think had a name yet. But it's not as if we started it from scratch.

Sure. It's a really nice post. We'll link it in the show notes. One of the things that's cool about it, as he goes to each iteration, which I think it's called John Quincy Adams, because he was like the sixth president. And this was the sixth major revision of the dot com. I'm not an american so don't ask me to you know quote presidential names and numbers not going to work i'm i am an american but please don't ask me to quote presidential names or numbers i'm just reading from the blog

post i'll say what's cool about it is to your credit like the the logic and reasoning goes along and like what we're trying to improve on each version and what things we're experimenting with. And he even goes as far as listing how many current buildings you all own at the time and then how many countries you're operating in, which is kind of, it's a nice way of telling that story. By the way, countries are one of the biggest hurdles and one of the biggest needs for technology. So just being able to bill in multiple countries is super complicated, especially when you have customers that are cross border. Right. You know, you have Amazon in Germany and Amazon in the US or something like that, and you need to bill them. It's super complicated. And you know what, we actually went to a lot of billing companies. And we asked them, let's say we decide on a new market we want

to open how long would it take you to add that country's billing to your system and they said well you know it would take us about two years to add a country and we're like we're going to open a building in six months actually build it and do everything around it. Right. And it'll take you two years just to do the billing and ended up having to write our own billing system because of that. Wow. Well, when you scale beyond the speed of others, other vendors, in this case, you know, you have to, right? You have to build the team to innovate.

You have to do the innovation because they're not motivated necessarily to move faster than the two years. I mean, sure, they'd like to, of course, but if they just can't, you need to, you're already building the building, there's ground broken, so to speak. Exactly. And you know, that's why Amazon started AWS. They needed all of those computing primitives to work for them so they can run their business on top of that. So the scale is obviously a huge factor, but in addition to that or beyond it, I guess, what were some of the biggest challenges that you faced in your tenure at WeWork in terms of engineering? Well, I had to explain why WeWork needs an engineering department about 10 times

a day. That was one of my biggest challenges. Who'd you have to explain it to everyone my parents i had to explain it to my parents every day and um you know just reporters candidates you know peers anyone would basically come up and ask me really why does we work in the technology department and everyone seems to think it's so easy to run all these buildings and you know if i had a penny for every time someone said oh that's easy i'm gonna open my own co-working space um at a building yeah you know maybe i could have funded the we work instead of having to go for an ipo the next we work around well as you said too it's it's so invisible right the technology you built was so invisible because I guess you just assume

key cards just open doors and that's easy, right? Or that you never have to reprogram it. Like the tech involved in not having to reprogram it every single time, like a hotel might, for example. I actually think that a transparent product is sort of a perfect product. So there's a difference between perfect and best because perfect is kind of a, like a

local maximum. Everything you do is going to make it worse. And a transparent product is just like that because everything you do is going to make this worse. If we changed anything with our key card algorithm, it would have made things worse, but no one notices it. And that's, that's amazing. Like the things in your life that you don't notice are the things that are really working well and someone who would try to replicate we work would get that wrong it's like if you know if if you ever moved into a house that you were involved in in the construction phase then you sort of think about all these things that you got wrong and you're like oh next time

um i'm building a house i mean people don't build houses that often but like next time i'm moving somewhere i'm going to make sure that the kitchen has this and that but what you don't take into account is all the things that actually worked right and then if you had to redo everything you'd probably get a lot of the basics wrong because they just worked the last time. You didn't notice them. They were just there. All the pipes are in the right place. Amazing, but what guarantees they'll be there

the next time if you don't pay attention to it? Yeah. I've used this analogy before, mostly around open source infrastructure and how that's invisible and therefore doesn't get the attention that it needs in order for it to thrive. And it's the analogy, maybe

this will be lost on you, An, because you're not from the States, but in American football. I don't know if you ever watch American football. Oh, I'm a huge fan. Oh, you are? Okay, so this will work out just fine. So the offensive line... I did live in New York for five years. Okay, good point.

But then you got the Giants and the Jets, so I don't This'll work out just fine. So the offensive line. I did live in New York for five years. Okay. Good point. So you're, but then you got the Giants and the Jets. So I don't know sure how you became a football fan. Of course, Giants. Go big blue. Come on. Easy.

Somebody else listens in. Of course, what? Come on on. Somebody's out there rooting for the Jets. Probably Gary V. Gary V. He's like,

yeah, the only Jets fan left. Just kidding. Jets fans. So the offensive line are very much like that. Like when you're, when off the Jets, probably Gary V. Gary V is like, yeah. The only Jets fan left. Just kidding, Jets fans. So the offensive line are very much like that. The offensive line does their job just right, which let's just simplify it down to protecting the quarterback. There's other things, right,

on running plays and stuff. When they protect the quarterback and he gets the pass off, the cameras are not on them. The quarterback's thankful to them, but the fans aren't paying attention to them. The only time the offensive lineman

is featured with his big old mug on the television zoomed in is when he just missed his block and the quarterback got sacked. Right. That's like the transparent feature. That's like the software that nobody notices

when it does its job right. There's no glory there. Being a Giants fan, I actually don't know what a functioning offensive line is. I haven't witnessed one for about 12 years now. I'm loving it. Yeah, fair enough.

But if you did, you'd ignore it. You'd take it for granted, right? I think we had an offensive line at some point, you know, back in 2008 or something. Yeah, that's tough. Some roles, they're just like, there's no glory there. And it sounds like, you know, running the software team for a co-working company,

regardless of the scale of like one building to a thousand, people don't give you any respect. They just think that's like just an easy thing to get done. That's why you go ahead and you start a pure software company afterwards because then, you know,

people are going to... I was going to say, this leads us into Willco, right? People are going to want you on podcasts all of a sudden. Right. And, you know, are going to... I was going to say, this leads us into Willco, right? People are going to want you on podcasts all of a sudden. Right. And, you know, the news cares about you in a non-gossipy way. Yeah. Software's great. Who needs operations?

Sounds like you're learning and adapting. Never stop developing. Yeah. Which also works for real estate, by the way. Never stop developing. This episode is brought to you by our friends at Fire Hydrant. Fire Hydrant is the reliability platform for every developer. Incidents, they impact everyone, not just SREs. They give teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum are responding to an incident. They can all be automated in every way with FireHydrant.

They have incident tooling to manage incidents of any type with any severity with consistency, declare and mitigate incidents all from inside Slack. Service catalogs allow service owners to improve operational maturity and document all your deploys in your service catalog. Incident analytics allow you to extract meaningful insights about your reliability over any facet of your incident or the people who respond to them. And at the heart of it all, incident runbooks, they let you create custom automation rules, convert manual tasks into automated, reliable, repeatable sequences that run when you want. You can create Slack channels, Jira tickets, Zoom bridges instantly after declaring an

incident. Now your processes can be consistent and automatic. The next step is to try it free. Small teams up to 10 people can get started for free with all Fire Hydrant features included. No credit card is required. Get started at firehydrant.io. Again, firehydrant.io again firehydrant.io so now you are here with a software startup that's right in your face.

No more transparency behind the scenes. Wilco never stopped developing. You raised some money. You released a product like number one on product hunt for the week. And I think it's like number three for the month, which is a great launch by darn near any measure. Tell us what you're up to. What are you working on? Gamifying upskilling is what I would call it.

But what would you call it? Yeah, it's not a bad way to call it. We spoke about upskilling in the beginning and what it means. But it all started with the realization that the only real way to gain experience for developers is on the job.

But when you gain experience on the job, it's a very slow, people take years to sort of gain the initial experience that they need. But after that, it's even slower. Because the more experienced you are, the less likely you are to come across, you know, new types of scenarios. B, it's very error prone i'm sure you you know firsthand witnessed many production outages deleted database tables etc etc and c it doesn't provide equal opportunity because you and i could be starting at the same company same time you're both of you are way more talented than me, but I get to a team where I get better access to production or better mentors. And I'll very quickly open up a gap that's going to be really hard for you to close. And if we're talking about groups that traditionally are underrepresented in

tech, they already have an experience gap and they tend to get to teams that don't actually allow them to close it. So you have this problem of gaining experience, but everyone in the world is trying to teach you the theory of writing code, but who cares about that? Like, why is writing code that important? You know, you start your first day on the job, your manager is not coming up to you and saying, hey, write me some code. Here's a function, do something with it. Your team lead is probably going to say, you know, hey, get yourself acquainted with the team, first of all, but guess what, nothing is actually prepared you for working on a team if you went to college or boot camp, or definitely not an online course. And they're going to say, you know, get

acquainted with the build system and with the architecture of our product. And then you're left kind of speechless. I'm like, wait, you know, where's all the stuff I learned in college? Like, where is the list I'm supposed to reverse? Right. And all of a sudden... Can I write you a bubble sort? and you're completely unprepared. That's what happened to me on my first day on the job. And I, by the way, got to a very dysfunctioning team on my first job. And this was kind of a blessing and a curse because on the one hand, I had to touch production on almost a daily basis because something was always breaking.

But on the other hand, I didn't have good mentors. I didn't really have a good team that I can bounce ideas with. I had other colleagues and other teams that helped me out quite a lot. But, you know, that experience shaped a lot of what ended up being Wilco, not going to say how many years down the line. And then everyone's so obsessed, like I said, with writing code. And a friend of mine gave me this great analogy, said, if I want to know the state of the art in medicine, I'm going to go to someone who just graduated from med school. But if I need someone to operate on my shoulder, I'm going to go to a surgeon with 15 years of experience. And it's kind of like that for software engineers. If you're fresh out of college, you're probably doing bubble sorts way better than someone with 20 years of experience. But if you need someone to write a production system, if you need someone to maintain

it, if you need someone to build a team and the culture for that team and the workflows and have things like an on-call rotation and all of that, you need someone with practical hands-on experience and there's just no way to get it. So how is Wilco going to give you that? Because is it actually real? I mean, it sounds like there's no way to get it, but is this going to close that gap somehow? I know what you're up to, but at the end of the day how real can it be if it's not real well it's not real real but we try to keep it as close as possible so simulation yeah i mean we looked at we looked at other domains and try to see all right what are other people doing to solve that problem and we looked at pilots and they have a flight simulator because guess what a regular

flight is not going to prepare you for that time you need to land on the hudson right right you know captain's call you had to train on the simulator to do that and we said all right let's do the flight simulator for software developers and then we came up with this idea of joining a fantasy company but we really wanted all the complexity of real life in it so that fantasy company has a production like system with logging and monitoring and analytics and load balancing and it has a real data set not just five records in a single table and it has the biggest mess of all which is other people so you know you have your team lead and the DevOps person and colleagues and product managers and all of that. Now you need to figure out how to work at that company and

run through all sorts of scenarios that we call quests. So a quest could be, we have a performance problem in production, figure out what happened, what's the root cause, what's the extent of the damage, fix it, and communicate it to stakeholders. Now, you might have learned how to fix it in college or at a boot camp, but how do you even know that something's wrong in production? What do you do to investigate it? When do you go for a quick and dirty fix? When do you go for something more meaningful? How do you ensure that lessons are learned and implemented? All of these things, these are the things that you can only really get by playing around and making mistakes. Learn by doing is the old adage, right? Like you had said before, you learn on the job,

that's learn by doing. In many ways, either you're going to pick up a side project, a thing for you to play with while you also work to to gain experience. You might play with a brand new framework just to see how it works or whatever. But you have to learn by doing. And I guess that simulation is that is that doing and probably the most comfortable way possible joining an actual company or a fictitious actual company. Right. Sort of an oxymoron there. But, you know, you got Vanessa, also known as Ness, awkward if you call her mom. You got Navi, you got Ben.

These are some characters you find. And maybe I'm jumping the gun a little bit, but the first thing you do really is you get invited into Snack, which is a play on Slack, I'm assuming. I think that's a fair assumption. Probably exactly that, right? It's a corporate messaging tool. Right.

That may or may not be related to some other brand you know, but it's its own corporate messaging tool. Sure. What I think is interesting, though, is that that's such a real-world scenario, right? It is a real perfect simulation of what will probably happen. I was just telling Jared before this call, like I have done what we've been doing here at ChangeLog for a while. So our slack, our snack is, you know, I've never joined it as a new person to join the organization. So my empathy and my familiarity with doing that is so foreign because I haven't done it. But if you're a new engineer going into a new role out of college or changing jobs or whatever, like this is a every new change job scenario. Meeting the new team, finding the repositories, understanding the code base, what is the domain knowledge, what are the complexities?

You know, how mature is the team? How mature is, you know, is it a, you know, a monolith or is it microservices? Is it, you know, many repos? Is it, you know, what is all these different things you have to figure out to sort of like understand the foundation you're standing on? And some of that you learn in the interview process, it may actually be part of your, you know, criteria you use to select your job and choose that team and go that direction but like this is so so similar to like what it would take to join a company i think it's it's kind of profound

that's that's how you land that's what you're doing here because that's exactly what you do when you join will go yeah exactly and you know all these side projects are great but they usually don't actually get to flex your team muscles, right? Because you're working on your own on the side project. Or maybe it's a very big open source project, but then in many cases, it actually doesn't operate like a company. It's very different. And, you know, I contribute to open source a lot, but there's no production instance that I have to take care of. It's usually things that other people run on their computers, or maybe it's libraries that people use, but it's not an actual system I have to maintain. And there is no team in the traditional sense. And all of

these things are what we really wanted to make sure that you get exposure to with Wilco. So I've also met Vanessa, a.k.a. Ness, and Adam and I have gone through the first run experience with Wilco. Love the concept. Love what you're doing. A lot of the reasons that Adam also explained resonate with me. Snack is very clever. I wonder how much. It's completely original.

I don't know what you're talking about. It has nothing to do. I wonder if you need to change some more letters for you guys to stay out of any sort of, all of the characters are completely fictitious and any, any relation to everything is, is made up. Yeah.

Okay. Disclaimer aside, uh, next time I'm bringing in my legal team for this, for this podcast. Let's talk about the Uncanny Valley because flight simulators have to be incredibly realistic for them to be effective and useful.

And I know this is a just launched product and you guys are on your way. Once you start trying to talk with Ness, for example, and as you would, if I join a team, and maybe I'm just a weirdo, and my tech leader, my boss, is talking to me, I try to build a little rapport. And the first run was like, oh, I'm loving this simulator. It's all a real company. So far, I've gotten to install Docker phase. I'm not very far in, right? Like it's like, it's like this first question take an hour. It's like, well, I don't have that much time, but I have Docker installed. Uh, but I haven't got to where I'm actually doing things yet. I love the different quests you have laid out, search party, fixing a

bug, a funnel drop, these different names, performance, et cetera. But you're still at a phase where like, it feels real until it's not real anymore. And you're like, Oh, Ness is like a pretty simple chat bot. If that, like maybe at this point, it's like a few hard coded answers. And I'm trying to call you out here,

but I know you guys are just getting started. I'm curious what the plans are and like fleshing out this universe, because it seems like you have like all these hooks to hang things on. And you maybe need to like get us further across that valley before it's like doesn't it need to be believable but i have to be able to like suspend my disbelief a little bit yeah and feel like i'm part of a team you know yeah sure so you know first of all ness is one of my favorite characters and not that we have that many but she's one of my favorite characters and right i can actually envision her responses to different scenarios.

But you're right. The product is still not completely there. She's not the most sophisticated AI bot out there. It's good for now. But she's obviously going to become better as time goes by. And you're also going to get other characters involved. And each one of them might have their own quirks. So here's a scenario from real life,

you're rewriting a legacy component and the person who wrote that component actually feels very attached to it and doesn't want to help you. And that's something you have to deal with, right? But that person is going to be, you know, an NPC, an unplayable character. Right. And we will try to make that obviously as realistic as possible. And one of the things you'll have to figure out is how to get that person on your side or how to get their support despite the fact that you're, you know, trying to destroy the very thing that they love so much.

Real world office mechanics, you know, like the power struggles, real world office mechanics you know like the power struggles the passive aggressive you know circumstances exactly and maybe maybe you know there's a developer with a big ego and you find a production bug and they say that their code is perfect and they're it can't be there it has to be somewhere else right right it's a feature yeah when i was young i used used to tell product managers that, they would ask me, what would the product do with this and that? And I would tell them, just tell me what it does and I'll tell you why it's the right thing.

You use the term AI bot, is that accurate? Or is it a misnomer at this current state? Is it truly an AI bot or is it a complicated fl statement it's on the spectrum between a very simplified automated can responses and a full-blown ai bot right and it's getting better by the way all the time um so you know we've picked up on quite a few things about transparent like that's the kind of feature that could get better or you know now that you have the framework in place. All you're doing is modifying the responses.

Everything else is there. Exactly. And you really need that corpus of conversations to make it better. It's really hard to make it perfect the first time you're out. You really want Ness to interact with a lot of people, hear how they respond, how they try to you know plant all these

traps for an s and then you can make her better so we mentioned the simulator uh i brought up gamify because in addition to this like faux reality that you're working in you also have a lot of the game mechanics of badges and point xp and will coins which i'm not sure if that's a web 3 thing or just a cool name for a web 2 thing are you gonna help us understand that but uh tell us some of the other ideas that you have at play i know that's just like you're getting these things out there and they're not all fleshed out but what are some of the ideas so actually a lot of it is fleshed out, even if it's not there in the product just yet. But I also don't want to give away too many spoilers. But let's say that anything, the fantasy company that you're joining has way more than meets the eye to it.

It might not be the company you think it is. Oh, so this is going to get even more interesting as I get further into this. That's what you're saying. Exactly. You know, developers, they have an intrinsic motivation to become better. You know, I was listening to the podcast you did with Lee Robinson, and he talked about education quite a lot and how that's the part of the job of a dev rel. And he mentioned how developers are always eager to learn more but the thing is all of it is usually very boring you know all of it is very top down and that's why we wanted to do something very different and do it in a game-like environment so they actually feel

you know like they're having fun along the way and you know we brought in an amazing game designer and we brought in amazing graphic designers. Not that our game is like 3D shooter graphic level, of course. But, you know, getting all the graphics down, you mentioned the quest names, but also their covers and all of that. It really had to be a very specific design for it to work, for to feel fun yet genuine and inviting i think jared said that before suspend disbelief i think that's a key ingredient here you know you gotta have one you gotta have fun but then it's gotta look good and be believable to suspend that belief or that disbelief like you want to you know it's a game because you signed up, right? You opted in.

Somebody didn't make you do this. Maybe we'll get into that because there are team involvements. It's just like that movie, The Game, with Michael Douglas. Yeah, I hope I don't find a clown in my living room. With a key.

With a key, exactly. It's got to be believable enough, though, right? To suspend that disbelief, you've got to have a believable enough. That is one, you know, quality. Two, having fun. Actually, how it looks, how it responds. You know, that's a necessity for to, I guess, suspend this belief, but then also let go a little bit and have fun, which is really where learning really is key. That fun component is a psychology thing. You learn way more and you get

more immersed in it and you retain that knowledge much more if you actually have fun, enjoy the process. It's kind of like exercise. I get better results when I enjoy the process of exercise. Totally. I'm not a big fan of just going and lifting weights for the sake of lifting weights. I'm more of a fan of going and being active, riding my bike or doing different things. That's where I exercise better. So that's because fun's a component of it. Exactly.

And that's why we sort of have two brands, which is Wilco is the fun brand and it happens in between the quests. And then when you're in a quest, you're in anything, you know, the fantasy company, and that is trying to be more real. And it's kind of like if you play a first person shooter, then between encounters, it doesn't feel very real. Like you're never preparing for an encounter. You're never having to deal with defects in your gun or anything like that.

But when you're in an encounter, everything is real. And they try to mimic reality as closely as possible. And you have to get aiming to work right. And you have to get, you know, the action of the gun and all of that. Worst metaphor ever, sorry. But that's kind of what we went for. You know, when you're in a quest, it has to be very realistic. You're talking to your colleagues on an actual chat product, you're using your IDE, you're using a command line.

But then in between quests, you have that fun, well-co-brand and design that ties everything together. I was thinking before too, familiarity. When you're new to the workplace, you have no experience to say this is normal, right? And it's almost like that, like this simulation is a version of what might be normal be, you know? And so if, you know, the fact that it's so similar to what normal might be is kind of like reassuring because if you have no experience to know what normal is, then it's kind of like, well, this is pretty close. And this prepares me, despite my lack of experience, my lack of having a first engineer job or whatever it might be, as you upskill, so to speak. You've gone through a boot camp, but have you actually worked somewhere before?

And it's not just about coding. It's about team interaction. It's about understanding the code base. It's about domain knowledge and all these different things that are involved in doing your job, not just can you reverse a string, for example. I couldn't have said it better.

Thank you. So as you all are imagining this world and creating this world, there's a lot of different aspects that you're talking about in psychology and storytelling and design. I'm just curious, where are these skills coming from for you and for your team? I know before the show you mentioned you're a film buff, so I guess somewhere in there's like storytelling hooks, right?

But how do you know that what you're doing is compelling, is going to work, is going to actually pay off at the end of the day? Do you have history in building like immersive games like this? Or is it just like, well, we're going to give it our best shot? What's the deal with that? Well, luckily, you know, I don't have to do everything myself. We do have a sizable team and we have a game designer and she's built a lot of immersive experiences,

both online and offline. So she knows. And in the beginning, she would keep saying, we should really do this and that. And we were like, oh, that's never going to work. And eventually we said, all right, we know, we trust you do it. And guess what? We were always wrong. And she was always right. And game designers apparently know what they're talking about. And, you know, our graphic designer is a big game buff. She actually writes for an Israeli

publication about gaming. So she knows, you know, what are the right graphic elements to make a game work. And even though it's not your typical game, you know, you can't really put it in any genre of game per se, but the mechanics, like you said, need to work. And having the right people who've built these types of things obviously helps a lot this episode is brought to you by sentry. Build better software faster, diagnose, fix, and optimize

the performance of your code. More than a million developers in 68,000 organizations already use Sentry, and that includes us. Here's the easiest way to try Sentry. Head to sentry.io slash demo slash sandbox. That is a fully functional version of Sentry

that you can poke at. And best of all, our listeners get the team plan for free for three months at the Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog. And by our friends at MongoDB, the makers of MongoDB Atlas,

the multi-cloud application data platform. Atlas provides an integrated suite of data services centered around a cloud database designed for scale, speed, and simplicity. You can ditch the columns and the rows once and for all and switch to a database loved by millions for its flexible schema and query API. When you're ready to launch, Atlas layers on production-grade resilience, performance, and security so you can confidently scale your project from zero to one.

Atlas is a truly multi-cloud database deploy your data across multiple regions simultaneously on aws azure and google cloud yes you heard that right distribute your data across multiple cloud providers at the same time the next step is to try atlas free today they have a free forever tier prove yourself and your team that the platform has everything you need head to mongodb.com slash changelog again mongodb.com slash changelog So you said this was a software company, though. So far we've been talking a lot about games. Where's the software? What's the software stack?

Give us a glimpse into the software stack. What powers this cool simulator? Well, what powers it is an engine that we've built that takes a quest in a domain-specific language and turns it into a quest in multiple different stacks. So we write a quest once, and then you have the Python and PostgreSQL version of it, but you also have the Node.js and MongoDB version of it. It doesn't work for all of them. If this quest is specifically about adding indexes to a SQL

database, then obviously the Mongo version is not relevant. But in most cases, it's a write once, run anywhere kind of engine. And, you know, we just added Python support last week, at least at the time of this recording. And we don't have to build every quest in Python anymore. We just, you know, build new quests, and they're available in all the languages that we support. So that is, I would say, our main piece of technology. And eventually, we'll have an editor that actually lets anyone create quests on top of that engine. And this could be the individual that wants to show off, hey, I built the Kobayashi Maru. Or this could be a company that, for employer branding purposes, is saying, this is what

a typical day at our company looks like. And by the way, when you're done, send us the output the output let's see if you're a good fit wow or this could also be a company that is reaching out to developers or catering to developers and you know a lot of these companies are already spending a lot of time and money and advocacy and it's blog posts and it's videos and and its conference talks and manuals and references and you name it. But we give them something that actually allows them to give their third body developers actual practical hands-on experience with their product. That's really interesting to go from this upskilling opportunity to a not just upskilling, but also great fit opportunity. Like I might be able to in the future simulate what it might be like to work at XYZ.

WeWork, for example. They may eventually be a client, which could be so cool, honestly. Exactly. To use your simulator to simulate the possibilities of working at WeWork. That would actually be such a cool thing. Call us when that happens. Exactly. And you know what?

The interview process is, you know, obviously everyone knows it's broken. But one of the reasons it's broken is the same reason that developer education is broken is because it's too focused on one specific skill, writing code. And I know amazing coders who are really bad developers and vice versa. Writing code is just not the most important skill, but that's what you test in a job interview. The issue, though, might be where you get this Instagram effect where the artifact for which you test against to consider

the employment opportunity or the joining of a team may be flawed in the fact that it's filtered. Like who's going to actually design a quest that is the perfect version? You know, like they're going to round the corners of certain things. It's not going to be the unfiltered version of the company, let's just say. I'm curious how accurate you know, how accurate, if you get to that point,

that that will be true. Of course. You know, maybe in that case, you can hire an auditor or a third party person. I just, I'm just saying like, you know, somehow it won't be accurate.

Now you're just trying to, you know, increase my burn rate. I need auditors and all that. But, but seriously though, obviously any, I mean,

auditor in terms of like somebody to audit the company to see how true it is before designing it you know i totally get it but you know obviously part of what they buy you'd make money this is a revenue generating thing i'm making products on a fly every representation of a company is always somewhat falsified true not mean, falsified maybe is a very harsh word, but like you said, corners are being rounded and it, the same goes for a video that they produce about, you know, working at company X. Right. So don't blame the medium. It's not, it's just a, it's just another medium. And people are still going to, like you said, create that Instagram effect and make it look perfect. Sure. Well, the one thing it could do accurately is simulate a stack, right? Because you point yourself to a repository, you pull that down, you install Docker, you spin Docker up, you go to a local host URL, you simulate chat with some people. Maybe those are NPCs and examples of people, not so much people that work there.

But you can simulate a stack and what it might be like and it might even improve you know dev setup potentially even you know like pick out all the flaws i mean there's a lot of really interesting permutations how this can work out but i was thinking about it for that same angle adam but from the side of the stacks so this of course assumes that you have success and like there's like this gravity effect which we hope you get too because it's cool stuff but I like that assumption yeah I'm going to take it yeah it assumes that let's just state that as

future reality imagine now that you have this like in between this engine that goes between technologies and games right quests well you can have people writing the quests of course now you're like super mario maker and that would be rad oh my gosh yeah or you can have people who have the

technologies imagine a brand new startup technology like dino for instance and they're like oh there's a node.js track we want people to have quote-unquote real world experience with dino dino's brand new nobody has that yet We have now a motivation to go ahead and create a Dino stack that you can plug into this game. And now you can say, yeah, I went through Wilco, this quest in Dino and I have

six months experience or whatever that would equate to. That's true. That would be kind of cool. Exactly. And we're doing similar things. So if you go on our platform, you'll already see quests that were developed together with New Relic. Okay.

And those quests practice observability, not just with New Relic tools, but mostly with New Relic tools. Right. And, you know, that's an important... Now Adam's dreaming. I can see him dreaming over there. Yeah, I am dreaming.

I'm sorry. You got it. I almost cut him off to throw in a dream, but I can't do an important... Now Adam's dreaming. I can see him dreaming over there. Yeah, I am dreaming. I'm sorry. You got it. I almost cut him off to throw in a dream, but I can't do it. I'll just be quiet. Keep going on. He's just... I get to see Adam dreaming. You got him going.

And, you know, that's an important skill to have, right? Understanding how to instrument production or even understanding that production needs to be instrumented is a skill of its own. And by partnering with Neuralik, we were able to do that. And yes, we could partner with companies that do their own tech stacks or do their own database or whatever it is. As long as you're trying to get developers

to use your products and to train them on your product, it definitely makes sense to do it on Willkub. I feel like a salesman now. What's the closest thing we have in the technology world that is a simulator? Is there anything like that out there currently, aside from maybe like an ad hoc version of something that might be like this? Like a platform. This is a platform to do it. Or at least that's the dream, the ambition that you're driving towards.

Some of these things will become true or not true, but is there anything that simulates any of this currently? So there are things that try to be sort of a sandbox environment within your browser, but that usually ends up being very simplified, oversimplified, and is always designed to get you as quickly as possible into a function you need to write or rewrite. But it never actually gives you the simulation of a real system, let alone a real company. Right.

That, you know, we tried to look for something like that. And as Alon, one of my co-founders, likes to say, if Wilco had existed, we didn't set out to start a company. If Wilco had existed, we would simply join it. But we couldn't find anything like it. What made you want it to exist? For me, it starts in 2014. We're three co-founders. Each one of us has their own journey that brought them to where Wilco is today. And eventually Wilco is the synthesis of this vision of three different people.

For me, it started in 2013. I just joined Handy as VP of engineering. And we raised a nice seed round, but we didn't have a lot of money. I was rather new to New York, and I didn't have a strong network just yet. And we were just starting to build out our engineering brand. So I realized I have to compromise on something as I'm building my team. And I said, All right, I'm going to hire a team of the best and brightest from the best schools, but they're going to be inexperienced. Because, you know, they can write amazing code. So what's the problem? And guess what? Like I said, many times today, writing code is, is not that important. So I had to mentor them very closely. And at some point it became unscalable. Luckily by then I was able to hire more people that would help me with a mentorship burden. But I reached out to a few boot camps and I said, let's do this evening class where we expose developers to simulations of real world events. And I believe that that way, within months, they can gain the experience of years.

All the boot camps said, we're focused on zero to one. We don't really want to do one to 100. And then at some point, I moved back to Israel, and I tried it with the Israeli boot camps. And I heard the same response. And then at the end of 2020, I left WeWork. And I called up one of my former colleagues, and I told him about this school that I've been meaning to open for a while now. And I said, you know what, I'm going to go for it as like a side project with, you know, I have a little time off. I'm going to do this as a side project. And I already called up a few CTOs.

They all said, this is great. We're going to send students your way. And that former colleague told me that I'm stupid. So I asked him why. And he said, well, you know, you're going to have six, maybe 10 developers per class. You're not really making a dent in the universe. Let's figure out a scalable way to solve this. And by the way, a third existed. And then we realized that everything is so top down and developers hate it. And we realized that there's nothing that actually simulates all the words and all, not just a perfect code base with a simple function that you need to write. You know, we need to actually simulate all of the

bad things as well. And then we realized that it's not about taking juniors from one to 100, but you don't really have a way to practice throughout your career. You know, going back to the flight simulator analogy, it doesn't matter how many years of experience you have or how many hours of flight you're logging every week. You still have to go through the simulator. And the fact that we don't do it as software engineers is pretty crazy to me. And apart from not letting us advance, it's also very demotivating. You know, I have a lot of

friends who are senior engineers. They love the company they work for. They love the team. And they're telling me, I think I might leave. And I'm like, why? You love everything about this job. Well, I'm not being challenged anymore. I'm not seeing anything new. So I asked them, are you going to switch to a different company that you're most likely going to like less than the company you're in right now, just because you're going to gain new types of experiences and they say yes and this is somewhat tragic right and you know what if they could have access to new scenarios without having to leave the team they love so much what if they could continue to practice and become better at the same pace that they could become better when they just started out.

And no, that really guided a lot of the thinking behind Wilco. Well, it's this idea too of being able to mess up. I think it's kind of key too, especially in that scenario where you got a senior who is sort of perceived by themselves as being stagnant in terms of their new experiences and new learnings and growth and whatnot. It is this ability to do things and mess up. And in a career, you can't mess up, right? Like if you mess up, you can not get your bonus.

You can lose team members. You can lose trust. You can lose all these. There's a lot of loss possibility in the real world. And I think the one interesting thing here with this is that you can have an area where you can actually mess up and if i mess up in in wilco you know what what happens in wilco stays in wilco so to speak you know you know that's that's the you know and that's a good thing i think this is the same thing for pilots like i would love my pilot to have so much experience on the simulator

and mess up so many times because they learn all the things sully did which you mentioned mentioned. We've talked about Captain Sully before on the show in terms of learnings. And it's such an interesting thing of like what it takes to make those choices on the fly. And it was just all the years of experience, all the years of having these different scenarios. And even when trying to do it again, they couldn't. There was a lot of speculation on the flight and how the choices made and all that good stuff. And all the most skilled pilots took the same simulation of the same crash and making different choices. And many of them crashed. Yeah, they never crashed in real life, though, right?

Right, exactly. That's the point I'm getting to is that it's in a simulation. And so that's OK. No one was hurt, but there was skills. You still upskilled. And we didn't talk about Willcoins. Maybe potentially you're also getting some true reward. I don't know what you're planning to do with the Willcoin aspect

or Jerry was saying is this Web 2 or Web 3? Is it truly on a ledger? What is it? Or Web 5. Web 5. Web 5 is the new Web. Web 5, yeah. The new Web.

Web 9. It's three squared. That's how you raise money is you just raise the number. Yeah, Web5. Web5 is the new web. Web5, yeah. The new web. Web9. It's three squared. That's how you raise money is you just raise the number. Yeah, exactly. Or you have to add.0 to make it sound cool. So it's Web5.0.

Otherwise, it's just 5. There you go. Who cares about 5, right? Yeah, you're in a simulator. No one gets hurt. And there could be some reward. Yeah, so, you know, Wilcoins are going to have their fair share of ways to redeem with really cool stuff.

Even today, you can actually use them to buy hints. So, you know, when you tell Nest that you need some help, you might have to pay for that with Wilcoins. And that's the difference between Wilcoins and experience points because the experience points stay forever. It's kind of like, you know, some airlines have the miles stay forever guarantee, but the well coins are the stuff that comes and goes,

right? You earn them, you use them. The point is not to have like, we're not a social game that's supposed to, you know, take all your money to buy fancy avatars or stuff like that. We're not going to have you pay just to advance in the game.

Our revenue stream is going to come from completely different... You could pay for a certain quest, though. Potentially, but... for a certain quest though um potentially but like you gotta have enough experience points and have enough coin to go on a certain quest because that would motivate me to one be immersed longer if i'm really enjoying myself i'd want to i'd want to upskill to get there and i'd want to make sure i have a bank account that can support my quest habit so to speak so definitely you know gaining enough experience points to gain access to a quest So definitely, you know, gaining enough experience points to gain access to a quest

is definitely something that's going to be in the platform. Having enough will coin is an interesting question. And like I said, this is not the revenue stream we're planning on. We would much rather have teams

that are genuinely interested in becoming better as our customers. Yeah. And, you know, we think it's a great value proposition to those teams but will coins are going to be this great bonus for you to do really cool stuff in the game and maybe get some will go swag i was gonna say you gotta bring some of that into meat space and get some t-shirts and stickers and stuff. Being able to trade that stuff in for something that's real, that's just fun. Yeah.

And I mean, fun is at the core of what you guys are trying to do, right? Exactly. Truth, yeah. In the future, we might have specific pieces of swag for specific achievements in the game. That'd be cool. That'd be cool. You could be one of only five people in the world

to actually have that piece of swag. Now I want in. That'd be cool. Limited edition. Ooh, when you write your first changelog, then you get a changelog t-shirt. Nice.

But only the first five people that write a changelog. I was thinking back to that colleague of yours who told you were stupid for this idea and the size of the impact, right? He's my co-founder now. Co-founder. Okay, there you go.

That completes the story. So we obviously, when we put our best work out there, impacting a few can be deflating in terms of your motivation. And so the larger the impact positively, isn't that positive for the world? And I got to imagine that at some point you might be able to interface with, let's say, not so much bootcamps themselves, but those who truly care about educating

the future generation of the world's hackers, of the world's engineers. I got good friends in the space, Launch School and Chris and others that do this stuff. They care deeply. Is there a world where these two intersect? Or are you competitors with them? Are you parallels to them? How will those who are educating, can they play?

Is this a world they can be involved in? Is there room for them? So I think the two things are very complementary. So if you want to upskill, if you want to practice what you do, you need to know the basics, right, to be able to start doing that. You can't start going on Wilco unless you actually know the programming language. Now, you don't need to be an expert in it or anything like that.

You just need the basic knowledge of it. But if you don't have that, you're not going to be making the most out of Wilco. And I really think that you need this combination of knowledge and wisdom to be able to create real proficiency, right? And what we try to do is give you that wisdom, whereas what the other schools are trying to do is give you that knowledge. And it's not that one of them is more important than the other. You really need both. And being complimentary goes both ways, right? I think that a lot of these, let's say, bootcamps could really benefit from sending their students

to run quests on Wilco, play quests on Wilco once a week or something like that. But I also think that Wilco players could benefit from a class after having played a quest and realizing that maybe a specific skill is something they need to work a bit more on, or maybe they're actually missing the very basics of that skill and they could go take a class somewhere. So to me, these two elements need to live together for our industry to really get

better. As you're describing that, I was thinking about one of my most favorite games ever in the world and it's the original castlevania from nes way way back in the day and like any any gamer or anybody who really enjoys a game you don't just play it once you don't just go and you know quest all the way to dracula if you can ever get there or medusa or these other folks that are so they're you know bosses that are along the way like Like, I've played those levels numerous times. Sad to even say I've also watched others who are really good at playing that game get their

best time ever on YouTube or on Twitch or wherever and watch the world record holder, for example. And so I'm wondering if in the future you'll have people, you know, who go back and play a level again to get even more sharp. Like practice makes perfect, right? Doing makes perfect, so to speak. So I wonder if this is a thing where you might enjoy what you do so much. You go on quest once a week, but it's the same quest every single week.

You just get better and better and better. Yeah, definitely. It's like athletes continue to do the basic drills all the time, right? The fundamentals matter. And for me, it manifests itself in two ways. First of all, you're absolutely right. And there are games like SimCity, for example, that I could play forever, right? And the more open a game is, the more it makes sense for you to play it again and again,

right? Because you can do things differently. And you can try various strategies to winning it. And then, you know, in SimCity, if you manage to get everything in those domes eventually or whatever they're called, then, you know, jackpot. But there are different strategies to go about it. So you could play the same quest again and again

and again and again and try to do different things. But in the future, we also think we will have multiplayer quests. And then at some point, you might play that quest again, but as a different character within it. So maybe the first time you played it, you were the engineer responsible for a specific element of it. But then the second time you played it, you were actually taking a very different part and doing something completely different. Maybe the first time around you were doing the back end and the second time you were doing the UI for it.

Right, like roles. Yeah. Yeah. That's interesting. I was thinking of it in a similar vein to you, which is like the anti-player. So you might be doing a quest, and correct me for how accurate this may or may not anti-player. So you might be doing a quest and,

you know, correct me for how accurate this may or may not be in the future. You may be doing the quest, but I'm the person who's the opposite role, which I take production down. And your job is to keep it up. You know what I mean? So the quest is for you really, but I'm the anti-player, right? I'm QA essentially. I'm taking you down. Right. Yeah. Yeah. Adversarial mode. Yeah. Which kind of gives a different facet to it. I'm the passive aggressive coworker. Really, really interesting. I mean, there's a lot of possibilities, probably so many that we can just keep talking through

all the different permutations. But one thing you said in regards to Will Coyne was that's not our business model. And you kind of alluded to certain things. What exactly is the business model you're building? What you got funding? You were on TechCrunch. You were covered on that. So this is the business model you're building on? You got funding, you were on TechCrunch, you were covered on that. So this is a funded startup. You've got runway, you're making a dent or you're attempting to. What is the business model and how will you succeed?

So you said making a dent, which to us is more important than the business model. Eventually, it's very cliche, especially coming in from WeWork, but we are a mission driven company. And our mission is to empower every developer, regardless of their background or skill level to unlock their full potential. And if we do that, I think we're also going to do really well from a business perspective. Because if you provide real value, people are going to want to pay for it, right? But teams do have learning and development budgets already, and they, in many cases, don't know how to use them. So you could be sending developers to conferences. You could be buying online courses for them. But everything is very ad hoc. Everything is dependent on someone finding a good use of that budget. Whereas what we're saying is, hey, you know, just get a Wilco subscription for your team members.

And they'll be able to practice all the time, whenever they want, at their own pace. And the platform is going to have enough content that they can choose what they want to become better at. And, you know, you'll actually know what they become better at as well. I guess you could even say like a manager or somebody can motivate them by saying, hey, take that quest again this week. I would love to see how you do that quest in this role with this concern. Is there going to be that kind of lever involved or is it sort of like very handed off to that person to make their own choice to do the quest whenever they want or the quests and it's very, you know,

a la carte to them or is it sort of guided to some degree? Like what do you have planned for teams? So it's a mix of both. But when we say guided, to me, the most important aspect of it is, you know, I'm a manager and I want to know how to help my team get better at their job. So this isn't about, you know, grading or anything like that. Not that I think that software engineers could be graded. And if I did know how to grade them objectively, that would probably be a company of its own. But I do want to help managers be better at their job as well. And if I'm having a one on one with you, Adam, and I can tell you, you know what, I think you're, you're doing really well on databases. But everything front end related, it seems like you're stuck. So why don't we figure out some ways to help you? Or maybe we pair you with Jared, who's doing really well on front-end,

but actually needs some help on databases. So why don't the two of you pair for a while and kind of try to rub off each other and help each other out? So that's another tool in my arsenal as a manager to make my team better as well. But it's not about me trying to decide the path for them. Right. I almost see it too, like when's the last time you simulated a database failure? Or when's the last time you simulated production being down because of an unknown error that you have to investigate?

It's crazy that we don't exercise that all the time, right? Well, that's where I really see the sweet spot for this because if you leave it up to the individual, sure, I want to upskill myself, but I'm also going to be lazy. Any developer is going to be lazy. And so that's just a natural artifact of just being human, right? cares about me and the direction I'm going. And I'm in a company who truly cares about me. And someone says, when's the last time you simulated this? Or it just maybe, you know, almost mandatory even like simulate failure of some sort that matters to you and pick your own version of failure and correct it. That's going to make me better at my job. It's going to make sure that my company performs well.

It's going to make sure my product gets bought by people. You know, it's going to make sure that my bonus is there when it's time to collect it on the quarter or on the year. My RSUs actually get to be cashed in. These are things you care about when you're in a technology company. And if you can simulate those things and be better at those, I feel like it's sort of necessary if this is an existence in the world. If this thing exists, then it should be something people can do. Yeah, I absolutely agree.

And going back to the beginning of what you just said, I find it crazy that we don't practice on a regular basis. Can you think of an NBA player who doesn't practice free throws every day? It's nuts, right? Check out Kobe. All the documents on Kobe and Shaquille O'Neal. Yeah, Shaquille's a different... But yeah but yeah i mean you got to put the hours in you got to put the practice in you know well going back to your mission real quick going back to your mission i just want to say that as somebody who's been in the field for a long time i appreciate the part

where it's like for every person, every developer, no matter where you are in your career, because a lot of these tools and educational resources, as somebody who's been in the business for a long time, I'm never their audience. And the fact that as you sign up for Wilco and the onboarding experience is like, where are you in your career and what are you interested in upskilling? The fact that I have like an answer there and don't feel like i don't belong here is awesome like oh actually just because i've been doing this for a long time doesn't mean i don't need to simulate some stuff or learn something new and i think it's very welcoming to you know expert level or long long career people you know i think that's really awesome. I don't want to call myself an expert, but like I've been, I've been, I've been around the block

a few times. I don't need the beginner level content, but I still need and desire to get better at certain aspects. Right. And so I think it's cool that you all are providing resources for us in addition to people who are just getting started. Yeah, it started, like I said, back when I first thought about it, it was just, how do I make these very junior developers better and how do I help them gain experience? But then we realized that the problem is even bigger for the more seasoned developers because for them, it's really hard to find new types of experiences. Well, Lon, thank you so much for sharing this story with us and sharing, I guess, a glimpse into even your experience at WeWork, too. I mean, this is a first for us to kind of, it's an elusive type of company and, you know, all the things that happen there. It's a TV show, a lot of interesting things.

But getting a glimpse behind the scenes of just a little bit was interesting. All the technology, the invisible technology that made it work, and then also how that translated into just how you're working now and you care about every developer no matter where they're at. I think that's such a cool story. So, appreciate you sharing, appreciate

Is my version better than Anne Hathaway's and Jared Leto's? Or do you don't think it's going to get picked up? I'm three episodes in, so I'm not a full We Crashed watcher yet. I'm on my way. But Jared, I think he has completed the series. Final question. Who would play you in the Wilco straight-to-fiction Apple TV Plus dramatized version?

I don't know. Maybe I have aspirations as an actor and i could play myself um there we go kiana reeves nice um that's actually a pretty good one yeah and and he can also throw in some kung fu and that would be really amazing and i you know it would turn me into this actual ninja um that's right no but i actually i was told once that i'm i look very similar to andrew garfield so that was when i had shorter hair so maybe maybe he would play me i don't know i've only seen the longer haired uh pixelated version of you that i see here on recording but i was actually just starting to think uh a younger shia labeouf like not Shia LaBeouf now but like maybe a few years back how old is he

you're probably older than he is but he's changed his look up recently well he's got he's got more scruff for sure he's gotten scruffier yeah I don't know throwing it out there I think kind of reason be sweet I would almost say Adam Driver even especially here on camera today right now adam driver yeah adam driver oh why interesting why are you typecasting because i'm jewish no just kidding is he jewish too no not at all i'm just kidding no i didn't know i didn't know adam driver was jewish i mean learn something every day but it looks similar yeah i would love to have kylo ren play me come on that's that's awesome and you know we could have like a lightsaber that is actually a good pick i don't know though keanu reeves a little bit better so maybe keanu reeves and adam driver can both play

you know we're three co-founders both of them can play oh and we can have like a Neo versus Kylo Ren scene at some point. Because what... Just for fun. What tech company doesn't have that going for it, right? And then randomly Shia LaBeouf comes on and just starts yelling stuff. You can do it. You can do this. Just do it. Just do it.

Actually, I prefer Rob Schneider's version of You Can Do It. I'm not familiar. I'm going to have to go look at that. Oh, You Can Do It from Waterboy. You can do it! Exactly. Now I'm with you. I thought he did a, he made fun of Shia LaBeouf. A meme as well? So I think there was like a period in which every Adam Sandler

movie had Rob Schneider come in and say, you can do it at some point. And that's like his only line in the whole movie. Yeah. Pretty much. Yeah. You can do it the website is a dot gg right or is it no it's try will go dot com which is dot com i don't know why i read it dot com it's so weird it's t-r-y no it's https colon slash slash. Trywillco.com. You've heard it here first. Dot com. Check it out.

Number one on product week on product hunt. Never stop developing a fantastic tagline and pun. Yeah. And guess what? By the way, if you go to trywillco.com slash changelog, you'll actually get access that cuts the wait list and you'll be able to get right in at least the first few. Oh, nice. I see you're trying it now it's not up yet i'm assuming there's going to be some time until this thing actually airs no this has been live the whole time we didn't tell you i do enjoy the 404 page hopefully our listeners will not see that it is cool though no they won't it'll be up by the time they get to it. Excellent. So there you go. Tribalcode.com

or.com, whichever you prefer slash changelog to, I guess, jump the wait list. Is that right? Jump the line? Yeah. Fantastic. Fantastic. And while you're there, upskill. Simulate. Practice. Never stop developing. Get better.

Be a better teammate. All the things. An, thank you so much for your time today and sharing all you've done. Really appreciate it. It's been awesome. Thank you. Thank you so much.

I had a great time. Thank you. Okay, that's it. This show's done. Thank you for tuning in. What do you think about WeWork? What do you think about WeCrashed? Have you watched the show yet? Let us know in the comments. What do you think about WeWork? What do you think about WeCrashed? Have you watched the show yet? Let us know in the comments.

What do you think about Willcode? Do you think that's the next big thing possibly for helping your team upskill? Also, let us know in the comments. Links are in the show notes. Big thanks once again to our friends and partners at Fastly. Our pods are fast to download globally because Fastly is fast

globally. Check them out at Fastly.com. And also, Breakmaster Cylinder, those beats are banging. We love them. Hope you love them too. And of course, last but not least, thank you to you for listening to the show all the way to the very end. I got much love to everyone around the world who listens to this show. If you haven't subscribed yet, head to changelog.fm for all the ways. That's it. Thanks for tuning in in we'll see you next week so Thank you. Game on.