A plea for boring tech with Jason Lengstorf
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at LogRocket. com today. My name is Paul, and joined with us is Jason Langsdorf. He's coming back to talk about his plea for boring tech.

What a title. So Jason is the creator and host of Learn with Jason. And we're excited to have you back, Jason.

Yeah. Thanks for having me.

So before we get into your talk, which is, boring software, very curious to hear what you mean about that. Can you tell our listeners a little bit about what learn with Jason is and how you got into web development?

Yeah. Learn with Jason is a weekly pair programming show where I bring somebody from the community on who's an expert in some topic and they will teach me about it live. That has been running now since 2018. We're coming pretty close to 400 [00:01:00] episodes now.

Oh my gosh.

And I, and on top of that, I make educational videos and like career growth videos to help people just, get along better in, in tech.

I got into tech way back in the early 2000s. I was in a band and we didn't have any money to pay for help. So I started figuring out how to customize a MySpace page, put our tour info up on, on a website, all that stuff. And through the course of being in the band, learned enough about web dev that when the band broke up, I realized I actually had the skillset to, to do it for a job.

And uh, did an agency for years from the agency went into a few contracts that were more full time and then to IBM and from IBM jumped into a startup scene. So I went and joined Gatsby, went to Netlify and these days I'm independent doing learn with Jason full time.

Oh, the big boys Gatsby and Netlify, like that's some of the cream of the crop. So when you were doing [00:02:00] learn with Jason, what was like the niche? That really people started to tap into that. You saw that growth. Cause I think a lot of creators, I see that like linear growth and then you do something and it starts to compound a little bit,

I would say I actually never saw anything other than linear growth. Like even today, I only have linear growth. I've been growing at roughly the same rate for five years and it's slow and steady. And I think part of that is because I've never done trend chasing or like engagement baiting.

My, my approach is more like web dev in general is a, it's a profession. It's not a, it's not a trend. It's not like one tech to end them all, or it's, a skillset that iterates through the years, but ultimately at the bottom of it, it's JavaScript is how we build for the web. And we just build different abstractions on top of that.

And so learn with Jason has always been built around this idea that if you. If you learn how to think about building for the web, all of the tools are [00:03:00] just different tools that allow you to accomplish this outcome of building for the web. And it, in my opinion, has, it helps me at least think more longterm and get less stressed out about the I don't know , am I learning the right things?

Am I doing the right things? Do I need to rebuild all my apps? I really, and honestly, that's like where this keynote came from as well is this idea of I don't know, I think we've built a bit of an industry that is hyper focused on like churn. Like we love new tech and if there's new tech, you must destroy the old tech to migrate to the new tech or else you're falling behind.

And that seems to be the narrative that we share in a lot of the, the marketing material the dev material the, the way that devs talk to each other, all of it makes it sound like, Oh, well there's this. elite group of developers that are always on the latest thing, and then there's all these other folks who are out of touch.

And it's no, that's really not how this works. Like the vast majority of the internet is still running on stuff like, I think jQuery is powering something like three out of four websites these days, or even [00:04:00] more.

Absolutely.

We just we get into a little bit of a bubble. So all that to say I've never really bought into this idea that there's one true way to build anything. And I think that actually really hurts me in growth because nobody's sure what I stand for because web dev is not like.

A hill you can stand on and make a big claim, right? Everybody's well, sure. We all do web dev. I'm not like the TypeScript guy or the React guy or the whatever guy. And that makes it harder for people to say ah, yes, this is the content I want. It's more like generalized.

And I think that just leads to slower growth, but I've also really liked it because it leads to, I think, sustainable growth. And also Less contentious growth like I don't know that anybody like hate follows me, and I'm okay with

Off of the J query thing, Jason, I just did a quick Google and I'm just reading the first Google result right here from Altamira. ai. But this is a common. Stat that I see across different reports that [00:05:00] at least , this research group is showing us that 78. 8% of websites are still using PHP on the server side. PHP. it's still tried. It's true. And if you ask a lot of like really senior people, they say I will use it. I'll die on that Hill. Cause I'm efficient in it. Why would I use something else?

Well, yeah, and I think a lot of that is driven by WordPress as well because I think WordPress is 43% of all websites

Oh, wow.

WordPress is driving a huge amount of the usage of PHP on the net. But yeah, I mean there's like Laravel and stuff like that. It powers the internet because it's a great tool and it's been continually improved for years and years.

