Hello and welcome to this episode of the pod presents primarily context based. This podcast is a collaboration between CTO craft and skill, a whale but it was inspired by the Q and a site stack overflow where questions have a single right answer and questions can actually be closed and archived when they're considered primarily opinion based. Well, we think that the most interesting questions don't have a single right answer and their answers are primarily context based.
And in this podcast we're gonna take one of those questions, Talk about a range of answers and the context that makes each of those answers appropriate. My name is Howell Carver. I'm the ceo of skill, a whale, really deep coaching for tech teams, which is individually personalized, hands on sessions with a live expert remotely in one hour chunks.
I've been a C T O for the last 10 years, I've run CTO dinners for the last three years and I've been a C T O coach as well and what I've seen is that the same questions come up again and again, but with different answers every time and that's because context is critical. Today we're gonna talk about the question how do you approach restructuring?
And I'm delighted to be joined by josh Goldberg, who is the author of learning typescript published by O'Reilly and he's also a full time open source maintainer of projects in the typescript ecosystem josh. It's great to have you here. It's great to be here. Thanks for having me, how's it going? It's going well thank you well you've heard me whine about my cold, but other than my cold, it's going very well.
I'm looking forward to talking about this because I think this is a perpetual question, right, that software engineering is is a sort of singular, unique, unusual world where stuff that other people have done. The idea of legacy is kind of a bad thing. If people talk about legacy code, it's not done, it's not meant in a kind way, it's meant in a in a problem that needs to be fixed way, which is why we need to do restructuring. Absolutely. You actually introduced me to a terminology split?
I wasn't familiar with until recently. The difference between a re factor and restructure, but I think it's fascinating that we have so many different terms for legacy or untested or etcetera code and the actions we might take on them because as you said, as an industry, we have to do it just so gosh, darn much. Yeah. Yeah, that's definitely true.
My eyes were opened by the martin Fowler Book on re factoring It's sort of like a series of algorithms for programmers to follow to perform a variety of re factoring steps and that kind of five point algorithms for when you want to extract a function or reduce repetition between two existing functions and things like that. But we're going to talk about restructuring today. The idea of I guess maybe I should ask you to define it, but for me, restructuring sounds like large?
Well, structural change more than just at the level of individual lines of code, it's changing architecture, is that about right? That's how I mentally interpreted that. A re factor is something you can do kind of in one sitting where it's, it's one little thing you're changing like the internals of one function or one class or something like that, whereas a restructure is the structure that you're completely shifting paradigms or using a different architecture or something like that.
I think we may be on the same page. Yeah, I think that's right. I think exactly that restructure is is something that you might take a year to do potentially I think a small restructure would be done in order of days or a week where a re factor is a kind of a momentary, you just kind of do it sort of single commit level of change. I guess we should start by talking about motivation for restructuring. Like how do you know when it's time to restructure?
You're looking at the code base and you think you're looking at that architecture diagram and you think we need to change things. It's a great question. I think a lot of people get really excited about re factors and or restructures because they like the idea of something new, something shiny or they have some pain that they're trying to address. This file is 3000 lines long and every time I touch it, it takes me two days to test the changes.
But you're always gonna have to justify what you do or at least hopefully you're gonna have to justify what you do to someone, whether it's a pull request reviewer or a C. T. O or some other group in the, in the company, the group, the organization you're working for. So when I think about taking on restructures or re architectures, what is the pain and what is the game? What am I gonna have to expend in order to change this code?
The way I want, how many hours potential bugs, number of people impacted or who will have to participate versus what is the actual benefit here? Will I be, I don't know x percent faster? Well I produce Y% 50 potential legacy things you could touch and only one or three of those is really something you have time for. So that's, that's kind of the general equation. I tried to start with. Got it.
And I suppose when, when the restructuring isn't justified, you instead look for the incremental improvements to solve the problem instead. I guess one of my big fears about restructuring or rebuilding any piece of code is always that it's done in response to some perceived problems with the current code, but because we don't have the new code, we're not able to perceive and anticipate all of the problems that that will likely come with.
The new shiny nous often feels like exciting because it doesn't have the problems of the old code, but it may well have new problems that we haven't foreseen. Is there a way of quantifying those or anticipating those or do you think you just have to kind of cross your fingers and jump in?
I don't know that there is a way I wish I would have one for you here, but yeah, I would love to do a thought experiment or a practical experiment where I would love to take a team that has some painful legacy thing that they'd like to restructure and then get them to restructure into the exact same architecture that they already have to see. Is it that the structure is bad or is that as you said, that they're just griping about the craft they've built for themselves.
There's a great quote, I forget where it comes from before the change we were in life. I think part of being an experienced senior plus software engineer is to be able to guess sort of what levels of benefit you're getting from proposed restructuring and that's not always doable, you you you can't practically know how everything is going to play out until you've done it. So the answer is no. And that quote was we forged the chains we wear in life, is that right? Yes, I'm looking it up.
It's it's stuck in my head since high school. I like it well, while while you're looking up, the thing that we can say in favor of making restructuring changes, rebuilding things is that we now know more than we did when we made the old code. Unless we have a kind of completely new team looking at it, who doesn't have that old context and doesn't doesn't know about how things used to be.
We should always know more today than we did yesterday and therefore we hope that our decisions today about the way we build this thing will be better suited to the problem we're solving because we're that much wiser about the problem. Absolutely, I did. It's Charles dickens, I should have known. Is it interesting? So then how do you make that decision right.
If you're in that context where you're like, we have this code that we already have with all these problems, we have these perceived benefits, We can see all the new things, we can see all the positives, you talked about kind of justifying that with outcomes. What does that process look like? How do you decide between starting again?
How do you decide between restructuring what you already have and how do you decide between maybe more incremental improvements and sort of living with what you already have. Unfortunately we don't always have the opportunity to stop the world for four months and rebuild everything from scratch. Most of the time we have stakeholders, users, people who need us to continue working on the product or project.
So most of the time, what we can start with is small steps, which I think are oftentimes better because you need to understand how to do the thing before you go full on it, unless you've all done this before you probably need to ramp up on whatever new structure or technology, library framework etcetera you're moving to, So practically working your way towards something bigger by doing smaller steps ahead of time,
maybe just doing the start of the restructure in a few files or if it's a new language only converting a few areas of your code base to that language first, that will give you the ability to practice, to learn the new methodology, technique, whatever it is, while still getting a few small results in that way, you're not stopping the world just to learn this new thing. Unfortunately, sometimes you do have to go completely in on something.
Maybe your project development is so slow that you couldn't possibly continue to work in the current paradigm, in which case maybe you do have to stop the world, but practically speaking, I have seen that happen so rarely where the level of pain ramps up over time and people start complaining and taking action sooner rather than later. So it's it's not very common I think to see that a team just stops what they're doing and then four months, 10 months later has a new project to work with.
Mm It reminds me of reading a post by get hubs engineering team about how they migrated from it was rails to to rails three or rails 32 rails for how they made a major version upgrade in rails and I think they tried maintaining a separate branch, forked off their main branch which had the upgrade on and so they would keep kind of merging in code into that branch and it was it was endless, it was a kind of like a sister fusion task, right?
You know the story of Sisyphus, like everyday Curse to roll the rock up the hill and then it would roll straight back down again and that was his kind of task for eternity. And I think that's what it was like to be in the git hub Engineering team responsible for the upgrade. And so what they ended up doing was they made their main branch had to work in both at once.
And so they started out just taking the main branch in adding some code that would have it also build in rails three and also run tests in tests in rails three, I think it was rail three that they were upgrading to and over time as they increased test coverage for those cases that were breaking, they were able to identify very specific bits of the code base that we're going to break,
have some bits that work for both rails two and rails three and some bits they would just put a like if rail stock version greater than two or whatever or equal to two, then do this, otherwise do this and so they were able to maintain in the one code base, both parallel versions of the code and I suppose that also meant they were able to very readily deploy their rail three version when they were confident in it and run both side by side for a time as well,
which isn't quite the same as a restructuring, I think it's not an identical case because they were doing essentially a light or framework upgrade but that might be a way for people to address a very large restructuring is to have the new restructured version live in the code base with the older version and slowly migrate across to it with the code, Both bits of code living side by side and then avoid stopping the world.
I quite like that there's a apologies for continuously bringing up new phrases, but one that's been in my head a lot lately is one must imagine Sisyphus happy that the original phrases on the absurdity of life but to me, I like the idea that there's always something that you have to do, there's, there's always something you're always going to be pushing that rock up the hill and whether it's, you know, maintaining a large feature branch or moving from rails, X two rails, X plus one,
there's always some large structure change happening. So it's a good idea to get effective at them to understand how you can do them, how you can say incrementally convert over, do one file at a time or have them both live in parallel and I really like the strategy that can help took. Um, I suppose though one of the things about our work should be that there is an outcome that is more meaningful to us than the rock is temporarily at the top of the hill.
Right, yes, we're going to have like feature branches that become out of date from the point where they were forks and we have to keep merging changes in or re basing or whatever, but ultimately that feature branch should do something meaningful for our users and so I guess that comes back to in our restructuring discussion, what should be benefits of restructuring and how do we then communicate those to stakeholders and people who care about our work?
How do we say that this thing is worth doing and then later on proved that it was worth doing? Absolutely. Well, we should ask ourselves that question. Why do we want this thing in the first place, it's almost always something new and shiny that people are asking for but why in the case of rails to, to rails 31 can imagine security updates, more features coming out the threat of it not being maintained framework going forward.
Oftentimes the idea of switching to something is instigated because the old thing is going to get out of date and the new thing is going to be the maintained version. You don't want to be on an out of date framework such as rails. So sometimes there are things that you just have to do. You just have to move to the newest version of your core foundation or framework because in five years it will be much difficult and the old version will be out of date.
So, you know, hands down that that's always a nice motivation you have to do it. But for things you don't have to do, there's some benefit from doing it in theory that you should be able to articulate most of the time. The benefit that I have seen developers want is for themselves for developer experience, which oftentimes comes down to a better development flow that it's a easier to modify. There are fewer files you have to touch.
It's easier to test or it's a better user flow that it's a simpler architecture that has fewer likely bugs or looks better for users in the visual field, whatever those benefits are, it's a good idea to quantify those benefits because not everyone you're going to talk to about them is going to be technical and excited about. Oh, it's the new version. It's got a better structure, the clean code.
And even for people who do understand the technical side, that isn't necessarily their primary motivation. If your manager and you're talking to a c t O, but how your team wants to do a re factor, the CTO can be very technical and still bounded by the constraints of I need to justify this. You want to spend six months doing something. What are the actual benefits?
So as much as you can benefit, quantify the change and development cycle process, change in how it affects users, whether it's a direct feature or reduction of future bugs or whatever it is. So that you can then compare against other stakeholder initiatives like bug fixing, feature, additions, compliance and so on.
Oftentimes honestly it comes up short that, you know, a lot of people ask for re factors, but we can't be constantly re factoring our code, you have to still be making progress at the same time. So there's no one size fits all answer here, but being able to quantify your benefits and compare them to the other things that are going on at the same time is a very good straight right? And I in fact, I think a lot of the things you mentioned become high level metrics.
You talked about developer flow and developer experience, those things ought to become like developer experience ought to be visible in your retention. If your team is large enough, you should be able to see that better developer experience means people stick around more because they like the work, they like the experience of doing work and better developer flow and experience together should mean that you start seeing high velocity, fewer bugs, fewer turnaround cycles on pull requests.
In fact, we, one of the first teams that we worked with that skill a well, I wanted to make a transition from one front end framework to another. I'm not going to say which ones for fear of getting emails saying no, the true way is backbone dot Js every everyone else's is a lie.
But yeah, they made that transition across and they were, they were a company that was all about measuring developer statistics, basically develop a team productivity and after we'd help them kind of learn new skills, their velocity was four times higher than it had been on the previous framework and that is a very kind of tangible stat to have as an outcome that you predict and then can demonstrate to stakeholders that we invested in this restructuring,
We invested in these new skills and now as a result we are able to do stuff faster. That's a compelling story to internal stakeholders at least. Oh, for sure, that's very compelling. Four times is fantastic, congratulations to the team, I'm so glad switching to react from regular, worked out for you.
Another terminology difference that I've been floating around with recently is the difference between correct and compelling that you can justify a re factor or restructure in terms of stuff that is correct but not particularly compelling or you can try to understand what motivates the people around you and speak to those needs.
The big thing that I've I've tackled most frequently is converting from javascript to typescript, moving from one language to another and I can describe to you as a theoretical stakeholder, Orban or some such. That typescript is a typed super set of javascript which allows you to declare the types in your code and that is all correct.
That's very accurate and precise, but it's not a particularly convincing argument for typescript or I can understand what drives you and the team, let's say that it's a team that frequently experiences bugs or has problems with developer to developer communications and I could use that in my description, I could be similarly accurate, slightly less precise and say, well, typescript is a super set of javascript variant that you can adopt incrementally,
that allows you to declare little documentation, snippets in your code and then it will validate to you if you change something that violates those in a way that would likely cause a bug.
Meanwhile, it also enforces that you add those things as a form of documentation and that speaks much more to the needs of the team to the things that you're actually trying to invest in at that moment and is I think a much more compelling argument to this theoretical team than just here's the broad definition of typescript to do with that, what you will write, exactly, you're, you're focusing on the benefits,
you're saying there is a class of bugs that we simply won't have anymore and we're going to make it easier for developers to communicate, which, you know, as we all know, is a big problem in our company X and therefore we're going to expect to see better team cohesion, that productivity between teams as a result of this. Exactly.
So we we've talked about how you can, how you can implement it and like the idea of kind of doing things side by side, is there a way of identifying where you begin doing that? Is there a way of starting a kind of surefire way of starting a restructuring project? I don't think there's one sure fire away because there are so many different things you could change so many different areas, you could change in but I think they're a good set of strategies that I try to go with.
I try to minimize risk first and foremost, you never want a suggest something is great and then try and then break everything that devalues what you said and what you are trying to do if say you're tackling every factor that can be applied to any number of pages, try the pages that people visit the least or the most unimportant pages per perhaps your about page rather than the product pricing page.
For example, if you can do something one file at a time, if say it's a language conversion, like a J S, two T s javascript to typescript one, then try doing that one file at a time rather than all files at once whole hog as they say.
Um if you're doing something that is meant to increase test coverage, perhaps focus on the testing for it, one of the strategies mentioned in the great martin, Fowler book, working effectively with legacy code is to wrap with tests which give you more confidence and then only once something is tested and you're confident that it is well understood. Do you swap out the old implementation for the new?
So there are few strategy, I think that let you incrementally change over, but again, it's, it's really such a wild and wacky field, there's so many different things we could be doing that there's no one strategy that fits everything I think.
Yeah, and I think the key thing there is finding that that small bit that you can start with that you can commit, merge and ship that that becomes kind of part of live code as as soon as possible because what you, what you really need to avoid in restructuring, I think is having your kind of parallel structure continue away from the main code.
You really want to get into a habit of the restructuring happening in the live code, not being an all sort of an alternative code base, it needs to be in there and so I think the example you're talking about all fit with that nicely as a thing that you can do, you know, you create your branch, make your change, get it most in as soon as possible and then the next bit of what you do kind of furthers that restructuring. Absolutely.
I'll tell you one of my great big career disappointment stories with all anonymized names of course we were working on an app that allows people to view a page after creating the page and we had this fantastic new architecture, we were moving to the shiny new front and thing performance was going to be way better developer productivity, way better all these fantastic benefits but we weren't really able to do it incrementally, we,
we made a whole new version of half the application and then a eventually after many, many months ship that new version of half the application to some users who we knew would only visit that half that is somewhat incremental, you could argue that it's incremental because we're not completely rewriting everything and then switching over but it took many months to ship and then eventually some people saw it and as you can guess maybe where this is going.
We unfortunately we're not able to continue with the re factor were moved to a different piece of software and it has just stagnated since I don't think people actually see the new shiny version we're also excited to work on. And since then I've always tried to keep that in the back of my mind of if we were to all be shunted into somewhere completely different if the entire team were to be hit by a bus, would this re factor or restructure live on?
And unfortunately in that case the answer was no, we weren't well prepared to make sure that our code had legs long term. So I'm still a little, a little beat up on the inside about that one. But I think it's a very good example of my unhealthy unhappy relationship with the concept of a long running feature branch or a V to be right, it's just hard to keep going.
I worked once with an external agency that a similar situation ish in that we had apps written in native languages for IOS and android and we wanted to rebuild everything in react native and they were pricing up the project based on a long standalone bill to recreate all of the features that would eventually ship at the end.
And it was only because I really sort of forced the issue and put my foot down and said like I really feel certain there must be a way of us getting some react native components getting them built in like compiled into native versions that we can then link in with the existing native apps we have that we should be able to do this more gradually and have both both versions live at the same time And it was only after kind of pushing quite hard but eventually I got the response back that this was actually surprisingly easy and they thought it was impossible but they sort of looked into it and it was not only not impossible but not as much work as they thought but it would take longer and had like 5% to the cost of the project And that felt like an easy 5% to sign off on because of course at some point there was a chance that things get shelved and then you know that we would have this kind of redundant version of the code that we couldn't use but we wouldn't want to add any features to the old version for fear of them getting even further apart.
And so I think I think if you start out with that mentality of like we must ship all of our new changes as early as possible at least in my experience it's always been possible to do that and then you avoid that eventuality where like people's hard work ends up not shipping at all or projects getting stored 90% complete. Yeah, well congratulations, that's that's great that you're able to advocate for the incremental, you know, adoption strategy there.
I think that now that you bring up cost, that's another good thing to think of where we have, not just the raw developer salary that you could average across on a team to determine the cost of a project, but you also have the opportunity cost, How much more money would your organization be making if the team continued to ship product instead of this re factor or restructure? So that is another factor to think of. If it's gonna take you, let's say $1 million $500,000 of potential sales.
That's $1.5 million being put towards this restructure. What benefits will your restructure give you that are worth $1.5 million. Oftentimes you can quantify those, you know, in six years will be experts and more productive and we'll have made 10 billion. But it can be very difficult and kind of hand waving to work with numbers at that scale, especially given how vague and hand waving engineering developing time already is.
Even when you are able to combine the restructured version in and get your restructured code live as soon as possible.
There's a danger that the beginning of the project is very exciting and the end goal is very exciting, there's a bit in the middle where all of the hard work still remains right early on, we do lots of small bits, everyone wants the end goal where the old bad way that we're getting rid of no longer exists anywhere and we get one of those nice pull requests, it's like, you know, plus plus five lines minus 200,000 lines that every, everyone loves being the author on those,
how do you keep that momentum going and how do you keep it feeling exciting and convince people to, to see the restructuring over the line to get it to 100%. That's such a hard challenge, I'll give you another story, this one can actually be anonymized.
I was working at Code academy on our core learning platform, which was going through a rewrite, this is an education technology platform that people used to learn to code for free or freemium and people who are learning to code are very sensitive to the computer if something breaks and it's our fault, they may still consider it their fault.
So we're very averse to any sort of bugs, weird, bad user flow shenanigans, anything that might detract from the learning experience, the pedagogy of it all and that made us very sensitive to swapping out the core learning platform and even though we had written a mostly working version of it, that was smoother less tech, that was easier to add new features on, I added a little auto format button with sparkles and it was a wonderful thing, it was just still such a challenging, difficult,
scary thing to swap out most of the existing pieces, even though there were new pieces that have been added in that used the new architecture, therefore meaning we had to, architecture is running in production. What a lovely situation. And yet that, that is something we struggled with. We eventually did ship the new version. Um, but how do you motivate for the long term, especially when there is a legitimate fear involved, things that could go wrong.
I'd say being able to quantify the cost is a good start. You know, we were spending x percent more 1.5 times the amount of dev time maintaining these two platforms. It was longer builds longer listed dependencies, longer list of bugs getting caused by the average change. We didn't do a very good job of internal dev advocacy. So a lot of people didn't know where the restructure was going or they weren't sure why we were doing it.
So, having effective documentation and advocacy internally, you know, being excited in the team meetings. Uh, one little rule I like to have is, if you have a project, it needs to be ongoing. You can't just pause something for six months and then eventually get back to it. People will forget folks leave the company, leave the team.
So always have at least one person working on some small bugs which both make sure that you have progress going and gives you the opportunity to get ecstatic and excited about it in the meetings and just demonstrate that you're doing something fun, get people interested and then finally, eventually, I think it was just costly to keep it going.
So we put our foot down and we said, okay, we know we have other things we have to work on, but this has been going on for long enough, literally years at this point we need to just buckle down and finish it. That can be a very good forcing function. We need to finish this. Here's three months, just go do To get you to understand what are the actual tasks remaining.
Oftentimes you just need to ship to 10% of users or some similar incremental strategy just to, to get that final list out there, which is a little upsetting to say, I don't like using users as a bug farm, I don't like subjecting them to that. But at the end of the day, if you have something new that's big and scary, you have to test it in some way. So whatever way you can do to get internal testing and a real user testing is, it's going to be beneficial there. Yeah, definitely.
I mean, you are going to cause new bugs, that's the rule of all code, I think as soon as you hit commit, you have almost certainly caused a bug and that's something to recognize and embrace and when you're doing a restructuring, you are probably replacing one set of bugs of one set of difficulties with the code at least with another and therefore looking for those and finding them and healing them as quickly as possible should be part of your strategy. That makes a lot of sense to me.
Yeah. If you look at the amount of bugs per line of code in any major piece of software, there have been studies shown on this.
It varies with language, which is something that people who work in modern low level languages like Go and Rust are very excited about because they're way better than C but even in the really good languages, it's I forget, let's say whatever one bug per 10 lines of code, One bug for 100 lines of code, If you're touching 200,000 lines of code, do the math, that's a lot of bugs. Even if your architecture is being restructured to something way more resilient and way harder to cause bugs in.
Even if it's a 10 x better architecture, 200,000 divided by 10 divided by that number is still gonna be dozens or hundreds of bugs. It's just a fact of life, that's, that's the industry, we work in nothing. You can do about it, You can just make it better, you can't get rid of it. Yeah, yeah, yeah, definitely. Some of what we've been talking about. I think it seems a similar language or a similar framework that we are rebuilding in.
Does any of your, your thinking change if you're moving to a different language altogether. I think these strategies for me are similar, but the weights of different factors are much different. I don't like moving a team to something new that they're not familiar with because it takes a long time time to gain familiarity with anything. If you're working in say a high level code based java, C sharp, javascript, something like that and you decide that, you know, a performance is critical.
We slow users hate it. We're going to switch to rust, something low level like that. It might be the technically objectively best thing outside the context of your team, but you're gonna have to retrain everyone. How many people these days know both java and rust. Let's say it's a large investment. So something that would take a team already familiar with both areas say a month.
You could easily take your 6 to 12 months just in terms of learning it, doing a new version, realizing this is your first major project in that new area and then you have to scrap it all and do it again. So I think you don't make project decisions in a vacuum. There's no such thing as a Greenfield project. No new shiny thing that is completely untouched by civilization.
There's just stuff your team is familiar with and new areas you're going to have to learn, which can sometimes be a very small jump and sometimes to be a very large, costly jump. I don't think that it's very easy to make that determination and it's exponentially harder if you also have to factor in learning a new language or framework, I think that's definitely true. Right?
A lot of approaches to learning involves giving you access to resources and then have you actually put it into practice on the job for the first time, which just really sets people up to fail.
It's one of the things people have turned to scale the well before actually for in the past when they had to rebuild, like we have one company that was rebuilding from ruby to go lang and they had to take all of their engineers along that journey, which is not a kind of straightforward transition because, you know, the vast majority of learning approaches don't try and get people genuinely capable, try and give you kind of information that you can then experiment with by yourself.
And so it is, it is hard without a kind of the right approach to make that transition. Absolutely, it's a catch 22 how can you possibly gain experience in something if you're not actively breaking it for people. Yeah, well, that's interesting.
So at some point, remind me to talk your ear off about the day Difference between experience and skills, I think, I think broadly we treat experience is the only way to get skills, but experience can be simulated and so by simulating real world experience, we can give people skills much faster.
That's the sort of 12th version of a much longer rant that will take in modern hiring practices and how we assess developers and also leadership and other people like that, and how we do it all in the wrong way.
But anyway, let me ask you a question first, josh, because I'm interested in your background, particularly because you're so focused on the open source community, where I imagine the costs of restructuring are much bigger or sort of harder to anticipate upfront in a way, because your your users, the people who are on the other developers who are on the receiving end of your restructurings are potentially in the thousands, potentially in the millions,
and you don't have a day to day working relationship with them compared to in a sort of sme where there might be 100 developers, all of whom you can kind of hit up on slack with an app channel message and say, oh, hey, just so you know, we've made this breaking change to the A. P I here's how things are going to work from now on that much significantly change how you think about restructuring code.
It does, and it's very frustrating at times, I want full time open source because I love open source software, This has been something that's benefited my career and benefited the world quite substantially. Uncountable. E so it's, it's a wonderful place to be, but it is still somewhat the Wild West, we don't have sustainable funding. So people bounce in and out inherently pre open source software is made so that people can bounce in and out.
So it's kind of like working on the absolutely worst organized team, you could possibly imagine people still have positive intent. Everyone I work with is lovely. They really care. But gosh, darn one of the maintainers on the most notable project I work on has not been seen in four months. We don't know, I don't, you know, their gender. I think it's a he but that's just hearsay. I don't know their name. I don't know their time zone. I just know they come in once in a while and do amazing work.
Can you imagine working in a company where someone's like that, no matter how genius level their contributions are, they're out for us. Oh my God, this is a blessing. So yeah, it can be quite difficult, but it's not dissimilar from working at a very large company.
I think the larger the pool of developers you have to support as a, let's say, as a developer facing project, the larger that pool, the more like open source it becomes when you're at a small company, you can just turn over your shoulder virtually to the next person in the slack channel or if you're a small or medium sized company, you can add channel say and slack.
But if you're in a company with 100,000 people, you don't know everyone you're working with, you don't know what that personal context is for all of them. So it becomes kind of like the open source world where you can scream into the void about updates you're doing and hope that people listen, but you have to go out of your way to help them. You have to provide good documentation. You have to make sure that breaking changes are warned about long in advance and are worth the breaking change.
You can't just rename an A. P. I. Because you know the new name is better. You have to really just make sure that the old one still works for months, then it starts logging, then it starts logs while the warnings, then you have to reach out to the team, still using the old endpoint and get them to fix and often times you have to fix it for them. But even fixing it for them is work they did not account for in their sprint planning.
So now you have the situation where you've got a backlog bug to move off of the old endpoint for six months and so on and so forth. So yeah, it can be challenging in the open source just that is in larger companies, but it's I think it's worth it. I mean, I can't imagine a world in which we don't have these free open source software projects, eating industry from the inside, it's, it's just such a massive accelerator for the industry. So it's a good place to be, 100% agreed josh.
I want to firstly say thank you so much for this conversation. I've really enjoyed chatting to you about this and hearing your thoughts. Can you tell us where can people find your work and support you in what you're doing? Well, thank you for asking. You can find me on the internet as at Joshua K. Goldberg, that's on GIT hub twitter, my website, Joshua Goldberg dot com. I'm on foster didn for for mastodon, the system that I'm still getting used to.
Thanks to the shenanigans with twitter on Git hub if you want to sponsor me, that would be wonderful. I do share to open source projects and help mentor people in open source. So that's become slash sponsors slash Joshua K. Goldberg. The most important project I work on right now is typescript es lint, which is the tooling that lets you run excellence and prettier on typescript.
So if your company uses typescript, you almost certainly use us and therefore you should probably get involved with us. So the very least contribute. So we have an open collective go to typescript dash dot io to learn more and if you're not yet limiting your code or formatting your code that is typescript, you should reach out to me because that's a really good, important thing in your developers will almost certainly thank you for setting that up. Awesome. Thank you again, josh.
We'll put some of those links in the notes for the program and I wanna say thank you to our listeners as well. I hope you've enjoyed this episode, join us again next time when we will be discussing another question that is primarily context based.