Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/front end dev: scale your thinking
80 Plays1 year ago
James and Aaron are joined by Adam Barrett to discuss software rewrites and web front end development. After almost 2 decades of web development, and over a decade of consulting at companies from large enterprises to tiny startups, Adam has learned a thing or two about the business of the web.
Recommended
Transcript
Introduction to 'The Forward Slash'
00:00:16
Speaker
sheoo skin she ski everybody we got to tell if she
00:00:29
Speaker
Welcome to the forward slash where we lean into the future of IT. I'm your host Aaron Chesney with my beautiful co-host James Carmen. You know James today I was reflecting on my past and how I got to where I am today and you know I I chose technology as my path ah for my career, but but you know, when I was first starting out, I thought maybe of working in a factory of mirrors or working with mirrors. It's, you know, something I could really see myself doing.
00:01:08
Speaker
Wow.
Humor in Personal Stories
00:01:09
Speaker
That's a, that's a fantastic dad joke. I enjoyed that one very much. So, you know, that reminds me of when I was a kid. Uh, my dad, he used to work on the, uh, the road crew. You know what I mean? Built men, you know, uh, maintaining roads and stuff like that. He worked there for many, many years, but, uh, uh, he got fired for stealing. Yeah. We were, we were all very surprised, but when we got home, all the signs were there. Yep. Nope. Okay.
00:01:45
Speaker
What have I come on? Do you want to just introduce our guests, Aaron? Oh, sure.
Introducing Adam L. Barrett
00:01:53
Speaker
So after almost two decades of web development and over a decade of consulting at companies from large enterprises to tiny startups, Adam has learned a thing or two about the business of the web. Former host of the Build IT t Better Podcast, a web focus show about design patterns in development,
00:02:13
Speaker
and excruciatingly entertaining public speaker, Adam L. Barrett has all sorts of opinions on coding, design, architecture, business, intra-office politics, and board games. He also wants nothing more than to stuff them in your ears until you politely ask him to stop.
00:02:33
Speaker
adam Why don't you tell us a little bit more about yourself? ah Thank you. Thank you. Thank you. I love that excruciatingly entertaining. And and yeah that's a perfect way to describe you, Adam. him I love it. I mean, I don't want to you know let the audience see the little man behind the curtain working the levers or anything, but I may have written my own bio there. I'm just saying. That's not legal in some states. but
00:02:57
Speaker
um But yeah, the Nobel Prize winning part, by the way, you know, I don't like to brag is what it is. I don't like to bring that up. um But yeah, no, I. I'm Adam Albert. I, ah as mentioned before, have been the host of a couple of podcasts. I've made my career in sort of like going into companies and helping them write better like JavaScript and front end sort of web focused code. um I also dabbled in other programming languages a bunch early on, but I've really kind of taken the web as my focus for at least the last 13 years. um And then, you know, for about seven years before that, oh man, realizing that I'm
00:03:34
Speaker
approaching the second decade and it's just making me feel old. But I have worked at places as as big as, you know, I don't know what I'm allowed to say, but I worked at places as big as Apple and Walmart Labs as a consultant and as small as like very like three people startups. um And so I've had a really good range of experience. I kind of learned a lot and then I like to push that experience out onto other people and pretend I'm being helpful by just, you know, allowing myself to say whatever I think as though it's right.
00:04:03
Speaker
We call that consulting. Yeah. I mean, that's, that's, it sounds good. Nobody wants a consultant that comes in and goes, I don't know. What but do you guys want? I've never seen this before. yeah this is because you have any opinion You guys have any idea how we'll fix this? So yeah, nobody likes that consultant to be perfectly honest. So what is it like? Um,
Insights on Young Developers
00:04:28
Speaker
The front-end communities tends to kind of have ah a reputation of having more of a younger generation, right? As the, you know, kind of the whippersnappers, right? So what is it like being someone who's had a lot more years of experience under his belt working in that community and within that those frameworks and everything? How's how' has that experience been? You know, i would I would honestly say like both frustrating and fulfilling at the same time. the You know, looking at the stats, it's something like The amount of new people like doubles every, whatever it is, few years. I can't remember what the actual number is, but it's like,
00:05:00
Speaker
So there's constantly more new people than there ever were before in web development, just constantly coming in. And so I i end up in this spot where I have a lot of people who are enthusiastic, but there's this like strange thing that happens at about year three, and you know maybe it's the Dunning-Kruger effect, maybe it's something else, but where you know they've learned enough that they know everything, and there is no problem they cannot solve. And it's very hard to convince them that I know I've been there and I know what you're thinking, but trust me, I know what I'm doing. So I have this like balance of completely enthusiastic people who will listen and other people who I am constantly, just constantly trying to convince. I swear to you, I really do know what I'm doing. I swear. I promise. It's only been my career for the last long time.
00:05:48
Speaker
I promise you, I know what I'm doing. And it's seriously, I just feel like that is half my job is convincing people I know what I'm doing. And it's come down into like tricks almost like I have a plan, I can almost recognize the people who are going to be trouble. And I like have this, you know, it's kind of this. Oh, there's a movie that Is like it I can't remember. what It's called oh the Dow of Steve the Dow of Steve if you ever see that movie He's got this plan for how to impress women and mine is like how to how to how to make myself known i I do something awesome first in front of them and then they're like, oh that's pretty cool and then I like you know help them do something awesome and then They seem to respect me and I have to like pick out the individuals who I have to do this stuff But yeah, it's kind of funny frustrating and rewarding
00:06:29
Speaker
Of course, when I got out of high school, I already knew everything. Oh, yeah yeah. Yeah. I have a 12 year old who knows everything, but yeah. I was going to say I was about 12 or 13 when I knew everything. And then somewhere in my twenties, I think i it was when, um It was something in society changed and suddenly I knew nothing. Right. There was a lot more things around, like for some reason new things got invented that I didn't know. Yeah. Your points are that I had never considered before. um, Yeah. Yeah. I think that's when aliens landed and possibly, you know, and, and took over and I must not have gotten abducted with everybody else because I didn't know what the hell was going.
Y2K Bug Fears and Lessons
00:07:13
Speaker
Yeah. and And they introduced the new math and that was a big deal. The new math. just Oh, the new ones. Yeah. The new math really brings things up. then Oh, in Y2K. The new math in Y2K, those two things. Y2K.
00:07:29
Speaker
but not like
00:07:33
Speaker
Not to tend like too much, but did you actually like, I was kind of worried that night. I must admit everybody else, we were we had a party at my friend's house and I was like, you know, the switch over from 19 in case somebody is too young to know what I'm talking about. Uh, the switch over from 1999 to 2000, everybody thought computers were all going to crash. Planes were going to fall out of the sky, blah, blah, blah. And I knew it wasn't going to happen because I know how computers work. and But I was a little bit like,
00:07:57
Speaker
i wonder What these is going to happen? Are these nuclear codes that are going to like have a problem because they have two digits storing the date, but no, everything was fine. Yeah. I was, I was expecting something, just not anything catastrophic. I'm like, because everybody was like, Oh my gosh, we're not going to be able to get money and the power grid's going to shut down and blah, blah, blah. And I'm like, all right, if anything, you're going to see maybe a flicker.
00:08:22
Speaker
Like the lights will go blink, you know, or something like that. And then like you said, the interesting thing was nothing, like nothing not even little glitches, nothing I heard about. So I think that was probably both like, Oh, overestimating the problem, but also because a lot of people spent a lot of time for the decade leading up to it, fixing those problems. But yeah, nothing was, was actually a surprise. Just absolutely nothing on Y2K. See, I don't even remember being a decade. I remember it like being.
00:08:52
Speaker
maybe three to five years with it. It was like, Oh, somebody goes, we're going to have a problem and it's covered up. We got it. We better get out of this because everything is set to a two digit year and our systems don't know of anything before 1980. It's like, okay. I don't know if it was a full decade, but I do remember in my like first year of university computer science, which would have been, I think 95 96 is somewhere on there.
00:09:21
Speaker
the professor mentioning the Y2K problem. That was the first I had heard of it. And I was like, that's so maybe just like five years before, but I assumed if academia knows about it, other people must have known about it for years too. Yeah, having to like, it was funny how pervasive the issue was when you started kind of trying to fix that the two digit problem.
00:09:45
Speaker
It was like pulling a thread, right? And a lot in a lot of systems, like it was just like pulling a thread. And you you almost want to like just say, okay, let's just scrap this whole thing, right? And start over from scratch, which was, you know, we all like to do that, of course. But, you know, but does that even work when youve when we
Software Rewrites: Pros and Cons
00:10:01
Speaker
scrap it? I don't know. Is that a thing? That is a very interesting subject that maybe we could get into because, you know, there's this thing that happens in software where Every senior developer you ever know, every like software person who's got a little experience under their bed will tell you, don't scrap everything and rewrite it. like That's the biggest mistake you can make. right And if you know if that's the biggest mistake you can make, well, then why do why does it keep coming up? And they say, oh, well, you know it's the it's the instinct. It's the junior instinct. Like, oh, you know what? I can't understand this. I just want to scrap it and rewrite the whole thing. I don't want to understand what's fixing and going on.
00:10:41
Speaker
Now let me take a moment to get into my diatribe here because I think that they might be wrong and I'll explain why because this is this is a blog post that I've actually been waiting to like thinking about putting out, but I'm worried about the backlash almost because I'm worried about everybody going, wow, this guy does not know what he's talking about. This is an idiot. Don't listen to this guy. He's dumb. But the truth is I have been a part of at least two very successful, complete big pie in the sky rewrites.
00:11:14
Speaker
And everyone's like, what? And like, don't do that. it's It's the wrong choice. And I will say, yes, absolutely. It's probably the wrong choice. But every now and then you come into a project and it is so far gone. It is so bad. And it's not just a lack of understanding because sometimes you try and work with it. You try and figure out where you're in. What could we refactor to just make small parts better and then build around it and stuff? But sometimes you get to the point where this is becoming a problem. We can't add new features. Things are taking too long and a complete rewrite might actually be the answer.
00:11:42
Speaker
And it completely right comes, you know, along with this like natural thing that you get to refactor a bunch of stuff anyway, like is just going to happen because you're trying to rewrite the whole thing. You got to understand the requirements again, you got to figure stuff out. And I think that's where people would say, yeah, that's the biggest problem, because once you're doing that, you're going to lose all this knowledge that had been built into the system already. And but I kind of feel like, yeah, but if you're afraid to touch stuff, that's a bad maintenance cycle.
00:12:07
Speaker
But I know that this is like, everyone's gonna be screaming at me right now on the on their ears to be like, what are you talking about? Don't be dumb. But the problem I think is just how people go about doing the big rewrite. Because the big rewrite is like, um everybody thinks, oh, I got this idea.
00:12:25
Speaker
and I have been a part of many rewrites that were not successful too. And I kind of feel like I'm starting to pick up on the patterns. And for me, there's these patterns that are like, and I and i mean like the patterns of why why they fail and why they pass, because there is patterns, you know, like there's the strangler pattern where, oh, you rewrite the parts around it and as you add more and more rewrite parts, the parts that are bad kind of like, get oh, they get smaller and smaller and eventually they go away. The problem is ah most of the rewrites I've been a part of,
00:12:55
Speaker
It's like two years, three years and they're still going. The rewrite will someday, oh yeah, yeah, we're halfway through and someday we'll get going. And I kind of feel like that's the state of so many projects. I've come into a couple of projects.
00:13:07
Speaker
where they're like, yeah, we're having trouble. We need somebody to help out. And they're like halfway through two rewrites. So they started a big rewrite and never quite finished. Oh, and they started another big rewrite and now we're never quite finished. And, you know, sometimes it's like switching, you know, in, in, in the web and JavaScript world, it's like JavaScript frameworks. Oh, we went from like Angular to React, but now somebody convinced us to try this new thing, Svelte. And so we're kind of halfway through that too, but we've still got some Angular there where we can.
00:13:30
Speaker
realize that. And so ah there are part there are things that you can do to ensure you have a successful rewrite, and there are things that are going to ensure you have a bad big rewrite.
00:13:40
Speaker
I think one of the things I've seen, and I always thought like, cause I've been doing this a long time and and I'm kind of on the same side as you. Like I do think a rewrite now, I probably tend to reach for that a little too often, but I tend to think that a rewrite is, you know, they, they can be successful and they can be effective. I think one thing that I've seen in the past when, when you do make the decision to rewrite.
00:14:03
Speaker
It's usually it's like, okay, how do we redo exactly what we did for the last 20 years again in a new language, new framework, whatever. It's like your track. There's no rethinking of how can we better solve this user experience, you know, and and solve this problem for our users, all of those things. You know, you've, you've got the patient, like this is the.
00:14:23
Speaker
The patient's on the table. We can actually take care of something here and people don't take those opportunities. That's I think one of the biggest issues of a rewrite, you know, the whole feature parody thing and all that. Like let's do, let's just replicate exactly what we had in a new language or whatever. So I think that's one of the things I see a lot of.
00:14:40
Speaker
Yeah. And you'll you'll see that, especially when people have like automatic tools to do it for them. They're like, Oh, it's okay. We have this tool that's going to run through all our components and do the thing for us. And it's like, uh, what are you gaining then? Like if you're just going to make the same mistakes that have led you down this path to this horrible confusion that stopping features from going out on in ah at a good pace, what are you gaining by this rewrite? So yeah, I a hundred percent agree.
00:15:03
Speaker
Another problem I see is people, you know and this is this is why people will usually rail against it, and I don't think it's a realistic thing, but it's stopping development. Like, okay, we're gonna we're going to stop feature development for three months, we're gonna do the big rewrite, and then when it's done in three months, which never will, by the way, when it's done in three months, then we'll start feature developing again. It's like, no, no, you gotta realize that this is an ongoing process, it's part of the stuff, but you still gotta keep bringing stuff in. You still gotta try and, you know,
00:15:31
Speaker
build stuff for sales, you might need to hire more people on. Um, but of course, everybody you add is just more, uh, technical problems because you have to like bring those people up to speed and do stuff, but maybe they hire experts in what you're rewriting to whatever. I was just going to say, I think another thing with that too, is that a lot of the times the the original requirements of that system that you're working on, the people that came up with that or knew that problem domain very well are usually no longer around or have moved up and out of that space. So the ones that I've found that are doomed to fail are the ones that are always looking to do it exactly the same way because nobody knows exactly what it's doing and how it's doing it because that that domain knowledge has passed on. And I think the ones that I have seen work
00:16:26
Speaker
on a Greenfield rewrite are more those ones where we're going to look at the problems we need to fix and we're going to reimagine the solution because then they understand what is it that we actually need to do and then let's just rebuild the system that does it.
00:16:46
Speaker
And you know there's a side effect of reflecting on why you do certain things too, because if nobody in the company's leftover who can tell you, well, why did we do it that way? And the answer is just, well, it works, don't touch it. That's really bad. Do you know what I mean? If there's no, you know whether it's documentation or just a person who gets it or you know expertise in the area, if there's nobody to say, well, we have to do it that way because then that's a problem that the rewrite can kind of come in and solve.
Strategies for Software Rewrites
00:17:11
Speaker
A thing I find that often is the biggest i think reason for failure is There's kind of two two methods to the rewrite. There is the bottom up or the top down, and then you're like, well, what do you mean? And it's it's a little more apparent, I guess, in web um development because there's this very clear like tree almost of stuff. It's usually a tree of like, oh, component tree in the front end or something, or a tree of like, here's our where the entry of the user is, and then here's the API dependencies it takes, and then they call different sub-services, whatever. And you can usually see it as like, oh yeah, there's a starting point,
00:17:45
Speaker
kind of dependencies spread out and then okay and then we we get our thing and people think it's a good idea to do leaf up so you're like oh well we'll do this leaf we'll do this leaf we'll do this and and eventually we'll we'll consume the whole app and it'll be great I think that's the biggest failure because what happens generally is you start doing it. like Oh yeah, it's great. The enthusiasm's there. everything But the hard stuff starts getting pushed up because it's like, well, we we can't rewrite this whole thing. So I'll just do this leaf and I'll just push that up. And that's kind of the refractory. So the harder stuff kind of gets harder, harder pushed up and the enthusiasm for this rewrite starts to die as it gets to the point where it's like, well, you know, people leave the company.
00:18:26
Speaker
you know, whoever was pushing for it in the first place kind of takes off. And it's like, yeah, this just keeps getting pushed up. And then you get this really hard part that nobody wants to like tackle because it'll be a big deal. And that's when things start to die. And it's like, well, we've been living with this rewrite for like, you know, we're halfway between for the last few years. um That's kind of the problem. The other way around, I found is much, more much more successful. And that's much harder at the beginning. But at the beginning is where all the enthusiasm is. But you kind of like go, OK,
00:18:53
Speaker
if we were to somehow make it so that we could wrap our new app and then insert our old app into it and it's like oh well how do you do that and it's hard and you got to figure it out and there's various patterns various different things that you can do but if you create a new app and then slot your old app into it then you start doing these like parallel slices like okay we have this one feature that goes all the way here maybe it's the website maybe it's like ah you know if you're doing like micro front ends or something there's Things you do that whole thing in like one big like, okay We we push we push we push. Yeah, we got it done You can now do this all the way from this, you know Whatever it is purchase all the way to you know it getting sold and put in the database boom that's done and it's all in the new app and Then you do that again You figure out a vertical slice that you can do and you do this whole vertical slice all the way from the end You're like, oh, hey, we've done everything and now everything in this little, you know feature Whatever it is isn't the new app now and by doing that
00:19:48
Speaker
the app actually gets easier and easier to do the rewrite as you move on, as opposed to the other way where it gets harder and harder usually because people start pushing the complexity up. You have to sort of deal with the complexity up front and then it gets easier and easier until you've got these last few strands and then get rid of those. Everyone celebrates and you move on. And that's the only way I found the rewrite be successful, is figuring out that really hard stuff up front while the enthusia enthusiasm is there. Yeah. in in it It almost has to be completely that way too, where you're taking those whole vertical slices, because if you end up with some kind of hybrid where, Oh yeah, yeah, we've wrapped the old application so that we can start using the string repair, just strangle out features and, and, and pull these vertical slices through as new system components. But they leave that backend pieces, but we'll just call the old system to get like our data, that whole data layer is still just all going to be the responsibility of that old system in the backend.
00:20:47
Speaker
And so you get, you know, like this weird kind of new shine finish on the outside, but the interior of it is still, you know, tore up and ran it out. And, and so it looks good on the outside, but the inside is still the same kind of junk that you had before. And then it's, it's kind of that leave it, it leans towards that leaf pattern that we're talking about where Then those things that are touching that legacy system and going all the way through, it's like, whoa, now we can't really rewrite this because it's, it's become a dependency of our new system. We've integrated tightly to it. So because we had to, because it wasn't written to be flexible. And then it just kind of lives on as this blob at the center of your shiny candy coating.
00:21:40
Speaker
Yeah. And you're definitely going to lead to the, ah, it works. Don't touch it then because nobody's going to go, going to go do that later. It's going to become this thing that drags on and like, nobody tackles it. It's like, Oh, that's in the way we we call it technical debt. And it's just, we'll do it someday in the future. And then it will never get done. So yeah, I agree with that a hundred percent.
00:21:59
Speaker
Another thing that people will often lack doing when they do a big rewrite too is preparing for the rewrite. Because there's a lot of stuff that you can do in your current system to be like, well, okay, what are we thinking? you know How are we going to tackle this new rewrite? what's what's What's the optimal that we're going for? And then let's try and refactor what we currently have to somewhat like that, at least, like we and we may not be able to get too far. But if we just start breaking off, well, we know this is going to be a component now and this is going to be component now, but it's all mashed together currently. Maybe separate that before you start the rewrite, maybe make that part of the like, hey, we're going to before we actually start changing languages or changing frameworks or whatever it is, let's just do that because we know it's better anyway. And then let's do some other part, you know, figure out, oh, well, this piece, maybe we we leave that alone. So we're just going to break that off, you know, that kind of stuff.
00:22:44
Speaker
figure it out and and do some refactoring and preparing for the rewrite. Cause then it's way easier. You're not like trying to fit as much into the system. You're like, Oh, we've already got these nice lines that we can sort of hit when we're doing this rewrite. And then we can sort of plan accordingly. And depending on how old the system is, if it wasn't developed with good practices in the beginning, uh, and this is something I used to call code rescue. Um, you know, you, you know, kind of from that perspective of like a first responder, you're going in.
00:23:14
Speaker
to put out this fire that's in this, the belly of this code. And one of the first things that any first responder or that you teach you like in in first ah type of thing is like assess your environment and don't become another victim. Right. And that was kind of one of those things. it's Like if you're going to touch this code, you need to make sure that the code you're writing isn't as bad as the code that you're trying to fix.
00:23:43
Speaker
So, you know, you put in these safety barriers of testing and make sure you you understand what it is that piece of code is doing via tests so that you have that, that safety net, that structure, that lifeline that you can give a tug on to say, no, okay. Yeah, that didn't work because my tests don't pass anymore. And, um, you know, those, those were the kinds of techniques that we would use to go in, to make sure that we could break this out safely and start doing those.
00:24:13
Speaker
Okay. That's what your practice, you know, let's not do a single, singleton pattern inside a spring because it's, it's double, it's, you know, double duty. Um, you don't need it. So we start refactoring that out, but oh, this is coupled to this other class. That's also done as a singleton is in its static space and blah, blah, blah. he' trying on and mesh And sometimes you have to go back and restart three or four times to try to untangle the spaghetti mess that's in there.
00:24:42
Speaker
And sometimes you're like, I spent two weeks on this and I am no closer to being done than I was before. I'm going to leave the test in place and let the building burn right here. it's It's actually another another good point you brought up that I kind of forgot about, but um one problem again that people often have is they'll be like, well, we actually have good test coverage on this one. So were we we can use that as we as we ah rebuild this whole thing, rewrite it in the new, you know,
00:25:12
Speaker
And it's like, well, maybe rethink that because often, at least in my experience, and this might be completely anecdotal, but often I'll find that the tests are bad and the tests are usually doing things like testing implementation. The tests are assuming a certain breakdown. So I almost find it's better to be like, yeah, yeah, I know we have tests, but I'm going to start really high level, you know, whatever your closest to end to end or integration is like these really high level. I want to see it do this. It's going to keep doing that. That's all I'm going to worry about. You know, few high level tests.
00:25:42
Speaker
and then start breaking in and if oh now we've wrecked all the other tests delete them or skip them or whatever you need to do to keep moving this on and then add more tests add tests to your to your code that you've rewritten now the new code the new whatever and kind of go from top down with the tests to like out going from high level to like your unit tests you know rather than like oh we've got our unit tests and we're writing out kind of do the reverse when you're doing the rewrite because Yeah, off like I said, you're you're going to get mired down in trying to make these old tests pass. And I don't think that's a good ah good way to actually get it done. And I would even say, if you can, and you know so depending on what industry you're working in and depending on what you're working on,
00:26:22
Speaker
But if you can, don't worry about the tests too much at first. Like if you can get away with like, yeah, we've got some tests to make sure that it's not broken, but we it's okay if we ship a little bug here and there that we can fix quickly. That's great because then you don't have to like,
00:26:38
Speaker
and And some industries can't do that, but that's great. Because then you can sort of like, yeah, yeah, we're gonna we're just going to turn off swaths of tests as we kind of break this down. And then once it's done, once the rewrite's done, we can have another task to like, OK, let's really get the test coverage back up. That's just a better way of getting it done. It has little to do with safety and more to do with just the momentum that you don't want to lose that early momentum of a big rewrite.
00:27:01
Speaker
Yeah. One of the yeah other prep things that I've, i've sorry. and One of the other prep things I found when we're, you're getting ready to do a rewrite is a lot of those older systems, they really have no idea what's being used at all. So when you are having to decide what features do we want to keep, what do we want to throw away inserting some sort of use.
00:27:23
Speaker
usability, observ observability into the system to understand like what what is actually going on here? What what features are people using? what What are people doing with this system today? How are they using it today? Trying to get some of that in place and and get some data to help you guide like, well, I think we should keep this. like whats Let's figure it out. Let's let's understand um what what these people are actually doing with this current system.
00:27:46
Speaker
And yes, I did pick up on some of your Canadian roots there, Adam. You said figure it out earlier. You said figure it out. Yeah. Um, I mean, I said all the boot. At least he's not saying process. Process. processing It's the process. Yeah. Yeah. Get your process. I do want to come back to something that I. Sorry about being Canadian. but sorry no that's right Sorry. Sorry about it.
00:28:13
Speaker
I do want to go back to something you said, but though I thought was interesting and it kind of, you know, I was listening to you all talk somewhat and in my mind went off on a tangent.
Human Factors in Software Engineering
00:28:21
Speaker
I'm sitting here thinking about it. Like you mentioned about like you're basically like, um,
00:28:29
Speaker
taking advantage of the enthusiasm early on on the rewrite and like doing the process. What might like if an engineer, we're looking at it and saying, well, obviously you need to do it this way and build it from the bottom up, right? That might be the logical technological best way to do it or engineering best way to do it. But you're taking the human side. And that's an interesting thing that I think the the I think the the industry has embraced maybe over the last 10, 15 years or something. I'm thinking of like Conway's law and and principles like that, but we're actually thinking of the human part of of software engineering and not just what is the absolute best technical approach because you we've realized that you have to take that. you know There are humans involved here and we have to to think about that and consider that. so I thought thought that was just an interesting thing that made my mind go on a little tangent, so thanks for that. so
00:29:13
Speaker
You've opened up a door in my brain that now I'm going to have to like you know walk into and look around a little while. So thank you. And that and that kind of leads to the point that I i was going to make as well, is that it's not about the technology. And the kind of tests that you want to be writing for these kinds of things are the, what is the value that this system is currently providing? Because when you are When you are doing a rewrite, you are replacing something that is currently doing a function in production to some level of adequacy, right? And you cannot lose that. You can't go backwards to go forwards a lot of times. And so you have to have those things in place to go, okay, what value is the system actually providing?
00:29:56
Speaker
And you almost have to value drive it from a, okay, this is, this is something of value we get from the system. And let's take that value story in and let's have a test for that. Can, you know, like an acceptance test type of, of thinking of, uh, you know, this is when we supply A and B, we get C out of this. And whatever the implementation is, who cares, right?
00:30:21
Speaker
I just need to make sure when I supply A and B I get C out so that I am getting the same value that I got out of the system yesterday. Yeah. And you know, often a rewrite will come with a redesign, dude. They'll just be like, Hey, let's do it both together. And so you should be doing things that like your normal UX patterns, you should be doing things like, Hey, we're going to use your test stuff. We're going to like, actually make sure that this is improving our conversions, whatever you're doing, whatever you're measuring, rather than like getting rid of it.
00:30:48
Speaker
That's one thing i yeah ah we had talked about before the show, but is just like, for some reason, and this is totally maybe a a switch of topic, but for some reason, it's like UX doesn't matter when it comes to to coders or something. it's It's this strange thing that we run into where, um not that the UX doesn't matter in the in the product, like, oh yeah, the product we're building, but more like the tools the developers are using. It's like, oh, well, they're developers, they can figure it out. It's like, well, is that is that right? Like there's a strong lack of user experience fundamentals in coding tools, you know, in development tools. And I don't understand why. And it feels it feels like it just comes from this legacy of like, oh, well, they're technical people, they'll figure it out. But that's never good enough. You know what I mean? Like there's there is there is in in web development right now, there's kind of like these major frameworks that react and and
00:31:41
Speaker
the Angular Svelte. And I find only one of them, Svelte, I feel like, kind of takes the like user experience approach. It's like, well, how are developers going to use this? And then they kind of figure it out. Rather than, what can we do? OK, now let's expose what we can do to everybody. And it's it's this mindset change that I think is desperately needed in the industry.
Critique of Developer Tools
00:32:04
Speaker
Like, if you look at any tutorial,
00:32:06
Speaker
that I see these like web development tutorials. They start with, OK, well, let's let's make the database schemas. Let's figure out what we're going to need. And then we're going to layer on an API, and then we'll put our front end on that API. And I'm always like, no, don't don't do that. Do the other way. like Figure out what the user can do. Move into what middle APIs you need, and then what storage you need.
00:32:27
Speaker
So the whole industry is kind of pervasive with this like, oh, technical as people can figure it out. It's fine. And I don't like that at all. It's it's strange to me. And I feel like we're about to hit this big um moment, I think, in Web Tools because there's Right now, it's it's actually pretty awful. In web development, the more popular you are, the better people just assume you are. There's this thing like, oh, you need a logo, you need a cool website, you need to have a backing company. It's like no kind of moved away from the, hey, what's the technically best solution? And just to be like, well, what's more popular? Because there's there's quite a few examples, actually, of like stuff that is just objectively better than other stuff, but it isn't used because the the popular one is still around. Which you know you could debate, well, whether it's popular actually does matter. And and you could debate that.
00:33:14
Speaker
but I feel like it's primed now for like, hey. What tools are just going to be the easiest to use, but also give you the best experience? Because there's always the problem. It's like, well, easy doesn't mean simple. And there's a whole difference between that. And you want to have the flexibility and the control, but you also want to have things you know ah quick and easy to do. And there's' it's as if there's a dichotomy there. But I don't think there actually is. I think there's like, yeah, you could have both. And somebody just needs to design it. What we need is designers to come and design our code and our tools. That's what we need.
00:33:48
Speaker
Yeah. And I've seen, I've seen some, some tools that actually took a very interesting and easier approach to applying complex logic, um, for solutioning in a couple of different industries. One of them was when I was looking at teaching my kids to program because, you know, Hey, do what dad does.
00:34:15
Speaker
Um, and one, there's this language out there called scratch, um, that uses like block formations for control structures in loops and things like that. This is brilliant because we type this in time and time and time over, over again, as we're developing solutions and they're the base building blocks of what a program is.
00:34:37
Speaker
Why isn't it just slapped together with blocks like that and make it simple? Um, and also then when I was working with chip testing software.
00:34:50
Speaker
therere Their testing structures were also, ah one ah one of the interfaces, I don't remember which one it was, but one of them also had like testing nodes that were drag and drop and organized and you plugged in your different attributes into the blocks. and but So you could see your testing path um on ah on a display. And I'm like, these are really cool and really easy to understand instead of looking at a series of just text and numbers on a screen and trying to figuring out what is this doing? And I thought that was, um, really interesting, um, approaches to the problem of we have a very complex structure, but we, we put a nice UI in front of it so that you can basically gooey edit your programs and your streams and your, in your thought consciousness and, and yeah.
00:35:47
Speaker
It was a beautiful, beautiful thing. And it just seems to have died away. Yeah. Well, I think the developer knee jerk reaction might be what, you know, i I could call the Dreamweaver effect where they're like, Oh, well, if it's got a nice UI and it's drag and drop, I won't have the control I need.
00:36:03
Speaker
And it's like, i'll I'll have to, whatever. It's just easier for me to write code. And I feel like this is this is where designers need to come in. Because there's this like very fundamental design position position right where it's like, yeah, you make the 80% that they're going to do upfront and easy. And then when they need to get into that 20% that is not the upfront and easy stuff that we know they're going to need,
00:36:22
Speaker
OK, you allow them to do it, but it's a little bit harder. It's a little bit deeper. They need to go a little bit further. They need to maybe open some. And that's it. That's all you need. So all these like drag and drop tools. Absolutely. People are like, oh, they have this. Oh, I remember all these gooey tools that won't let me do what I need to do. And I'm just fighting the tools all the time. But if we had more user testing, essentially like when was the last time you ever heard of like a technology for dev developers being user tested? Like, oh, we sent this out to 100 developers. Here's the feedback we got. Like it just doesn't happen.
00:36:51
Speaker
Maybe it does, but I haven't heard of it. But you could get into that, like, oh, yes, well, this was great up till this point. Oh, well, maybe if we added, you know, the ability to just hop this open and write your own code for these particular parts, well, that would be perfect. You know what I mean? Like, it's just these such easy wins, I think, that we could get to drastically improve productivity for developers.
00:37:14
Speaker
And meanwhile, we're focusing on chat GPT, which I don't think is a good productivity boost. There's a lot of stuff ah with these chat GPT things happening right now where it's like, oh yeah, but I just type what I want and it like codes for me, but it never really does. And like I feel like most senior developers are like, yeah, but then I spend just as much time debugging what chat GPT wrote like than I did would have if I had just written it myself. So I feel like there's like Again, let's user test that. Let's see how they're doing. And maybe, you know, GitHub or whoever put up co-pilot, maybe they did. Maybe they tried it for a while, but I'm just, I'm not sure they did. I feel like people just think, Hey, there's this cool thing. I'm sure developers will use it because it's cool and it does stuff. I just want to see more fundamentals of design being brought into the the whole development tool. Yeah, I think.
00:38:03
Speaker
I think trusting your programs to AI is, is folly, like you said. Um, but you could use it to say, you know, what kind of, what kind of tests should I have for this piece of code? Or if you get, you get stuck in a piece of code, it's like, what is this code doing? And, you know, kind of that is like a research partner type of thing. It's very, it's very good analysis of, of data, right? Cause that's what it's designed to do, analyze data and come out and produce an outcome from it.
00:38:32
Speaker
So, you know, doing, using it as like a research assistant in, in your development process, I think is a really good use of the tool. Um, but yeah, I would not trust AI to write my code with some of the things I've seen. You know, especially if you've looked at any of the AI generated pictures that have an extra arm coming out of the head or whatever, you know, ah yeah nobody Nobody wants code that like, I don't know, sometimes it fails, but we don't really know why. So we just ignore those ones, like predictability. We just we just regenerate those. Yeah, we just don't worry about that. That's that's fine. Just hit refresh.
00:39:07
Speaker
um my What was I gonna say about that? Yeah, and you're right. there is There is good ways, definitely research, definitely like, oh, hey, I wanna learn something. But also that's kinda weird too, right? Because it's reliant on sorta knowing when it's if it's gonna lie to you. Because you know as maybe we don't know, but yeah, chat, GPD stuff, all these LLMs, they lie to you sometimes, because they're just trying to guess the best text they think you want from your input.
00:39:35
Speaker
And it's like, yeah, so you kind of have to have this base knowledge of, oh yeah, no, that's wrong. Like, oh yeah, you know, that's ah whatever they just said there, that's actually a complete fabrication. Don't listen to that. And so it's, it's, it's a weird double edged sword when you use it for like learning and research. Yeah. And now I'm having to like.
00:39:55
Speaker
scratch my idea of always generating all my applications from a database schema thing. And I thought that was a great way to do it. You guys just talked me out of it. That's one thing I wonder if it would be amazing though, um is these LLMs is just the, ah you know, and I know there's ah quite a few products actually right now, but just being able to say, I have this giant data set, you know, across data lakes and data things, and I want this. And just being able to say it and in plain English, and then it figures out how to query all that for you.
00:40:24
Speaker
that would be a pretty amazing tool that I could actually see, oh, LLMs would be good for that. Because you'd just be able to like figure out, you know, I wanna see a graph that has this compared to this, compared to this, and give me a table so that I can run the numbers differently if I want. And it could do that, I'd be like, well, that's how we do all interfaces for for graphing data now. Just all of them, because that's amazing. Let the analysts just ask for what they want directly.
00:40:51
Speaker
Yeah, and I've been probably in use cases for that. Yeah. And I was going to say, I think you could probably get away with that in a relational or a graph database. I don't think you could do it with a, with a, a NoSQL database though. Well, I couldn't, but maybe a robot could. I just don't know. I've been trying to figure out what is enough information.
00:41:17
Speaker
Well, that's what I'm trying and to figure out. like What is that even called? Because we've heard we've heard a lot of use cases from clients you know basically saying, like You know, we spent a lot of time ah when when what one of our people wants to understand stuff about data. we We bring in either a DBA or somebody to write me a new report to answer that question. Every single time we have to have somebody go write a brand new report. Whereas if I had chat GPT that I could use that, but it's not, I don't think it's retrieval, augmented generation rag, right? It's almost like the reverse of that. It's like generation augmented retrieval. You're saying, Hey,
00:41:53
Speaker
you generator figure out the query that I need to write that goes and gets me the things that I need to have. like It's like flipping it on its head. It's like a reverse home logo. Get your patent in there quick because you gotta to and and get that
Progressive Enhancement in Web Development
00:42:09
Speaker
term out there. oh with that black host Get that term out there. This podcast brought to you by Guard.io.
00:42:17
Speaker
are gar That's just fun to say too. We have a feed more and there have a talk like a pirate day sale going on. gar that reminds Do you know what a you know what a pirate's favorite letter is? I'm going to guess R. You might think it's R, which is a good guess, but it's true love be the C.
00:42:42
Speaker
well paid sir Well played hook, line and sinker. sink Emphasis on the hook. Speaking of hooks, I thought and I love really bad segues.
00:42:58
Speaker
Speaking of hooks, you you talked about, we we we got together before this episode and we talked about, you know, what are some of the things we get tired about? You brought up a topic that i I honestly had never heard of and I was, and you know, I've been doing this a long time and I had not heard of it. um Progressive enhancement, you kind of talked about that and I kind of, you know, the the in my brain is like, oh, you're just progressively making things, you know, better, which would be like iterative development. but That's not exactly what it is. Can you maybe explain that a little bit better? Yeah. Yeah. So, and you know, maybe this is very, well, it shouldn't be, but maybe it's a very web development term. But like about 10 years ago, I feel like everyone was talking about progressive enhancement and the, the, maybe the.
00:43:39
Speaker
the other side of this same coin would be like graceful degradation, where the idea is for whatever and and it's more important in web maybe than in other platforms, because it's no matter what device you're on, no matter what ah limitations you have, you're going to have this work for the main part. And so you make the most base thing that will work on the most browsers, the most, you know, devices, that this will possibly just work, then you say, okay, now we test for features, we test for you know what versions we were able to do or whatever, and we enhance. And so the idea is that if you're doing graceful degradation, the idea would be that we made it, but then we also put in some some stuff to be like, oh, hey, ah make sure this works on on older crap.
00:44:29
Speaker
And progressive enhancement is we make the thing that's going to work everywhere first, and then we start enhancing it to build it up to the thing we actually want on the latest browsers or the latest devices.
00:44:41
Speaker
And it's a huge thing that was around 10 years ago, decade ago, everyone was talking about like, you couldn't put this out. And then I feel like the the spas, the single page apps in web development sort of took over. And this is where these frameworks like Angular and React were. And doing graceful degradation in that medium was, or sorry, not graceful degradation, doing progressive enhancement in that medium was very hard. And so the conversations just stopped.
00:45:05
Speaker
because it's all in this like, oh, everything's done in your client. So if it doesn't work, well, it just doesn't work. Like, oh, you have an old browser? and just You get a white screen or you get this. and and there And there were weird justifications like, yeah, but who cares? You know he hear this a lot with like, oh, should it work without JavaScript on? And they're like, well, who turns off JavaScript? And then there's a lot of articles you can find about like, well, it's more than you think because It's you know people going through a train. It's people in certain situations, people out, whatever. Often there's what they call Wi-Fi, where you are you are connected. But for some reason, it's not giving you all the the files that your browser is requesting these things. And so you'll actually just have like one JavaScript file that didn't load, that kind of stuff. So there's a lot of things that can happen. So it's like, yeah, you should maybe worry about that. And there's a large enough percentage of users that this will be happening to that like, actually, it's it's kind of a big deal.
00:45:57
Speaker
And then we have this like big swing from spas and everything happening on the client in web development to like the server again, everything's moving back to the server. There's these things that like, you know, always secular. It's like, oh, hey, we go server, we go client, we go server, we go client. um There's other different things that kind of happen in development. But we're currently on this big swing to the server again. That's where the pendulum has gone. But I don't hear anybody really talking about progressive enhancement now.
00:46:23
Speaker
And I'm like, but why not? This was the thing that kind of stopped it. I felt was like doing everything on the client. We're back on the server. We could be doing this. Why isn't everybody talking about it again? Cause it's rather important, but I'm not hearing it.
00:46:36
Speaker
so That explanation of progressive and how enhancement actually like play out. I kind of realized it bad with a lot there, but where it's not just like, Oh, we, we make a feature and then we keep adding to the feature. It's literally about like, what are the devices this is going to run capable of? And we try and make sure that the root of it, you know,
00:46:54
Speaker
If it's content, OK, they can read the content at least. If it's videos, it's like, well, they might get a link to download the video if they can't play video on their device. If it's a, you know, CSS stuff like, well, worst case scenario, everything looks OK. It doesn't look right, but it's enough that they can function and they can like, you know, submit a form and stuff happens.
00:47:14
Speaker
but The way they expect is a good analogy. Maybe like, um, I know this isn't what you're talking about, but like, help me frame my brain here. Like video players, if it notices that my bandwidth can support full HD or 4k, it will go ahead and upgrade your video experience to be the best experience that your certain situation, whether it is your machine or your, your, your.
00:47:37
Speaker
internet provider or whatever can provide for you is that the idea is kind of like instead of dumbing down when you realize, oh, this this user situation can't support the best of the best of the best. Let me dumb down pieces of it. It's I'm smarting up instead of dumbing down or enhancing exactly. and Yeah, no, I think that's that's exactly it. Because like the canonical um example, real life example is like the escalator where they say,
00:48:01
Speaker
Oh, well, you know you know, an escalator when it's broken, hey, it's still stairs, but that's kind of more for graceful degradation in my mind. It's cause yeah, yeah. But you built an escalator, you didn't build stairs and then make them move. You built an escalator. That's, that's graceful degradation, but you're exactly right. What it is, is it's more about like, well, we built the thing first and then we started to enhance what it could do to get to where we want it based on device features and what it can do. So yeah, your example is better than the canonical one.
00:48:31
Speaker
We had to think a lot about this in TechEd when I worked in that space because students came from all different kinds of universities, some that had really old infrastructures that couldn't support you know video streaming. So we had to provide transcripts and that was that that that graceful degradation part. But then on other ones, we actually were able to do some of this um progressive enhancement where Not only did you get the text, but you had a read speaker on top of it. And it was the original intent of that was for accessibility, because not everybody, you know, for the visually impaired, you know, the reading experience, isn't that great. But it turns out other students were using it because it was great. I can put on my headphones and just have it read it to me. It's story time for, for my homework. And we're like, Oh yeah.
00:49:29
Speaker
that works out really well. And now it's kind of like a staple feature because of the fact that is it's like, this is, this is one of those progressive enhancements. Not only do you get the text, if it's available, you can have it read to you as well. And, you know, the next thing is going to be, you know, AI will draw you a TV show out of it, you know, type of thing, you know, but AI magic. Yep.
00:49:55
Speaker
you Well, and i yeah, Aaron, you bring up an interesting, so could could one of the reasons, and I don't know that it necessarily plays and plays into or comes into play in general, but in our case, because Aaron and I worked together at Cengage Learning and we we were in ed tech.
00:50:09
Speaker
um One of the, one of the aspects was you had to be very careful not to give one student an unfair advantage when it comes to assessments. Cause they're kind of competing for grades. They can be grading on a curve. you You can't give one student an unfair advantage by giving them a better experience that makes it more easy for them to learn. So you had to be really careful of doing those sort of things where you're, where you're enhancing that experience for one user because they've got a faster computer versus the other where they do not. I don't, is that, I don't know if that,
00:50:39
Speaker
specific aspect comes into play in the general sense or what do you think maybe on that progress is that maybe some of the reason why people didn't do it o No, I. And there the reason I would say that is that the people who aren't doing progressive enhancement aren't also doing ah like lowest common denominator. They're not doing like, hey, this will work for everybody. They're doing stuff that will absolutely break for people on on less devices. So it would be even worse than the situation there where, yes, some students you can actually like do your tests and do your learning online. Oh, but you with your older phone? No, you can't at all. You'll just have to figure it out.
00:51:18
Speaker
Go, go borrow one from a friend or, you know, get a job and come back when you have money. You know, that kind of thing. Like, it's just such a like it's a way worse problem, I think. If I'm getting through credit is what's coming. Yeah, yeah. Going to the lowest common denominator would be like, oh, well, that's you don't have to do that. You could progressively enhance. um But no, what's what's actually happening, I think more often is like, no, it just completely breaks. Yeah, it's like, very take load and I don't get it on. and Yeah.
00:51:47
Speaker
That's like trying to pull out an um iPad and installing a new app on it. like um No. You can't do that on this. You might as well use that as a paperweight right now, because we're not gonna run anything on that anymore. And like right now with web development, React Server Components is a big thing, and Svelte has this streaming and whatever. It's like we're primed to do this now. We can actually have these great experiences, except React Server Components, the most popular thing in web development right now, I think that people are talking about, and people are whatever,
00:52:21
Speaker
It needs client-side JavaScript to work. and And I know that sounds weird because it's like, but doesn't it run on the server? Yeah, it does, but to compare, if not to get too technical, but to differentiate it from just like server-side rendering, which is one thing, but these components, one of the main things is that you can stream updates, but those streaming updates will not work without client-side JavaScript. Therefore, you cannot do progressive enhancement. Therefore, what's the point? i don't Well, not what's the point, but why isn't this prioritized? Might be a better way to say that.
00:52:52
Speaker
It's interesting how that pendulum swung, right? So, you know, you remember back in the oldda green screen days, right? it was the machine itself was doing all the, and and then we just had dumb
Web Development Paradigms
00:53:01
Speaker
terminals, right? And then it was like, well, forget that, that's that's not a good experience. Well, we need fat clients, right? And we started writing all these desktop apps. And then it was like, oh, no, no, no, we need to put everything back on the server and let server side render and just spit out HTML. And that worked for a while. And then it went all server size, you know, single page app and um all Ajax and all of that fun stuff. it' It's so funny how that just goes back and forth. And now we're back emphasizing server side rendering again. So,
00:53:26
Speaker
I can't wait for the next iteration of the of the smart front end that we that oh yeah you can almost you can almost feel like i think we may be at the apex of the server side they can almost feel it swinging back now too but yeah absolutely though one would say maybe we're not really swinging back and forth as much as kind of like moving in a spiral forward it's like yeah but things are still getting better all the time we do go like this way and that way but things are still always getting better like it's It's better than it was no matter what. So yeah, it's like a weird spiral. Like I don't know if you've ever seen the solar system moving through space thing. It's like the solar system doesn't move through space in a flat plane. It moves through space like a big spiraling thing rushing towards something. So yeah, same idea. Yeah, I guess. I guess you're right. Maybe macOS is better than Vax. Maybe. Right. Like maybe that's true. My old Vax screen. Yeah. Yeah.
00:54:17
Speaker
All right. So we have a new segment that, uh, we'd like to debut this, uh, this episode and we, we, you know, there's, there's all these, like, are you going to, you know, do you like this or not kind of things? There's plenty of them, uh, you know, the kids would say pass or smash kind of thing. Right. Um, so we did an an IT or technology take on it. We call it shipper skip.
00:54:42
Speaker
And we can insert the ship or skip jingle right here. Uh, if we ever come up with it, I don't know. Skip, skip, skip everybody. We got to tell us if you ship or skip. And that should be our first ship under skip it topic is I love it. I would just say as is, I agree. Ship it. So.
00:55:02
Speaker
So anyway, the idea is I like this or I don't like this. We have a few that we've kind of jotted down. Aaron, do you want to start? And we'll just kind of work through the list back and forth, kind of ping pong it? Sure. Let's start with a TypeScript.
00:55:19
Speaker
Oh, ship it, ship it. And here's the thing, I get why people don't like TypeScript. I understand it. it's It's added complexity to a beautifully simple language that's completely whatever. But the the difference is when you're working as a team,
00:55:34
Speaker
And you have at least a few people who really know TypeScript well, because you know I'll admit, when you have a bunch of people who are new to TypeScript trying to beat do TypeScript, it can feel awful. When you have a few people who really know what they're doing to guide the others, it can save you from a lot of problems, like a lot of problems, a lot of problems with You know, oh, I can't believe this bug happened. Oh, I can't believe, you know, we never caught this before. It's so weird. um Why are we doing the same data and reproducing it a bunch of times? Well, you'll find all these two things. So I'm absolutely a typescript ship it. It's and I do feel like it's taken over like JavaScript. I think there's probably more typescript projects than there are JavaScript projects when it comes to like commercial products, at least. But you earn I.
00:56:20
Speaker
I am a fan of the write it once and use it everywhere philosophy. Um, that, you know, it was like kind of the basis for TypeScript. Um, and I believe in enhancing TypeScript to cover the edge cases that were maybe it didn't handle something natively. Um, instead of going, Oh, well, it doesn't do this. So I'm just going to, you know, write this native over here and then write this native over there.
00:56:48
Speaker
Uh, because we don't live in a single platform world and, um, you know, that, that, um, portability, I think is, is worth it. So I'm, I'm a ship it for TypeScript.
00:57:03
Speaker
Yeah, and I mean from that point of view, I wanna step back and say like, absolutely ship it because I was just having this discussion yesterday with a bunch of people. TypeScript and JavaScript, I guess, and TypeScript, therefore, is one of those weird things where you can do anything. You can do anything. everything. You can do A.I. stuff. You can do device, you know, embedded in device stuff. You can do robots. You can do everything. You may not be the most like performance. So, you know, when you've got you, oh, we're going to parse through this to gig file, whatever. Maybe it's not the right choice every time, but you can do everything with it. So from that point of view, absolutely ship it. I'm I'm ship it on this one as well. And this comes from a Java guy, so no surprise, right?
00:57:48
Speaker
um But I think it's the the thing that people lose sight of honestly when it comes to development is everybody tries to optimize for like, how can I write the smallest number of characters? We're trying to optimize for the right scenario as opposed to the maintain scenario. And for me, TypeScript, yes, absolutely. It is a beautiful language. I would agree. I love TypeScript as a language. However,
00:58:09
Speaker
If i'm production is down, it's four in the morning, I haven't had any coffee, my my CTO is yelling at me, I'm in trouble unless I get, you know we're losing millions of dollars in sales unless I get this code back up and running and I open up TypeScript, or i open up JavaScript versus TypeScript, I think I can more quickly reorient myself in a TypeScript environment than I could in a JavaScript. That's how I think of it in myself. I i think people try to emphasize too much on the,
00:58:35
Speaker
the right side of software engineering, engineering W R I T E right side of software engineering, as opposed to the enhancement and maintenance maintenance side. Cause you maintain software much, much more than you initially write it and I'll shut up now. All right. So let's go ship or skip design systems. Should I go first again? Sure.
00:58:58
Speaker
All right. Absolutely. um Especially when we consider like the design system isn't just like, you know, your component library or whatever it's going to be. Your design system is the language and the concepts that you're going to use where the designers and the programmers both can come together and be like, oh, we understand what this means. We're going to have this, you know, domain language to understand that, oh, this is this and our, you know, whatever it is. It's not just about colors and branding and whatever it's about.
00:59:26
Speaker
How do we communicate with each other better? And I think it's all for it, all for design systems. I don't know that I'd have much more to add. out I like the idea of design systems myself. So I'm Chippet, Ryu, Aaron.
00:59:41
Speaker
Yeah, i I'm, I'm stupid. I've actually, I've been taken the idea of design systems into like requirements gathering and stuff like that to use some of those, the same kind of concepts of, of visualizing and storytelling in order to um to define requirements to a development team so that they understand why they're doing what they're doing and not just what they're doing.
01:00:06
Speaker
So yeah yeah, the only time i've I've run into, yeah, the only time I've run into where there, I would couch my statement with something. So I have seen ah scenarios where we've tried to come up with like a standard set of components, right? That everyone should be using for everything. That's usually design systems usually involve here, the canonical component library.
01:00:23
Speaker
if, when there are new use cases, they kind of like try to shoehorn every little case into the common component libraries. And it becomes just as like maintenance nightmare, because there's all these ifs, there's the switches that you add. I'm thinking back to like, you know, back in the ed ed tech days, right? There's always these question types that we would have to support from an assessment perspective. But you would they would try to like put all these little one off little scenarios like, oh, I'd really like, you know, the the the answers to read you know sideways instead of up you know up and down right and so you'd have to have all these little if statements and and the code just became just ugly over time there's all these like it becomes a combinatorious explosion of options that you could have and there's no way to test everything all this so that would be the only thing i'd say to be careful of it's it's usually easier to to just copy something and and use it and adapt it as opposed to trying to cram everything into that you're kind of your canonical your common library
01:01:21
Speaker
All right, next one, A.A. Ron. So this is next one is Jamstack. Is this a ah stack of like different flavored jams? Let me talk stack about Jamstack. Sweet. So I will say as a huge Jamstack proponent,
01:01:45
Speaker
I will absolutely say, skip it. And the reason is this, JAMstack he is dead. So to get into what JAMstack was, JAMstack was, well, okay, actually, so JAMstack is kind of funny because you have to face facts jamstack ended up changing over time because it was an idea they didn't want to acknowledge the idea it had to change and eventually it died and honestly i think i got an email of a couple months ago from like the person who had like been pushing jamstack and the company netlify that had been
01:02:19
Speaker
like trying to like get that word into everybody's ah lexicon or whatever and it was like yeah so we're not gonna do jamstack anymore we're not gonna call it jamstack jamstack is officially dead so jamstack what it was was ah static sites got a bad name a long time ago but it was a pretty cool way to make um It was a pretty cool way to make applications you could do. This is the single page app era where you could do. Hey, I'm going to like put everything on the client. These are the thick clients and I'm going to call different APIs. So it's going to be JavaScript APIs and markup jam jam. JavaScript, APIs, and markup. And that's what we're going to ship. And it's like, well, isn't that just static? But they didn't like the word static. And the reason they didn't like the word static is because people would be like static. Well, ours does a bunch of stuff dynamic. We can't do a static app. That doesn't make any sense. It's like, well, it's not static. Just the assets are static. Just the like literal files don't change. That's the only part we don't. We just don't have to have like a runtime running. And it's like, no, no, we we can't do that. It's static. We do lots of code.
01:03:20
Speaker
So they tried, you know, these companies in particular, there were a few of them, tried to like rebrand that like, Hey, this isn't static. This is Jamstack, JavaScript, API markup. Cool. Jamstack and full client apps aren't unreasonable. You know, this is how apps work. Like, ah like, ah sorry, like native apps work on your iPhone or Android is a full client. It's all in your, on your device right now. That's how it works. You download it to your device. It runs in your device. It can save things in your device. It can do things in your device.
01:03:49
Speaker
and it doesn't necessarily have to go to a server, but it can go to a server when it needs to, it uses APIs to do that. That's a really common ah architecture, whatever you want to call it, for apps. This is, Jamstack was just that, except with one thing, because it was all browser-based technologies.
01:04:06
Speaker
browsers don't have the ability to do any sort of like ah safe savings, so any sort of cryptographic like storage. And so without that, everything has to like, oh, well, you can do so a certain amount on the client, but then you always have to kind of fall back to these APIs. You always have to end up doing something. And then it was like, okay, well, you got to this point where You know, the browsers have this very unique problem where the size of the files that you're downloading actually affects the performance because it has to load them first and then execute them. And the execution actually is is dependent on the size too, just by the way, JavaScript works. um And so bigger apps start to be a problem. And it and it has this weird connotation thing because ah you expect to go to a website, it downloads very fast and I can immediately start using the app as opposed to like an app.
01:04:55
Speaker
which you go to the app store, you hit install, it takes 20 seconds to download. You're fine with that. and You open up the app and you start using it. That would be fine if that's how web works. But if you open up a website and 20 seconds go by and nothing's happening, you just go, ah, and you go away because it's broken. So Jamstack had these two main problems. Couldn't store stuff safely.
01:05:13
Speaker
Loading had to be taken into account. and There's all these kind of things. And eventually people started going, hey, you know, if you server side render stuff, then ah it just it works better. You get better performance off the off the hop at least. And it was like, yeah. And they're like, oh, and because you have to do all your crypto storage kind of stuff on the server anyway, we can just do it closer to there. And and this is where the server movement started like the pendulum swinging back to that.
01:05:35
Speaker
And it was like, okay, well, let's rename what JAMstack means. And they literally like, again, the same company Netlify sent out ah an email. I think it was Netlify. They had sort of separated themselves and JAMstack had its own website and stuff too. So maybe it wasn't particularly them, but the idea. um They sent out this email saying, okay, JAMstack means this now. It means composable. it And and and they they literally said like, it doesn't mean JavaScript API is markup anymore.
01:06:00
Speaker
it's just its own thing called Jam. so And it was like, okay, and here's what it means. It means composable ah software development, where you like bring things together, you know this API from this service, this API from this company, this API, yeah and you compose your application together from various services. And it was like,
01:06:17
Speaker
Great, isn't that what everybody's doing? It's like, so what does what is the what does the term mean anymore? like It's like, yes, I get that. And as it kind of went on, it was like, yeah, okay, Jamstack started to die. You started to see less conference talks about Jamstack. And then, like I said, I think the killer in the coffin for me was the nail in the coffin story.
01:06:36
Speaker
was the email that says, hey, just so you know, officially Jamstack is dead. We're not sending out a newsletter anymore on the website. It's going to go down eventually. Jamstack skip it. That was a really long skip it. Sorry. That's good.
01:06:52
Speaker
All right, i like so with that description, I would definitely say skip it. I think that um a lot of that, for for one, the security concerns are just, especially since security is taking like a main spotlight on many, many, many sites, um having having those kinds of concerns in a backend for frontend type of of ah layer is it's definitely where you want to have that. You can also get caching there um to reduce load times.
01:07:22
Speaker
So, and I always um like doing my data consolidation behind the scenes and ah on a very small, close to front end ah type server piece, especially in in cloud environments. um I say skip it.
01:07:46
Speaker
I, let's see, how do I say, I would say ship it. In certain cases, right? So there are, I don't know that server side rendering is necessarily the answer for everything. like I don't want, we know the pendulum shouldn't swing all the way to like all or no, it doesn't have to be all or nothing. I think there's for certain experiences where.
01:08:03
Speaker
concepts now, maybe the term and that, that whole environment and the movement is dead, of course. Right. But, okay. Yes. But I still think using JavaScript in the browser, calling APIs and using markup to display things to users that that that concept is solid, right? the The essence of what they were saying. So I think it's ship it. Um, and, uh, you know, to with certain in certain scenarios, yeah put that asterisks on it for certain. Yeah. Yeah. Yeah. I, I, I was.
01:08:33
Speaker
thinking the same thing, you know, because, you know, back in the day, the static sites did have their place to even, even just for like content, like when you were just doing content. But I, I feel like the use cases where this would be useful, cause I was trying to think of one, it was like, what would be a use case where I wouldn't have security concerns or I would want the data to be obvious, my rendered version of the data to be a layer away from what the API has given me so that I have that, oh, they changed their version of the API, I can update my mappings. And like I couldn't think of one off the top of my head. ah So that's you know that's what led me to skip it, because I don't think we're in that space where there isn't
01:09:30
Speaker
security concerns or some type of data conglomerate happening between APIs anymore. ah We're not, we're not doing like static HTML type pages. Yeah. And like, there is actually a, I would call it a fork maybe of jams JAMstack or like ah ah a more refined thing that the movement that's happening right now, which is just local first and local first is very similar in the idea that the idea is that you download the files to your, to your, um,
01:10:01
Speaker
device and that's where it does all the work. And that's where your data stays unless you choose to sync it somewhere else. And you and it's about syncing to, it's like, this is my data, I sync it to where I choose, blah, blah, blah. But it's a local app first. And I think local app is kind of where, local first rate is kind of where Jamstack went. And I think if you had to name movement, rename it again, that'd be what I would say Jamstack morphed into the local first, essentially.
01:10:26
Speaker
But there's a lot more philosophy of why and privacy and blah, blah, blah about local first two that maybe wasn't related to Jamstack at all. But I'd say that's kind of what happened with Jamstack. I'd like to say, so we had another one on the docket, but I'm going to, for the sake of time, I think we're going to skip that one because I really want to skip it. You're going to skip it. You're going to skip it. You're going to skip it. I am going to skip it. I, I see what I did there. Um, uh, the last one that we have, people are multifaceted. We want to understand more than just technology about people. You know what I mean? Yeah, exactly.
Should Breakdancing Be an Olympic Sport?
01:11:00
Speaker
And this slide in the, in this next one is more about people and understanding people.
01:11:05
Speaker
Uh, breakdancing as an Olympic sport. Ship it or skip it. I'm going to let you guys, I'm going to let you guys go first. I got a long answer again.
01:11:17
Speaker
James, why don't you kick us off on this one? Breakdancing. I say ship it. And again, but again, I'd like to put an asterisk by what I'm saying here. Don't let Reagan do it ever, ever again.
01:11:34
Speaker
that was that person that everybody's making fun of, that poor person, I mean, that whatever. but But I say ship it because I remember as a kid, Um, I'm old. Okay. Um, I'll be 50 this year. I actually went to like break dancing classes as like, there is some physicality to that. I, you know what I mean? Like there, it is a hard thing. So I think if, if there are going to be things in the Olympics that are, there are much more trivial things in the Olympics that don't show athleticism than break dancing. I think break dancing can qualify as an Olympic sport. I just think we, the the example we got in Paris this year was a little, little, little cringe.
01:12:15
Speaker
Now, you know i i'm I'm on the fence. im I'm going to say it needs work for, so I'm going to skip it with an asterisk. And my asterisk is isn that if you bring it back, you need to change the criteria by which it's judged in possibly the format. um So the whole the whole dance battle aspect of it, I wasn't good with. um you know I'd rather see one performer doing their bit to a set song or whatever and, um, it being less subjective because I thought there were some really good dancers that got like, didn't get put through just because the other person, you know, we're hitting check boxes on a list type of thing. Um, cause I actually watched it in detail cause when I was learning to break.
01:13:11
Speaker
There were no breakdancing classes. We had to pull up the cardboard and kind of figure it out from what we saw somewhere. Um, and, uh, a lot of those, I do agree with the athleticism of it. There are some of those moves are extremely hard to do. And if you mashed up some of the moves that were done on the floor there to the, um, men's gymnastic or exercises.
01:13:39
Speaker
you will see a lot of those same moves, uh, being done. And so from that aspect of the ah athleticism, I'm like, yes, shift that part of it. Absolutely. I enjoy having the, you know, it done to music. Cause I was kind of asking myself, I was like, why did this, the women's gymnastics team get music to their floor routine and the guys don't, um, or vice versa, you know, it's like you're doing tumbling passes on the floor. Why are they different?
01:14:09
Speaker
Um, and I also think that we're, I'm getting off track a little bit, but I also think, you know, ah why are the events different for women and men in gymnastics? Um, but, uh, so for the break dancing thing, I think I didn't like the judging format because I thought some of the better dancers didn't get put through. Like I thought the French, um, break dancer, I can't remember his name, but I thought he was phenomenal and he got taken out.
01:14:38
Speaker
by somebody I didn't think was is um had as good of a performance. and ah so i was and i how How did that work? And and as I was watching it, it was like, oh, he checked off more boxes for the judges. And what'st it wasn't judged the same way. So I think there should be, it it needs to be more like gymnastics where it's a more of like, a these are the things that get judged in how they do it. These are maybe like,
01:15:08
Speaker
required elements that you have to put into your dance type of thing is more of maybe a routine, uh, that has to be done and maybe a level of difficulty of your routine type of scenario. So I, for me right now, I'm a skip it with that asterisk of if you you bring back, it needs to be done better.
01:15:29
Speaker
Well, all right. I gotta admit, I didn't think we'd be taking this so seriously, but I'm going to take it just as seriously as you guys. So I'm going to say ship it with a tilde and a superscript ampersand because I want to say ah I agree with everything you said as a sport. You know, it needs to be, you know, actually the same things are always being said about figure skating. It's like, well, how are they judging it? Where's the transparency in the judging? Blah, blah, blah, blah. Same thing with that. So, yeah, absolutely.
01:15:55
Speaker
um And, ah you know, it's a new sport, hard to judge, hard for laymans to judge too, hard to be like, well, what why does that guy look so cool? Why is he losing to this other person that did not look so cool? Now, specifically with Regan.
01:16:09
Speaker
I also said I sort of gave a ship it because I would say this is like one of those um Rebecca Black Monica Lewinsky kind of situations where this thing happened and she went out there and she wasn't trying to do anything. She's not an artist. She wasn't trying to be avant-garde. She wasn't trying to be like break the system or anything. She's just doing her best.
01:16:29
Speaker
And suddenly she was descended on by the mob of the internet, the largest, most destructive mob in the history of mankind, descended on her, insulted her. They put her on TV, just like Rebecca Black, just like Monica Moon, put her on TV, making fun of her. She was probably in an an SNL skit. I don't know if that's true, but probably, um,
01:16:50
Speaker
literally, you know, talk show hosts making jokes about it. Though probably the most crushing bullying that can happen to a person ever in existence. And I do think she is going to become one of these stories much like Rebecca back in Monica Lewinsky, where the bullying is going to define her future probably. And she's going to come back and be like, this happened to me. And here's how I dealt with it. And she'll help like a million other people being bullied in the future. So more power to Ray Gun, keep Rick dancing in the Olympics, ship it, ship it all the way. So I yeah i know it's interesting. You know, I think back in it and there, there have been other um instances like I don't know if any of you have heard of Eddie the Eagle, the the British ski jumper. he He never was going to make a medal. And really, e and it was it was kind of the Ray Gun kind of thing. It was like,
01:17:45
Speaker
You know, um, he just got there and did his best and everybody was kind of rooting for Eddie, the eagle to to score big. Um, and that was kind of the pre, because that was an older reference. And then you talk about the mob descending down a similar situation happened in the pistol shooting events as well with the, um, the guy from.
01:18:11
Speaker
turkey ah Turkey, Turkey, yeah Turkey. Uh, that, you know, he, he was an older guy. He didn't have all the fancy gear and everything. And they descended on him as being, Oh my gosh, this guy is like a hit man. You know, he's, you know, he's just like, and, and it was like, he was a really good shooter and he's been competing for a very long time and he didn't have.
01:18:36
Speaker
the extra, you know, blinder on his glasses and things like that. And everybody was shooting with their hand in their pocket. So it's like, you guys are taking this way out of context. The guy's just an old guy that knows how to shoot. Nice. And I can call him old because he's actually a year older than me, but ah a little different there though, because he was like the coolest guy ever. You know what I mean? Like nobody was like, yeah he's in an assassin and there was no bullying there. It was more like, that's so cool. Whereas like Reagan, I'm sure is just getting like death threats and whatever. You're the worst person ever. She's the worst, you know, that kind of thing, but still weird internet mob thing.
01:19:16
Speaker
Yeah, and I don't know if the the claims are substantiated yet or not, but my understanding is there was some shenanigans around how Reagan actually got to the Olympics. Like there were other people more qualified that should have made it through, but there was some.
01:19:31
Speaker
weird stuff going on. I don't know. they it It's probably conspiracy theory stuff, but I'm sure the documentary will come out soon. And yes, yeah maybe my opinion will change. But as far as I know, I don't know. So far, it looks pretty religious. If it if it was honestly just she's given her best and she did the best she could. OK, I'll take back my statement. But if it but if it was shenanigans that' like somebody else that should have been there and said of her and I'm almost stand by it. I will pistol whip the next person who says shenanigans. that's a reference hopeful I love the movie reference. I love it. Love it. Love it. Yes. I'll go guzzle some maple syrup just to. All right. So time for our final segment. Everybody's favorite. The lightning round.
Light-hearted Q&A Session
01:20:18
Speaker
Have you ever worn socks with sandals?
01:20:22
Speaker
yes i have because i'm an old man with no fashion sense so yes yes i have also my feet get really cold yeah i like it all right scale at one to ten how good are you at whiffle ball never played zero zero okay we would have accepted ten as well
01:20:49
Speaker
What's the fastest speed you have ever driven in a car? Hmm. That's a good question. It would probably be 150 kilometers per hour because I'm Canadian. We use kilometers here. So 150 kilometers. I think that's about 90 miles an hour, I think. Let's see.
01:21:13
Speaker
You're correct. nine one fifty well ninety three point two one miles per hour too but yeah And this this might be an interesting question um because if you do live in Canada, so there may be interesting differences in the way we do carnival food here. What is your favorite carnival food?
01:21:32
Speaker
o Well, um I don't even know what they're called. There's these little mini donuts that they make, and and they're really, really fried, and they're really, really tasty, and they just douse them in like cinnamon and sugar. But I can't remember what they're called. There's like a name for them, but i I'll call them mini donuts, but it's like, there's a more specific name for that. I just wish I could remember. Do you guys have that? There's like a lot of lot of fried dough going on at carnivals here, too. We dig our fried dough.
01:22:02
Speaker
Elephant ears, funnel cake, those, those, those are my favorites. Like that kind of a thing for sure. I, I was, I was totally banking on hearing poutine, but it's not really a carnival food. That is a cuisine. That is like, so, you know, that's all right.
01:22:23
Speaker
all right Um, do you like the word dapper? I'm a Dapper Dan man. Yeah, absolutely. I yeah i enjoy the word dapper.
01:22:36
Speaker
ah When people stand up for a standing ovation, are you usually one of the earlier people to stand up or one of the later people to stand up? I i guess I'm in ah in the middle because as soon as they start people rising, I will stand up. So like, even if it wasn't a standing ovation, if people just started standing up. I'd be like, I don't know what's going on, but I'll stand up quick just to make sure I'm not the guy. I don't know. Is the national anthem happening? What's going on? Why are we standing up? What is this? i I better do the same thing. Yeah. Okay. All right. Now,
01:23:04
Speaker
If we ever get a chance to meet, I will ask, please bring some ketchup chips down from the great white North. I've heard this is an amazing thing. I don't, I've never partaken in a ketchup chip just yet, but I've heard they're amazing. Also going to bring you some all dressed chips in case you don't have those, which are delicious. but We do not.
01:23:24
Speaker
Have you watched Letter Kenny? They did a whole episode about what the best chip is. Oh, I have seen Letter Kenny, but I so don't remember that episode. It was one of the later seasons. It may be the latest season they did it. It was a whole episode dedicated and somebody talked about the all dressed chip. I believe that was one of the popular. It is extremely popular. Yeah, they had a whole debate about it. It was very good.
01:23:48
Speaker
Most of what I know is either from Strange Brew or Letterkenny from about Canada.
Canadian Cultural References and Farewell
01:23:51
Speaker
That's all you need to know. You just nailed Canadian culture in one fell swoop there. That was great. That's all you need to know. I mean, I I'm more of a hockey guy. So Shorzy was was is my GM. OK. I consider Shorzy a wholly owned subsidiary, I guess. So I consider that part of the Letterkenny, you know. Oh, it is. It's a total spinoff. but Yeah. Yeah.
01:24:17
Speaker
um with a lot of character crossover too. but ah Yeah. it's It's great. I like it because it's a little bit more end to end Canadian instead of just like, you know, wherever letter Kenny is supposed to be. Yeah. Okay. So I think we've gone through everything. Yeah. And and then some. um Thank you to our guests.
01:24:48
Speaker
Adam Barrett for joining us today and my beautiful co-host James Carmen. I am Aaron Chesney. This has been the forward slash where we lean into the future of IT. Thank you for listening. Stay tuned for future episodes wherever you get your podcasts from and thank you and good night.