And there's not a lot of surprises left, right? You've seen WordPress and Laravel and, these PHP frameworks go through their paces. They've been used for every application you can think of. They have figured out where it's really good and where it's really not. And there's also, like with WordPress, all these companies that have [00:06:00] dedicated their entire value prop to specialized optimized hosting for WordPress so that you know your website's not going to go down, right?

That's their whole thing. And there are a lot of reasons not to choose PHP if it's what you're learning, like if you're coming into the industry right now. But there's also a lot of reasons to learn it if you're coming into the industry right now, so at the end of the day, it's like choosing, a tool, and if you get really good with a tool, if what you choose is stuff that lets you be a plumber, then you can go be a plumber.

If you choose stuff that lets you be a carpenter, you can go be a carpenter. Neither of those is good or bad. It's just a tool that lets you make a living. And I think that this is actually a trap that a lot of devs fall into is this sort of there's somehow a superiority of a tool over another tool.

There's not, that's like arguing over whether a screwdriver or a hammer is better. It doesn't make any sense. It's a nonsensical

I love that.

to say well, one way I've thought about this is like when somebody picks up JavaScript, And they say, all right, I'm a JavaScript developer.

And then they build an identity around that where they're like, well, I am a [00:07:00] JavaScript developer. That's my identity. Then they take that as okay, well, PHP developers are different from me and therefore we are, we need to argue about whose tool is better. But that's a, it, to me, that's a, you're just cutting off a lot of opportunity for yourself because if you think about it, that's, that would be as if a carpenter walked into a job site and was like, I'm a hammer guy.

And they were like, okay, but we need to attach this thing with screws. And he's yeah, I'll use a hammer to do it. And it's but why? And and then it's well, if you hammer a screw in that's not going to work. He's like, oh yeah, it does. I've got this special method where I pound a hole into the wall and then I fill it with putty and then I pound the screw into that with the hammer and then I, it's and it's real good and it's okay, but that's a really inefficient way to do something that another tool would solve really well.

And they're like, well, that's what I do. I'm a hammer guy. It just, it always throws me off when people get really stuck on their tools like there's no alternative doesn't matter. We're here to, we're here to build something that people want to use that's useful and hopefully that they're willing to pay for.

[00:08:00] And if I have to, switch to Java or. net or, whatever, PHP. If you send me to any of 'em, and if it's the right job, right tool for the job, I'm gonna do it. I think the flip side to that though is that when you get really good at JavaScript, you can build a lot of things in JavaScript.

you know, There's a limit to that. But at the same time do I need to learn Java to build a website? Probably not. There are very few applications where I think Java would fall short in Java. Or JavaScript would fall short and Java would solve the problem. Ditto for PHP or any of them.

Because ultimately if you get good at a tool, you can probably make a web tool do the thing that you need. But that's not because of superiority, it's because you know it well. Like a, an oil painter, yeah, like an oil painter can make a really good oil painting and if you tell them they need to use watercolor, they can probably figure it out but they probably make a better painting with oil.

Not because watercolor is, inferior but because they have more experience and they understand it better.

Jason, I'd love to take this aura that we have this energy where we're talking about [00:09:00] tools and it. getting stuck on things. I also think it's related to like shiny object syndrome a little bit. Like I, I love the fireship channel because it keeps me up to the recent up to date with the recent frameworks and stuff coming out.

I can understand if you're a new developer though, and every day you have a new 90 seconds or a hundred seconds of this thing coming out, you might be like, Oh, this thing. And then that thing, it speaks to the same growing paint that maybe we're talking about here, which is the right tool for the job and just moving with what is.

Most appropriate for the task at hand. 

Yeah.

yeah I know you have this sentence or this phrase in the talk that you gave about the sins of your youth.

I think that raises a lot of memories for a lot of people. If you say, let's talk, let's think about the sins of your youth. Oh, God, what are we going to talk about?

Well, we're talking about tech here. So, Yeah, can you clarify for us a little bit, Jason? What are the sins of your youth as they regard to what we're talking about here?

I think, like, when I was younger I had this belief [00:10:00] that the problems were solvable and the problem that people ran into was that they didn't want it enough and not that it was extremely difficult to solve, right? And I think that this is a pretty common, especially like young man's.

outlook is that the world would be fixed if everybody would just think the way I think, right? I think we see that a lot in the way that people talk about their choices and their preferences and their world outlook. And without the benefit of a broad experience of how other people interact with the world and like what somebody else's experience of the world is, you just don't have enough empathy to be able to have a conversation that doesn't.

result in you saying well, sure, but everybody else is an idiot and that's why this doesn't work. And so I think that for me, when I first got into web dev, I always looked at the challenges of something like WordPress as being a failure of WordPress. So I thought to myself, well, I can build a CMS.

I know how to, to write something to a database. And so [00:11:00] my early agency days, I rolled my own CMS for my, clients. And it was fine. I mean, It was great. Was good for me to learn that stuff. But I also started to, you know, my vision of this like perfect, streamlined, no flaws CMS.

Very quickly, as it started to meet real client needs, I started adding caveats and edge cases and other pieces that like made the CMS more complex. And I had These challenges with it, things that were falling short. And as I added those, it got more and more similar to WordPress and all these things that used to irritate me about WordPress.

I now saw as being like necessary safeguards to prevent a client from deleting their whole website, for example, or to allow somebody to have a an editor who can change posts, but not delete them or an author who can write posts and edit their own, but not touch anybody else's all these sorts of.

permission controls. These needs to like have reusable blocks. These needs to do things that like, I was like, WordPress has all this [00:12:00] stuff and nobody needs it and all of a sudden I needed all of it. And so eventually I had to admit that I could either admit that I was, I had succumbed to my own hubris and that I was rebuilding WordPress and eventually I would get to something that was roughly feature equivalent to WordPress but completely hamstrung by the fact that I didn't have enough time or resources to go in and build all these things.

Or, I could just accept that WordPress is actually a great tool and I could go use it and spend the energy that I would have spent trying to reinvent wheels, just learning the idiosyncrasies of WordPress so that I could go out and build great stuff that my clients needed and that they wanted to pay for, right?

And I've made that mistake several times where I would go into a situation and somebody would tell me why, why the system was big or slow or whatever. And I would immediately jump to solutioneering and say, well, okay, well, the problem is that we didn't do X, Y, Z. So if we just rebuild this from scratch, we can obviously fix all those problems.

And then, if you get the buy in and I'm [00:13:00] pretty charismatic, I walk into a room and I can get people hyped about something. So I would do this. I'd go into a company. I guess somebody hyped about a rebuild. We would go and rebuild. Nothing happens for months because we're focused entirely on the rebuild.

And when we get to the end, we've got something that's roughly as complicated, roughly is as difficult to work with as the original build. But now it's in my preferred stack, and we lost a lot of the nuance from the edge cases that were handled in the previous stack. So we've got this new list of bugs to reimplement things that were already reimplemented, and we still haven't built any actual features that our customers wanted.

And I think That's been a pattern for me over and over again is I get focused on what would be fun for me, what my preferences are. And I index on that so hard that I forget that I've been hired by a company to create something that their customers want and are willing to pay for. And If I fall into that trap that I lay for myself, I delay the company from building features.

I delay the customers from getting something that they value because I wanted to chase my preference, which was to refactor the whole app or add a [00:14:00] hundred percent test coverage or do whatever it is that I wanted to do that I could have probably lived with if I would have just taken a minute and, thought to ask more about why instead of immediately jumping to, well, I could build this better.

I love hearing that because I feel like a lot of times when we have people who have worked in these zero to one environments they speak a lot about, you have to listen to what the customer needs. And if you don't, you're 100% of the time going to build something that the customer doesn't need.

Because what the customer needs is often very nebulous. They don't even know themselves. Your job is to go detangle that.

Well, and this is actually A phenomenon that I've been observing since I moved into startup tech is, especially working in the dev tool space, is this curve that is really pretty predictable. If you look at a lot of the companies in the space where it started by a dev who is solving their own problem.

So they, they see an issue that they have with their stack. So they set out to solve that problem. They get investment, they get a lot of initial groundswell [00:15:00] and they start growing and everybody loves their tool. And then. They make a shift. So at first they are their customer, right? I'm a web dev. I'm building for the web.

I wish that this thing was better and they see an opportunity, they go build it. It's great. They're, they have product market fit because they were the market and they built the product for themselves. But as soon as they build that product and release it, they're no longer their market. You are like when you are a developer building for the web, you consume dev tools.

When you start a company to build a product for developers, you're no longer a web dev. You are now a dev tools builder. So if you keep building for yourself, your product gets further and further away from what your original customer went. web devs actually want, and you're solving your own problems. And you'll watch this happen with a lot of dev tools companies, where the first thing they launch is amazing.

And then they get more and more into esoteric things that are really only relevant for their edge cases. And they start ignoring their core web dev use case, which is that the vast majority of websites are [00:16:00] informational, don't update all that often. They need to serve videos and images as efficiently as possible.

They need to be able to withstand the odd chunk of high traffic from an ad campaign or going viral or whatever it is. But that's it. But these companies have these edge case companies that are like, we need instant updates. We need global consistency instantly or whatever these things are.

And these companies start chasing these very. challenging technical problems that almost none of their customers have so that they can land like one or two big enterprise contracts or because they see it as a limitation of their product and they want to solve it for the sake of solving that hard problem so that they can be the most technically advanced company.

And in meanwhile. All these customers in the middle are saying like, well, this product doesn't feel like it's for me anymore. I'm going to drift off and go get something new that feels more like it's for a web dev. And this is you can see this happen over and over again with DevTools companies.

And now that I've seen it, what I'm realizing is that It creates this false sense of security when you're a web dev who builds a tool for web devs because at first you [00:17:00] are your customer and so you, you trust your gut. You say, Oh yes, I am correct. And then you get that first win and you go, see, that's a confirmation.

My gut is good. I'm right. I should do what my instincts say. And then you start building things that are unrelated to your product because you're no longer your market. But you've learned to trust your gut. So you don't listen when people say that's not what the customers want. You're like no, I know what the customers want because I am the customer and they start building in the wrong direction.

And there's this sort of like commitment bias, right? So something that I really would love to see more founders. address is this almost immediate divergence, like your gut is only good until you stop being a web dev, which is roughly six months after you build your product. After that point, you need to rely entirely on research.

And that's a really hard thing to do. And most most people I don't think want to be founders, because that means you become a servant to customers. https: otter. ai

Part of what I'm talking about in this talk is that you do this stuff because you start a company because you're a [00:18:00] passionate coder. You enjoy it. It's fun. It's your hobby. It's what you were doing on the nights and weekends before you made money doing it. And when you start doing a product, it's not the fun stuff starts to become fewer and farther between because your responsibility now is to build a product that people want and are willing to pay for.

And most of what people want and are willing to pay for is not super technically exciting. And so now you have to battle against your hobby instinct and you have to battle against this part of you that wants to be playing and pushing the boundaries and like exploring the limits of technology when what you really need is to add like better user management.

You need to fix that UI so that people can find the button, and that's boring. It's so boring,

but that's what people will 

pay for. 

You really have to zero in on that, which then we would call it at one start. If I worked, we called it doing the needful 

Yes. 

that you really just don't want to bother with, but it needs to be done for the product to exist for your vision to come true. Jason, I'd love to ask about the flip side of this. I'd love to ask about the [00:19:00] flip side of when boring and exciting tech might be valued. Excuse me, when it's the exciting side might be valued. Right before we do that, I just want to remind our listeners that this podcast is brought to you by LogRocket.

So if you're in your web app and you're trying to decode things, you want to spend less time on it. on that boring stuff so you can pave right over it less time in the console. LogRocket can surface errors. It can use AI to find patterns that you might not have otherwise noticed. So you can spend more time in your code editor pioneering those issues and hopefully, like we're talking about today, focusing on maybe stuff that you didn't otherwise pay attention to and letting you have time to do the needful.

So go over to logrocket. com today and check it out for free. Jason, on the flip side of this coin, like there has to be some environments that you've seen in your time through the startup, through the enterprise, through the hobby phases, when the exciting might have been preferred, might've been like important to the growth or development of your [00:20:00] team and company. Is that the case? And if so, like when did those times come up?

Yes, I have definitely seen it be the case that, there's a need to innovate your way out of a challenge. But it is rare, right? And a good example of this is I was at, when I was at IBM We introduced GraphQL there, and this is one of the few times where I think my instant solutioneering was not the wrong choice because, IBM had been, it's been around for a long time and a lot of their tech is geologically layered, where there was like the thing that they did you know, 15 years ago, and there's a thing they did five, five years after that.

And then, three years after that, they did something else because it just, that's how turnover works. Like people come in, they build some stuff, they want to use their own tools the landscape shifts, and you're never going to have enough time to rebuild an entire IBM sized app. Instead, you just figure out ways to layer it on top of what was there before so that you get to make the part you like into what you want to work with. And you just [00:21:00] let the rest of that sit as write only code, like the idea of an append only file which is pretty common in big companies, I think.

So The problem that I saw was that IBM had tried to do this shift to microservices and prior to that they were on a monolith, but they didn't really have the time to build out all these different microservices. So what they actually did was duplicated the monolith 35 or so times. And each team got their own copy of the monolith and they didn't have to worry about what the rest of the monolith did.

They just had to make sure that their part of it was the micro service, right? And so there were 35 copies of this monolith, most of which was dead code because most of it was related to parts of the microservice that weren't. to parts of other microservices that weren't used in the team's current implementation.

So everything was drifting, getting out of date. Everything was super weird to update. There was so many files where people had just, they had no idea how things work. We had a lot of those mystery things where it was like, we can't see where this is called, but [00:22:00] if we delete it, everything breaks and we don't know why.

Just mysteries, like mysteries on mysteries. And so what the teams were doing was We just had this like really Byzantine process where every team had to roll their own off. And so there were, and they had to do these other compliance things. And so there were, a few dozen teams, each of which owned their own microservice and each of which had to do these compliance things.

And then there was a design system team that was trying to unify the UI. And there was a team that was trying to unify the way data was being done. And each of these teams had to be policed by these other roaming teams that would go on rotation to go try to make sure compliance. Matched across all the different microservices.

So there was like a security team who had would go and embed with each microservice team in rotation to make sure that they were doing updates right. Then there was a front end architecture team or the front end architect for IBM cloud had to go rotate between teams and make sure that they were doing things in a way that was blast, right?

And this was really inefficient, like those [00:23:00] teams would never get done. And by the time they left the team before them, within a week or so, they were out of compliance and they had not even gotten close to. To getting everything back up. My, my initial thought was, okay, so we're not doing microservices here.

We're doing mini monoliths. So how do we get to actual microservices? And the way you do that when you have a UI team cause that was the part I was responsible for was the UI. I was like, okay, well, let's make this UI actually. a microservice. So we made it headless. And the way that we made it headless was by laying GraphQL over all the backend microservices so that they only needed to communicate to one thing the GraphQL layer.

And if they were making changes, they had to notify the GraphQL layer. The GraphQL layer was able to identify whether or not something had changed upstream and then could notify us so that we could then go hunt that team down and ask. It just it turned into this communication tool so that there was the back end spoke to GraphQL, GraphQL spoke to the UI, and if the UI only had to speak to GraphQL, we could literally delete the mini monolith and actually just build a [00:24:00] UI, a static UI that spoke only to GraphQL.

GraphQL. And so we did that and we started seeing the UI speed up by, 3500% or 3200% on one of the UIs. Another huge benefit was that iteration time went from like months to weeks, in some cases days, where you could have a single sprint where we'd build out a whole dashboard. UI. And that was completely unheard of, but because we'd been able to remove all of this kind of like layers of cruft.

And because of the way that was set, I was able to make an NPM package on the private IBM node setup that standardized all of that compliance work and abstracted it in a way that the UI teams never had to use it. They just had to put it in their express chain. Because that was the way they had an Express app, right?

So I made Express middleware that did all the compliance. And then the compliance team just had to keep that one middleware package up to date and all the UI teams would just bump their version and it would stay up to date, right? So it was one of those things where like doing a modernization like that was the right choice.

[00:25:00] Because of the way that it was built in the past now were the tools I chose the right tools we can debate that all day and I think people at IBM might still be debating whether or not it was the right choice because I know that I immediately hit pushback from one of the back end teams on well, we shouldn't be using this open source package.

We should roll our own thing like graph QL and they started this political thing about who should control that middle tier, right? So you're never going to get a good solution, especially at a big company. The bureaucracy is just going to be there to stay, but. The only thing that I'm a hundred percent confident in is that the way they were doing it was not sustainable.

We were just burning weeks and weeks of time and it had led to things like there's this sense of fear that you see from teams when they start to hit a certain level of slowness. And I've seen this in not, far more than IBM, like just about every company I've worked at hits a point where there's a competitor that they feel is outpacing them.

And. When that happens you start [00:26:00] to see decision making get really weird. Like instead of saying what's the right thing for our customers, they start to say well, that feature is interesting, but does our competitor already have that? And it's well, no, that would be an advantage. Well, let's focus on getting feature parody with our competitor instead.

on the present, not the end goal.

Yeah. when iteration speed goes down then everybody starts playing defensively against the slowness of the organization, and it just, it screws up the incentives, it screws up the decision making process, and it starts to compound the bureaucracy, because nobody wants to take risk anymore, and in a company that is trying to make something valuable, You don't have guarantees that what you're going to build is what your customers want.

And the only way that you can de risk that is by being able to iterate quickly. And so it is the right choice to try to find ways to iterate more quickly if the tech is legitimately, and this is the 10, 000 foot if the tech is legitimately the thing that is preventing you from iterating quickly. But what I would wager [00:27:00] is that in the vast majority of cases, it's probably not the tech, it's probably the team and no tech stack is going to solve team dynamic issues.

And so that, that's the piece where I think, if the tech is boring and you all understand it and you all understand how to ship with it, and the problem is the politics of how ideas move through your organization and get live, that's a very different problem and you would be better saving your energy for fixing those team dynamics rather than assuming that you can like program your way out of a bad political situation.

Programming your way out of bad political situations sounds like the perfect like bow to wrap up this present because that truly feels like a cathartic phrase of the mentality that emerges where it's like social problems are scary. Political problems are scary in the company. Your job could be at risk in some situations if you're met with too much pushback.

So wouldn't it be great if I could use an impersonal solution and code my way out of it? It's a natural engineer's thought process sometimes. [00:28:00] Going back to your example about GraphQL, like what about that team strata or the existing technology do you think was the transferable piece that people can look for in their organization, in their team that could help them identify when, indeed, a innovative new piece of something from their brain. Is an add and not a hindrance. What is transferrable from your situation there, Jason.

So I think the reason that I. believe that GraphQL refactor was the right choice is that the significant contributing factor to the slowness at IBM at the time I was there was that. The majority of the code was irrelevant to what you did day to day, but you couldn't ignore it because everything was tied together, right?

It was the classic, why would you not use a monolith? Well, because every time you touch anything in the code base, you have to check all the other things that it might touch and make sure that you didn't inadvertently break something, right? And when you don't have solid [00:29:00] test coverage, which we didn't, then you just have this very cumbersome manual testing process.

So we had this QA team with a big checklist that had to go through every single change we made to make sure that it worked. When the data teams, a backend team made a change to the way that data worked, the APIs would shift. And they didn't know who to tell. There was no communication channel so that all the other teams could be aware that their stuff was updated.

And we had tried things like an email list. We had tried, some kind of regular update cadence. And people would forget to put something in. Nobody would check it because they got too many emails. There were, there were a lot of reasons that, that didn't work. And so, the major issues that we had were these communication issues where we didn't know how to communicate what needed to change because a lot of times we didn't understand the depths of the code well enough to clearly communicate where the risks were.

So everybody kind of hedged on what they were willing to accept because they didn't want to accidentally get into this rat's nest of Oh crap, I touched the legacy system. [00:30:00] Now I got to go untangle this. Thank you. There was this cross team communication issue where the QA team had to do these really cumbersome tests which made it really slow for us to get a change into staging and ultimately to production, and the feedback loop was really long.

You would put in a PR, and by the time that got into staging and through QA, it might be two, three weeks later. And so you're completely out of that mental mode. You've forgotten what you were working on. You like, remember that you built it, but you don't have all those mental constructs that allowed you to really think through that problem.

So if there was an issue and QA sent it back, you had to rebuild that whole model and then wait another three weeks to get that feedback. So the feedback loop time was so incredibly long and the prospect of being able to write tests for this word. It was like there's no chance we were never going to get enough time to actually write tests for this code.

So adding GraphQL helped solve those communication problems in a couple ways. One by providing a single source of truth for how front end spoke [00:31:00] to data, then the back end teams no longer needed to ask who they had to update. only had to tell the GraphQL layer because that meant that people could use the GraphQL layer as docs.

Like the GraphQL schema was close enough to docs that it was significantly better than what we had before. And it, we knew it was true because it was generated from code. And so that. was a huge step forward for us and it made the back end teams willing to communicate because they knew that somebody would hear it.

They knew that if they made a change, somebody would understand that the change had been made. We also got there were benefits for them as well. We could we could see like per field. which data was being used, which was really important to them because they had dozens and dozens of bespoke rest endpoints because each team would need a certain shape of data and they had no way of really knowing how often those pieces got called or which pieces of data in those bespoke endpoints were actually being used.

So this also allowed them to sunset a lot of unused endpoints that had, three years ago were important, but that service had been [00:32:00] turned off. And so that endpoint was just sitting there being maintained for no real reason. And on the QA front, because the GraphQL layer was there and it let us get to a fully headless UI, or a fully decoupled UI, that decoupled UI was actually testable and it wasn't related to all these other pieces of the code.

So what the QA team had to check started to drop down until we actually got test coverage on the UIs and we didn't have to go through QA anymore. We could actually ship because our test suite was automated enough and we could prove with like video playback and all that stuff because of things like Cypress.

It worked. It all functioned, right? You could just know that the UI was okay. And there was no way that it could touch anything in the back because it was a separate code base. So that decoupling and that graph QL layer solved very real iteration problems because it cut it like simplified communication and remove these hurdles that, that devs in this company were having to deal with to get work done.

So Yeah, you know, we just saw an enormous improvement in [00:33:00] morale too, because when a dev got asked to work on one of these modernized UIs, they were like, yeah, I can do that because they knew what it looked like. They understood the full breadth of it.

Would you say that the key takeaway here is tightening up these iteration loops. That's when New Tech can really step in and be a winner.

Yes. And I think that the approach that I've been taking to this. Since the lesson learned at IBM is the value at IBM wasn't the tech that we chose. The value was that we saw a very specific internal team slowdown that was based on the human setup, right? The complexities of communication of testing and feedback of deployment and of like rollback safety, all that stuff that makes deployment slow in big companies.

We needed a way to tighten those to shorten or even eliminate like in the case of QA, we didn't need QA to look at UI because they were really only there to make sure the business logic stayed sound, but because of the way that [00:34:00] it was architected, they had to look at UI because UI could break business logic.

So this decoupling eliminates that need right to tighten it simplifies their job, their checklist gets shorter, they're doing less really boring, mindless, click a button, make sure the button works kind of stuff because we can have a robot do that. And they're focused more on the things that actually matter.

Hey, did the math for this, like billing API work the way that it's supposed to? And yeah, it's the, if you can use the existing tech, because there's a huge switching cost, right? If you like IBM had a few dozen teams by somewhere between five and 15 developers per team, so that's well over a hundred developers that need to be retrained when a system changes.

So this actually is, was part of what like ended my career at IBM is after I shipped GraphQL, I became an internal advocate at IBM for training people on this. I basically went on tour inside the company teaching other devs on other teams how to use this tool. right? And that's what got me mired into the politics and stuff that ultimately led to me not wanting to [00:35:00] be there anymore.

But the the switching cost is enormous for making a technical change in a company that's over even like a dozen developers. So if you can solve these problems by rearranging your existing tech so that you don't have that switching cost, that's I, that's better because the problem you're trying to solve is how do the devs on the team speak to each other and work together?

Not are we using the coolest tech? And if the tech meaningfully, like truly meaningfully impacts the way that the team works together, then it might be worth that switching costs. But you really have to weigh those trade offs together and make sure that what you're doing is going to have a higher upside than all of the weeks and months that you'll lose in doing the refactor in training everybody on the refactor in following up with everyone and making sure the other teams have switched over and that you don't have these like fractured pits of the code base where people don't want to do it the new way because all of that will happen.

if you're not willing to go do that, like if, and this is the other problem is a lot of times devs want to go build the new thing, but they don't want to follow through [00:36:00] on rolling it out. And that's how we end up with these like stratified layers of whatever geo geological tech where like you go, you go do the archeological dig and you can see.

where somebody had a great idea and didn't want to follow through. And so there's this like very cool, partially implemented, whatever they could control themselves, piece of tech that no one else understands or can use because they weren't willing to do the work to socialize it.

Classic. That is classic. That is a classic software story. So Jason, what about, this example we're talking about here is. The minute piece. If we take the minute piece of a developer's career, if we're taking away from your talk, like putting in bespoke pieces of tech, changing things, the point of your talk was really like a lot of tech is the boring stuff.

And it's, it's really this needful stuff that needs to be done. So for developers that there's going to be plenty of folks out there that maybe don't see that immediate position where they can go, Hey, we can save like this amount of hours. We're [00:37:00] going to roll this out. Like maybe you do with GraphQL.

What do you have to say to those folks trying to make a change on their team that are maybe in what you would label as the boring category? Are they like just pushed off to the side or that's not really the point of your talk. So I'm curious how you 

compare those. 

The point of my talk really is that I don't want people to prioritize fun. over value in their job, right? For many reasons, but the most important one is this, when you introduce something exciting, something fun at work, you have to go train people about that.

You have to maintain it. You've got to make sure that it stays up. And if you don't do a good job of socializing it, you're the only one who can deal with it. And pagerDuty becomes your problem. If something is wrong, you get to fix it, right? Suddenly all these things that you thought you were going to get to do, like play with all this cool tech, you end up babysitting your cool tech that you built.

And, or looking at a huge stack of docs you need to write, a whole bunch [00:38:00] of refactoring that needs to get done, a whole bunch of retraining that needs to get done, and it stops being fun. So now you are the tender of this cool idea that you had, and that's not as fun as being the builder of a new idea.

And so for somebody who is hankering for a new idea, do that. on the side. If you want to go play with new tech because it's fun to play with new tech, I so deeply support that. That's the foundation of learn with Jason, but do it for fun, right? Do it in your 10% time at work on a little hackathon project, do it on your nights and weekends.

If you've got the luxury of having that kind of time, let a hobby, be a hobby. Don't force your hobby into work because it stops being fun when it stops being a game. And the major issue that I see is that if you continually introduce hobby projects into the production code base, it slows the team down.

It leads to complicated and difficult to understand code. And probably it leads to you feeling so bored and trapped by the code that you've written that you'll leave. And [00:39:00] now your company is stuck with this code that nobody understands because the person who wrote it is gone. And beyond that, you also all, none of that.

that I just talked about has anything to do with producing something that a customer wants and is hopefully willing to pay for, right? Like Migrating a statically generated app to the next JS app directory right now, almost I would bet so much that 99. 9% of apps out there will get no customer benefit.

From switching from a static site to the next JS app directory because the customers don't care and it doesn't matter for so many of these edge cases because what the customers are asking you for is Like fix this button that I thought would do this that does that instead, get like you watch something like Twitter, right?

Like what people ask for is never what they build They're always like we now run, you know on some super server and they're like cool. Can I have an edit button? It's that bug where every time I scroll down, [00:40:00] it resets my place in the scroll order. Like those aren't fun bugs. They're not going to be challenging technical solutions, but that's what people want and will pay for.

And if you're too busy doing whatever it is they're doing at Twitter right now, you get further and further away from solving those bugs instead of building things. You know, it's it's all very frustrating to see. And you can see the devs get frustrated with it too, because they half chase.

A very cool technical solution, and then they realize that it's not a, silver bullet as Sunil Pai said that sticks in my head all the time silver bullets only work on werewolf shaped problems, and nothing in software is actually werewolf shaped, like you, you try these things, they seem like they're going to solve all your problems, but really they just haven't been examined well enough to expose the challenges, right?

Like Laravel, WordPress, they've been put through their paces, jQuery, we know where it's short. You can be very clear on what jQuery can and can't do. We have no idea what React server components can and can't do yet because nobody's used them at scale. So we'll 

learn those things, but it's [00:41:00] not because they're superior that we haven't heard these horror stories.

It's because they're unexamined. And that doesn't mean they won't be. They will be. Somebody's going to get through building really advanced production stuff in Rust. They're going to build it in React server components. We're going to get these case studies. We're going to get these stories, but we're going to find out that they're just as limited as all the other tech.

They're going to have trade offs. There'll be things that are better and things that are worse. But if we're all just chasing shiny. Shining always seems flawless because it's, it's very carefully lit from a marketing standpoint. We haven't seen the flaws aren't exposed yet.

So yeah, I think that ultimately I want work to be boring because I want the exciting stuff to happen out of work. I want to build fun projects. On the side, I want to have excitement with my friends. I want to be able to go on vacation without worrying about pager duty. I want to be able to leave my computer in the office on Friday nights and pick it up again on Monday mornings, right?

All of that stuff is so much more important to me than whether or not we're shipping the most bleeding edge tech at work. Like a job's a job. No, when you die, [00:42:00] they're not going to put, ship the latest version of next in production on your tombstone. They're going to put whether or not you like had friends or family.

So let's let work be boring and let's have exciting lives outside of work, 

i, I, this just makes me wonder if the creator of insert next framework is going to have creator of insert next framework on their gravestone. Cause that would be one heck of a look. Uh, Jason, we're running up on time here, unfortunately, cause I know we could go for another hour.

about the state of the industry here. You're like you're fired up. I'm fired up, the rotation of the earth isn't on our side. We, time is not on our side. So a closing out, you know, you do learn with Jason. Where can folks find that? Is that on YouTube?

You can find me on YouTube. There's also learnwithjason. dev, which is a kind of consolidation of everything I do and the easiest way to find all the stuff I do because I have a few different domains is to get on the newsletter at Learn With Jason. So lwj. dev slash newsletter and I send out a digest of whatever I've been publishing across the web.

Awesome. And [00:43:00] could we close with a fun fact? What was the name of your band? that you toured with.

The band was called Minus My Thoughts. It was as emo as it sounds and you can find it on the internet if you want to hear how bad it was.

Thank you for that. I'm going to go looking, Jason, because I'm curious,

jason, it's been a pleasure. Thank you again for coming on. We're going to look forward to the next time having you.

Yeah. Thanks so much for having me. This was fun.