108: Vite, Debugging, and PNPM with Ed Faulkner

[00:00:05] Robbie: What's going on everyone live at EmberConf here for whiskey web and whatnot recording. This is a podcast aptly named. It is about whiskey web and whatnot. And we are the hosts. I am Robbie Wagner with my cohost as always, Charles William Carpenter, the third.

[00:00:22] Chuck: it is about whiskey, web and whatnot. And we are the fifth.

[00:00:25] Ed: III. Today I want to V. That name is taken. My oldest son is Ed Faulkner V.

[00:00:31] Robbie: Oh, okay. If you

[00:00:33] Ed: call him Ed, though, he probably won't even answer you because he's so used to being known as Quint.

[00:00:37] Robbie: Okay.

[00:00:38] Chuck: I like that nickname. That's clever.

[00:00:40] Robbie: I don't have any fancy seconds or thirds or fourths or anything for me, but, uh, we do have Ed as our guest. , people probably know who Ed is since we were at EmberConf, but for anyone who may be listening later, can you give a quick intro into who you are and what you do, Ed?

Sure,

[00:00:53] Ed: I'm a member of a bunch of Ember core teams, and I have been for a lot of years.

I've definitely been around the community a long time and seen a lot of the technology and the people It's really great to have been back at this first in person EmberConf that we've had in a bunch of years after pandemic times.

[00:01:07] Robbie: yeah, it

[00:01:07] Ed: really, really recharges my batteries a little bit to just see everybody again.

And, it really does matter to, uh, faces to names and people you've been talking to online a long time. I think remote work is great. I'm totally fine with remote teams and everything, and in open source we've always had to work remote, but just getting a little bit of face time with people really, really helps, and it helps you collaborate into the future, even when you go, all go back to your homes. definitely. Something that also helps

[00:01:31] Chuck: with

[00:01:32] Ed: with in person situations

[00:01:33] Chuck: and socialization is whiskey.

[00:01:35] Robbie: we have as you like, all that kind of

[00:01:36] Ed: today.

[00:01:37] Chuck: Yeah. And we have a unique experience too, since we have audience members for the

[00:01:41] Robbie: Yeah. Tell us about it, Chuck.

[00:01:42] Whiskey intro

[00:01:42] Chuck: sharing if they choose to share, have as much as you like, all that kind of fun stuff. Tell us about it, Chuck. Tell us about it. Well, today, folks, my phone went to sleep, and that's where my notes are. I have notes

[00:01:53] Robbie: and that's where my notes here if you want them. Alright, today we're

[00:01:55] Chuck: here. Yeah. the Westward Whiskey Cask Strength. It's an American single malt. It is 125 proof, so it's a pretty hot one. , non age stated, but I actually learned something new about American single malt standards.

Oh, yeah? So the, uh, Alcohol, Tobacco, and Firearms Bureau, they have come up with single malt standards that require it to be Aged in American oak, , has to have a minimum of four years on it. So even if it's not age statement, we know we got at least four years. This one has a little color, so I'd say at least that.

, yeah, that's about all I got. Obviously it's a single malt, so that's all it's in there is a malted barley.

[00:02:32] Robbie: Yeah, so we, we tend to sniff a little, taste a little, come up with arbitrary descriptors about how we think it tastes and smells.

[00:02:38] Chuck: Yeah.

[00:02:38] Robbie: Um, there's no right answers.

[00:02:40] Chuck: Yeah.

[00:02:42] Robbie: Uh, I think it smells a little bit like some lime gummy bears.

[00:02:46] Chuck: pears.

No, that's what you had before you showed up.

[00:02:48] Robbie: Oh, you're right, you're right. Uh,

[00:02:50] Chuck: Uh, I'm actually getting kind of a toffee smell. Yeah.

Anyone in the audience can call me out on bullshit.

[00:02:56] Robbie: call me Adam.

[00:02:56] Chuck: could say bullshit on this show too, so it's fine.

[00:02:58] Robbie: Explicit show. Sorry.

[00:03:00] Chuck: I mean, we are drinking.

[00:03:01] Robbie: Yeah, yeah.

[00:03:02] Chuck: to pretend that

[00:03:02] Ed: a lot of sweetness.

[00:03:04] Robbie: Hmm.

[00:03:05] Ed: I'm not going to say anything more sophisticated than that. I'm not going to pretend that I can taste the, uh, the lavender notes among the, you know, uh, the...

[00:03:13] Robbie: the tanned leather or whatever.

[00:03:15] Chuck: Oh, yeah, I was gonna say freshly tanned hide. Cow hide. Uh, no, I am still getting kind of a toffee in the initial. A little, little bit of like cocoa and a toffee in the initial flavor. It's fun. You said lavender. Now I'm kind of feeling a little bit of floral through the middle, but it is it is very hot at 120 something proof.

and just so everybody knows who's listening later, we're doing this at 11 30 a. m. prior to lunch. So looks it looks like dessert was first today. Um, yeah,

it's pretty. It's diverse, though.

[00:03:44] Robbie: I

[00:03:45] Chuck: I like it. I think

[00:03:46] Robbie: Yeah, this uh, this brand has won a lot of awards. They're like all double gold.

[00:03:51] Chuck: Right, so... Westward Whiskey is a Portland distillery also, so we thought, like, oh, we're gonna be here, let's try some of the local flavor.

aside from strip clubs and vegan restaurants, um. And, uh, I think this was a good choice. I would, would recommend, I would, you know, the fail was I didn't bring the little water dropper, you know, to like have the two and be all extra fancy. I'm the

[00:04:14] Robbie: have a glass at least. I

[00:04:16] Chuck: yeah, so. I take my drinking problem very seriously, so.

Um, I'm gonna give it a second whirl, and then we'll, uh, we'll discuss, we'll talk about the, uh, the rating system, which is really clever and very specific, so.

[00:04:29] Ed: really

[00:04:29] Robbie: Yeah,

I do get a little bit of caramel in there, I think.

[00:04:33] Chuck: Yeah, for sure, but definitely something floral in the middle. I don't know, I think Ed got me on that one. Every time somebody mentions something, except for lime gummy bears, I, I

[00:04:41] Robbie: you don't taste that.

[00:04:42] Chuck: start to get that, yeah. Um,

[00:04:43] Ed: an

[00:04:43] Robbie: I

[00:04:43] Chuck: know, like dried apricot or something maybe?

Um. Yeah, so there's a inside joke is that, uh, that's like half of my

[00:04:50] Robbie: is dried up. Yeah. If you listen to episodes later, they're, you'll hear that in every episode pretty much.

[00:04:55] Chuck: uh, okay. So, Ed, we have this, uh, highly complex rating system. It's one to eight tentacles because of the octopus and the tentacles, as you can see on Robbie's t shirt there.

Um, we do allow zero since we are programmers and zero indexing is something that's part of our lives. Um, but one or zero would normally be, this is terrible. I never want it again. , eight would be amazing. Never want to drink anything else. Possibly at least in comparison to some in the same category.

Because Robbie and I drink so much, we tend to categorize our own, but you could just say in whiskeys or just beverages in general, how would you rate that? So four is not bad. Four is like, this is good, middle of the road. so I'll, I'll tee it off to you, Ed.

[00:05:35] Robbie: What do you think?

[00:05:35] Ed: yeah, I give it a five. I, I, it's, it's better than just okay. For sure. I would usually be more of a, uh, of a bourbons and, uh, or, or like that's a nice smoky scotch. Those would usually be my go to's category wise.

[00:05:51] Robbie: Gotcha.

[00:05:52] Ed: but this is, this is pretty nice for the category. I like it.

[00:05:55] Chuck: But this is your go to sipper, then, in those?

[00:05:57] Ed: I like, just a nice, a nice bullet. It's fine. Nice, stable American bourbon kind of taste. And, uh. You know, on the, like, scotches, it's probably, like, the, uh, I don't know, what's the super peaty ones? Give me some examples. Yeah, like the

[00:06:13] Chuck: like, the peat monster and

[00:06:14] Ed: The stuff that my wife says tastes like a campfire.

[00:06:16] Robbie: Oh, yeah. Oh,

[00:06:18] Chuck: It tastes

[00:06:18] Robbie: I think it's pretty good. It's, uh, I don't know. It's not my favorite. I'm gonna, I might also say five. I think there's a lot I like better. I typically like rye more.

[00:06:28] Ed: Um,

[00:06:28] Chuck: Well, yeah.

[00:06:29] Robbie: Yeah, just not super blown away.

[00:06:31] Chuck: Okay. Well, as I said, I'm going to actually categorize and not compare this to a rye.

So, uh, American single malts or, it's a, it's a fairly burgeoning new category in whiskeys for American micro distilleries. And I'm always worried that they're going to try and make an American scotch though out of that. And I'm, I'm impressed when, when, uh, distilleries decide to kind of do their own thing with it.

There's another one out of Tucson, Arizona called Del Bach that does like smoked mesquite and they'll smoke the, the barley as part of their process. And that kind of brings a little something to it. so in that family of things, just. Yeah, I'm going to give, still leave scotch over there and I'm going to say American single malts.

I, I actually think this is really good. I think it's very diverse in the flavor. This is a cast strength one, so it doesn't make it as palatable, like, over time. It burns like hell, actually. Um, so a couple drops of water in a cube or something like that would probably help you sip it a little more. It's not going to be, but you should have it independently.

I think it's too much for a cocktail. So I'm going to give it a seven. I think, uh, Portland's doing something really nice here. , would definitely have it again if I was looking for a different American whiskey. And, uh, I'd be interested in trying their other expressions, too.

[00:07:42] Robbie: Yeah, that's fair.

[00:07:43] Chuck: Um, so we'll just do, let's jump, jump to hot takes. Hot takes. All right. Hot takes.

[00:07:48] Inferred vs explicit types

[00:07:48] Robbie: Uh, in TypeScript do you like inferred types or explicit types?

so

[00:07:52] Ed: it depends on, if you're just writing your own code, if you're writing an application and you've got the choice of, um, inferring or having to say it explicitly, Inferring's totally fine whenever it's working out great, to say the least, on a thing. If you're the library author, though, whose other people are going to be importing your stuff, and having to, like, take a look at your stuff, I do think it's nice of you to be explicit about the types that could have been inferred, but you really want to say it very clearly for the people who are going to come and use your code.

Yeah,

[00:08:21] Robbie: that makes sense. We do hear a lot of that about, you know, libraries being much different than apps, for sure.

[00:08:27] Ed: It really is, and it, you know, it's, uh... as my own career

has progressed, I've definitely been, found that I'm a, I'm definitely a library person. I'm happier building the tools that other people are going to use to build applications.

I mean, I, working on apps is fine too. But, um, I'm definitely attracted to working on the tools and the libraries and the lower level stuff. I, I've often tried to explain to folks who, who start doing that work for the first time. They often feel really frustrated because they're like, I feel like I'm really bad at this.

I'm going really slowly.

And I have to explain that it's actually okay. It's supposed to feel slower than app development. Like, you're under a lot more constraints, and if you're working, when you're working on a change that's gonna affect a thousand applications at once, and not just one, it takes a lot more, takes a lot more out of you, and it's fine that it goes slower.

It's, it's supposed to move a little slower when you're at that layer, and you shouldn't feel like you're doing a bad job. Like, app development feels faster. Library and framework development feels slower, and that's just how it always feels for everybody. It's not that you're bad at it.

[00:09:25] Chuck: Yeah, a little more care must be taken because you know a lot more people that you don't have direct contact with are going to use your thing, or you hope so. That's why you're taking care in that. So yeah, I think that's a great breakdown of descriptor. I was just thinking for a second though. So we have this section of the podcast called Hot Takes.

It's like quasi hot takes. It's just basically things that, uh, people would argue about on tech, Twitter or other internet spaces. So we're like, okay, let's, let's see what, uh, people were talking with. Uh, think about those things. So I was just an aside. ,

[00:09:56] Rebase vs merge

[00:09:56] Chuck: so on that note, get Rebase or get merge.

[00:10:00] Ed: note, get merge? Oh, I'm a merge, merge can't merge.

[00:10:02] Robbie: merge.

[00:10:03] Chuck: never working with Ed.

[00:10:04] Ed: Never working with that. I mean, if you, if you're working on something privately that you haven't shared with anybody yet, rebase is all you want.

But once you're working with other people, it's all merges. philosophically, it's like I, I get why people like the clean linearity of the, of the rebase world. But I think it's a lie. I think, uh, Merge shows you the messy reality of what really happened.

[00:10:27] Chuck: Oh,

[00:10:28] Ed: And, uh, that neat linear history, it was a lie.

[00:10:33] Chuck: I, I think that's an, an interesting and different take that I hadn't

heard before, so That's true. 'cause I, I cover up the dead bodies all the time. Yeah.

[00:10:42] Ed: Yeah.

yeah, you know, I do think it's, it's still appropriate if you're trying to present yourself to somebody else, especially if you're like a drive by dropping a PR on some project and you don't even know these maintainers, you should definitely think about constructing them like the most clear, put your, put your changes in the best light, right?

If that means one commit, that's fine. If that means like several that you've carefully rebased and crafted to tell a story, that's really good. Yeah. So, I'm not saying you never reuse the rebasing as a tool, but, um, once you've handed that off to the world, I think at that point you're, you're merging, you're collaborating on stuff with other people.

[00:11:17] What do you think about milk?

[00:11:17] Robbie: collaborating on here, and I don't understand the context, so I'm not going to ask that one. I'm going to skip to, what do you think about milk? What do I think about milk? Yeah,

[00:11:26] Chuck: Yeah, what are your thoughts and feelings and passion around milk or milk substitutes? That's the part you left out.

[00:11:31] Ed: This isn't like a, there's not like some ship library called milk you're asking me about right? This

[00:11:35] Robbie: nope, milk. The beverage, yeah.

[00:11:38] Chuck: Comes from cows or other animals

[00:11:39] Ed: Well, well, oh, I suppose the controversial thing is whether you can call the other things milk, right?

Wasn't, wasn't there some kind of regulatory lawsuit about whether like almond milk, people could call it

[00:11:49] Chuck: Yeah, yeah, there was. I don't know where that landed, but

[00:11:52] Ed: So, yeah, what, what even is milk man? I dunno. , uh,

[00:11:56] Robbie: is milk, man?

[00:11:56] Ed: I definitely like dairy, but usually just like a splash in my coffee is my, where I go. Uh, I, I'm a big coffee drinker.

I don't drink a vast volume of coffee. I definitely am an aficionado of coffees. And I'm also hardcore addicted to caffeine. So if I don't get my two cups a day, I'm gonna be having a really bad day. And I'll drink it black. I like straight up coffee and just taste the coffee, but there's something so nice about Actually, it's very analogous to having a drop of water in your whiskey to really open up the flavors.

There's a lot of coffees where a little bit of that dairy fat in there really opens up the experience. So, I'm all in with the cream and the half and half. Just a little bit. definitely not your like frappuccino world. Not that kind of coffee drinker. I don't want all that dairy, but the little bit goes a long way.

Other than that, no, I'm not like, I would never pour a glass of milk and drink it just because I'm thirsty. It's not my thing. That's

[00:12:49] Robbie: drink it just because I'm thirsty. It's not I really do that either.

[00:12:51] Chuck: It depends. It's always the

[00:12:52] Ed: It depends.

[00:12:53] Chuck: It depends. Alright, so I'll give a little context for this question since Robbie's easily confused. And so, again, as I referenced before, Tech Twitter, talking about a lot of things. There's an interesting, I mean, it's not a concept. It's an actual thing. But htmx. Have you heard or seen anything around htmx and hypermedia?

And it's basically like a regression to simpler tools around requesting data and just rendering html because it turns out html is really good at showing you information and deciding how complex you want to add, like full application logic and memory and all those kinds of things. Like, remember, servers used to do that for us.

And then the browser just showed us like Geocities banners, or whatever else. So, not quite to that deal, but like, thinking about a potential regression of simplifying things, and have we overengineered things as a whole. So my question was, around that, HTMX is the thing, but there's a few different ones.

[00:13:50] Thoughts on new tools like HTMX

[00:13:50] Chuck: HTMX or EmberJS.

[00:13:52] Robbie: EmberJS.

[00:13:53] Ed: Well, okay. So I do think there is, there's something to this story that a lot of overengineering has been done, but

I think that's because of people choosing technologies really getting over excited about themselves and miscategorizing their own applications. I think. that the vast majority of the applications that I work on and the folks that I help work on applications, they are in fact building applications, right?

They're building the kind of thing that would have in an earlier era been a pretty complicated desktop application a lot of fancy UI and a lot of state and a lot of different views of things. , apps are really a thing, right? just like mobile apps are definitely a thing. Some things are applications and some things are content.

And apps are a thing. And if you're building apps, I am still very strongly in camp, like, have an app real, like, build a real application with state. Like, have a running application that, talks to APIs to get what data it needs and truly maintains all its own state right there in your device, Like, that's the full throated build a real JavaScript application if what you have is a stateful application. And yeah, build it with Ember. The other kind of thing you're talking about, where you're, you're smearing your state between the server and the client, that is appropriate, for when you are doing stuff that is very document oriented, that is very content oriented.

And I think there's a lot of, a lot of people got excited about JavaScript applications, and wanted to be doing them, even though the task they were assigned was like, go make me another product, catalog page. And like that kind of stuff, it wasn't a good fit. Like, if you were building all that stuff as JavaScript heavy, you were picking the wrong tool.

Because you're not trying to build a complicated application. You're trying to build like, you're building classic web content, right? Some hierarchy of content pages. And yes, you have little bits of interactivity you want on them. For that stuff, yeah, you were probably picking the wrong tool. If you tried to, because if you were trying to just get that button interactive, just get that, like, sign up for my mailing list box interactive, and you did it by replacing the whole web document model with a big JavaScript application, you probably messed up.

But that's not because, like, JavaScript apps are bad. That was because you didn't want a JavaScript app. You wanted a web page, right?

[00:15:59] Chuck: JavaScript

[00:15:59] Robbie: think e commerce can actually be the gray area, too, right?

[00:16:02] Ed: a full

[00:16:03] Robbie: so there's interactivity.

[00:16:05] Chuck: I mean, is that a full fledged application because of identity and something else? Or is it good enough coming from the server and then capturing the end of the flow in a particular way? Yeah, I mean, I think, uh, well, you know, the secret to all these questions is always, it depends. And, uh, I think that the frameworks and, and, and the over engineering kind of happened because there was a different context in resourcing, too.

That we can reconsider is like, yeah, my personal computer is pretty fast, and you can spread out some of that usage to the users themselves, but also like the cloud is everywhere, and it's really fast, and resources have become cheaper, and so everything we thought about 10 years or more ago, maybe isn't as much of a problem, so it depends.

[00:16:48] Robbie: you brought up good points about like, how you

[00:16:50] Ed: Usage to the actual CPU cost of stuff. That matters a little. I mean, it matters a lot if you're really gonna be, Really caring about supporting all the users out there in the world. if you look back over a few years of discussion about this stuff, right, people were a few years back really pointing out repeatedly that, uh, look at, look at the low end devices that most of the users on the internet are using.

Your stuff is too heavy. that story is wearing thin.

and it always was gonna. you could be like, yeah, I get it. But. If I'm trying to invest in technology for the next, that's a good five years from now, even those developing country users are getting faster and faster stuff, as soon as your iPhone is not the hot thing anymore and Apple's trying to sell you the new one, that factory still exists and it cranks out those chips and they're cheap and they sell them all over the world, right?

So like, we've now out weighted the, like, devices are too slow era, frankly. There's still networks that are slow, and, and there's definitely still slow devices, but if it's still too slow for you, wait another two years, so, like, the device scaling stuff is not really the high order bit, I think, when you choose this, this gray area between where do you keep things.

I think it's about, the, the limiting bandwidth is always, like, our brains and our ability to manage these applications.

And so it really is, where is it going to be easier to manage the state? State is the thing that's hard to manage, right? And That's how I would say you'd categorize your applications.

If it's, if the state of the user experience really is centered on their device, and that makes it easier, that's the kind of application that should be a JavaScript application. if the state is easier to be centered on the server, and it's going to be persisted there, and that's the easier thing to do, then let's do that.

that's the kind of criteria I'd be looking at.

[00:18:26] Chuck: Right. And also maybe there's an inflation of ego to

[00:18:30] Robbie: to

[00:18:31] Chuck: assume that you have users worldwide because that's a misunderstanding of what you're trying to accomplish also, too.

So if you're, always mobile first, always, I mean, I think progressive enhancement is a pretty good thing, but I mean, if you might be like overengineering and that ideology, too.

[00:18:47] Robbie: right. Yeah.

[00:18:48] Ed: And, and I think also people want to, like you said, I think it is an overinflation of ego sometimes to some people put themselves into those buckets 'cause they, it's the cool thing to talk about and cool thing to do. I think there's an awful lot of applications that have much more focused user bases.

And if, if you really lean into that, there's, you know, there's a lot of successful software built that way. You know who your users are.

[00:19:09] Robbie: are,

[00:19:09] Ed: you don't need a billion of them if what you're selling is super high value stuff, and uh, you know, there's a lot of applications that are like live within one big company and people in that company use it and nobody else does.

And you know who your users are. there's a huge, dark matter part of app development that is all that stuff. And, um, it doesn't get talked about as much because people don't know those applications. The people who work on them can't point at them and say, like, this is the stuff we do.

Because, I don't know, you work on some dashboard that's used by a thousand people, but they all work for one company, and it turns out it's hugely important. Like, a chunk of the economy would fall over if your app wasn't working, right? This stuff is important software, but we don't see it. It's not consumer facing.

It's not on the public web. that kind of stuff, it just definitely has different constraints, right? And if you listen to what is trendy that the, like, the fang companies or whoever is building today for consumer facing stuff, and you try to apply it in that environment, it just doesn't really matter, right?

You're just getting misled.

[00:20:07] Chuck: that we've not really discussed around that.

[00:20:10] Robbie: yeah, so what is your least favorite programming language?

[00:20:14] least favorite programming language

[00:20:14] Ed: JavaScript.

[00:20:15] Chuck: Please say JavaScript.

Well,

[00:20:17] Robbie: No, well, I definitely have a love hate with JavaScript.

[00:20:20] Ed: I think the language is fine. I mean, I'm not mad at JavaScript for the language. I think JavaScript is both love hate for the same reason, which is that it is so accessible because it's in every web browser. And, like, getting started with JavaScript is a very... It's a much easier... I'm not saying it's easy, but compared with a lot of other language communities, it's much easier to get started with, and so we get a lot of beginners.

That's a hugely good thing. I think that's ultimately great that we can get people into programming. But it's also frustrating because we've got to deal with that tidal wave of beginners all the time. And so the, even though as people all come in and progress and they gain experience, but and JavaScript in particular are still expanding so fast that at any given point in time, most of the people in the room are beginners.

And so, You have a real challenge of, propagating cultural knowledge, propagating experience. it can be really trying because you'll get a message across and, kind of teach a bunch of people something. And then, you know, next year you've got to do it all from scratch again because, like, the whole, the

[00:21:23] Robbie: whole,

[00:21:24] Ed: general ecosystem is just a constant wave of new, new people. It's a good and bad, because it's very invigorating. There's constant new ideas and constant change is, it produces useful innovation. But at the same time, there's some lessons you don't need to relearn every year, and there's some wheels you don't need to reinvent every year. yeah, I'm the crafty old man saying like, yeah, we've been down this road before, we know where it goes, but, you know, can I tell you the punchline already?

Let's not do it again,

[00:21:51] Chuck: Yeah, yeah.

But you still have to pick the one you hate.

[00:21:54] Ed: Yeah, oh yeah, okay. I, no, I do want to do that too. I won't say hate, but I will say the language that disappoints me the most, uh, would definitely be Go.

[00:22:02] Chuck: Go.

Oh, okay. And

[00:22:04] Ed: that's, and that's because really, and this is not because it's a terrible language, like I think I'd much rather pick Go over writing something new in C or something like that.

But it's because Go is like consciously designed in an era when they should have known better. And, like, they were supposed to learn the lessons of the earlier stuff. And, um,

I disagree with some of the philosophy there. The philosophy there is like, We can't trust programmers with more powerful abstractions, so let's keep it really flat and simple.

And it just doesn't work. way they fought against generics so long. Uh, it's like, yeah, you can do terrible, confusing things with them, but if you don't have them, people are going to do terrible, confusing hacks around not having them.

[00:22:41] Robbie: They're going to get there.

[00:22:42] Ed: and so, like, that's where I would, I would be like, no, definitely camp Rust over Go, because it's, you know, it's,

[00:22:49] Chuck: not just because of

[00:22:50] Ed: no, no, not just because of Yehuda.

Well, I mean, I won't, I will say that, like, it's not a coincidence that Yehuda and I both work on same things and probably both like Rust better than Go. It's because of the underlying principles and philosophy are aligned there. I think we, we, we both should. I'm aligned with Yehuda's philosophy. That's why I like working on the same stuff he works on.

It's not a coincidence, yeah.

[00:23:11] Chuck: Fun fact, uh, Golang was actually originally called Googolang, and they just shortened it because they were afraid, you know, people would be distracted and dissuaded from that. Yeah.

[00:23:20] Ed: I believe it, yeah. And that's also probably why, not that I'm not, this isn't Google hate, but like, it's clearly designed for that environment, right? It's designed to work for Google. It's not designed to work for you.

in that kind of environment, I really dislike low trust in your programmer's environments.

I understand why people get defensive in, like, particularly in super big companies with thousands and thousands of developers. It's easy to get burned a few times by, you know, groups of people going off and doing things that make big messes that are hard to clean up later. But if you take the lesson from that, that, like, we just have to not trust our programmers and take away their autonomy and not give them powerful tools because they might misuse them, I really think you've shot yourself in the foot, right?

Like, why are you paying all these people? You really need to build a culture of Learning and trust and building people up so that they can have powerful tools and they can make big tech decisions I see a lot of a lot of defensiveness defensiveness in big companies where it's pretty challenging to make an impact because,

the scar tissue they've built up to protect them from mistakes also also protects them from innovation and like just joy and progress and making programmers really feel an ownership and autonomy over their work so that they'll do a good job and be professionals responsible for decisions and not just a cog in a machine, you know?

[00:24:36] Robbie: Yeah, speaking of powerful tools, so let's pivot a little bit back to Ember specifically. So, um, being able to use Vite here soon, what does that unlock for the community?

[00:24:46] What does Vite unlock for the community

[00:24:46] Ed: Well, a couple things I think for the average programmer, the thing they'll see the most is just like a delightfully fast development experience.

And that's hugely nice, right? I mean, not just because it saves you time, but because it's closer, shorter feedback loops really change your cognitive model sometimes, right? Like, there's a big difference between, um, you feel freer to experience when things go faster, right? So that's all nice.

an ecosystem level. I think it's just an example of us being able to, focus our attention on the stuff that's unique about our project and not on things that don't have to be unique, right? We don't need a bespoke build system. We used to, because when we were starting this stuff, it didn't exist.

when we first wrote our, the build tools that we still use today, like, it was extremely controversial to have any kind of build tools, that was a very controversial take that you would dare, require a build tool as a thing in, in web development.

[00:25:35] Chuck: um, that was it set a real standard across many other

[00:25:38] Ed: sure, for sure.

[00:25:39] Chuck: started to look at like, oh, the positive ALPAT, uh, you know, the impact of that.

[00:25:43] Ed: Totally. Yeah, no, like the, for quite a while, um, in Angular, if it hit certain errors, it would say, like, oh, Ember hit an error.

[00:25:51] Chuck: Angular,

[00:25:51] Ed: Cause, cause their, their build tool was forked off of, was forked off of, uh, of Ember CLI, yeah. Yeah, so no, it, it served its point really well, right. It's, uh, it was not a mistake to build it.

Now that the rest of the world has invested in that area, there's a lot of good choices, and we, we don't need to be weird, and we don't need to maintain something, uh, bespoke anymore, which is great. So as a, as a maintainer, I'm looking forward to not maintaining so much bespoke stuff.

in addition to as a user, I'm looking forward to getting, like, the speed and the ecosystem of plugins and stuff that are available to that.

[00:26:20] Robbie: Yeah. It's one of the few things that most people, regardless of community seem to like is vet.

Um, that, and I forget what the, the couple other things that just had nothing bad about them and state of jss, but that was one of them.

[00:26:32] Ed: Oh. I mean, I can say bad things

[00:26:34] Robbie: if you want.

[00:26:34] Ed: I, I, I think v is, it is probably one of the, like, probably the, one of the very best choices you can make right now. I won't say it's perfect, Like, if you're interviewing developers for a job or something like that, A question I love to use is to tell me What you don't like about your favorite technologies.

You can usually ask, like,

[00:26:51] Chuck: What if you hate them all?

[00:26:52] Ed: Yeah, well, exactly, like,

[00:26:54] Chuck: why are you doing

[00:26:54] Ed: kind of the point, right? If, like, first you ask, like, well, what do you like? And then you say, well, okay, what's bad about that thing? Because, you know, if you're thinking critically about your tools, Always know what's bad about them, right?

I mean, that's a useful skill. You really do want people to be aware of that stuff. You don't want them to just cheerlead for their favorite stuff. you know, it's easy to get into a silo where you don't, you're so used to the way things are that you don't question them, right?

And you don't realize things could be better. I definitely want to work with developers who are aware of the shortcomings of the stuff, even the stuff they like, Because they're always thinking about how it could be better. I, you know, I could say things, like, so Vite, um,

say a thing that's, uh,

like, a challenge with Vite and our adoption of Vite is just that it's, it's right now very, um,

[00:27:37] Robbie: weirdly

[00:27:38] Ed: un extensible in the area of the dependency pre bundling.

it doesn't have to be. It's just kind of a choice that was made. So, you know, there's like a first pass that Vite makes where it tries to look at all your code and guess what dependencies you have on the outside. you know, if you're using any kind of custom file formats, whether that's, you know, Glimmer's new GGS files, or that's like a view single file component or whatever, uh, it just, it won't look at those, and you can't make it.

It just won't find them. It's not extensible. It doesn't have to be that way. I think we could probably work with, do some PRs upstream and get it there, but it's kind of a weird take, so, just, there's stuff I could criticize.

[00:28:11] Robbie: Yeah, yeah. Always good to see both sides for sure.

[00:28:15] Chuck: Yeah, but I think as you said, there you go. That's an excellent point, though, if there are kind of flaws in the system, but it's like this is 80% 90% there.

It's going to make things easier across the board and also, um, help folks who aren't as familiar with ember come into the ecosystem, and it's one less hurdle because, there sometimes are challenges learning the initial bits there. ,

[00:28:36] AD SPOT

[00:28:36] Chuck: so then, conversely, right? Like the keynotes yesterday, the big call out there is You know, come on board, help us get the rest of the way there, and then conversely, you can help make these other more, quote unquote, common tools better as well by doing some upstream changes.

And again, continues this continuous feedback loop

[00:28:53] Robbie: there.

[00:28:53] Ed: Yeah, exactly. Exactly. It's definitely advice I'd give to any developer also who's never really had the chance to be. Maybe you don't think of yourself as somebody who goes and makes PRs in open source projects, right? Like, that's definitely a level you, takes experience to get, to have the opportunity and the confidence and the experience to do that.

But if you're not, if you're not already somebody who thinks of themselves that way, there, there really are opportunities all around you all the time to do it, and you just have to really, find the chance to go for them. , what I mean by that is like, software is constantly broken all the time everywhere.

Right? Like, software is hard. you can't really work in software and not hit bugs on a daily basis in things. And so, each of those is really an opportunity. And, I mean, it certainly doesn't feel that way when you're like, God, there's just another one now. I'm like four levels deep in the act shape. but they really are an opportunity, and if you're trying to just grow into your career, I really would encourage you to Do the thing that feels like a waste of time, right?

It feels like a waste of time to go and understand this bug in something that you didn't write. the reason it matters, and of course, like, yes, you have to balance this. If you know that you're on deadline and you don't have time, you don't have time. But where you can. it is so worth it because the skill of debugging that thing, that code you don't understand, it is a skill that you develop and it gets faster and faster and faster.

and, but you would never develop it if you never try. And once you have that skill, it's like a superpower, right? You can just cut through a code base you've never been in and start debugging it right away. that is really like, you know, the most senior and experienced developers I work with that I really admire can all do that.

You pick up a brand new tool, things break in it, and you know, 30 minutes later, you know why they broke, and you have the PR, right?

[00:30:30] Robbie: right?

[00:30:30] Chuck: Well, and I wanna highlight an important, uh, aspect of that too. So yes, that and going down the path or whatever else, but I think it's a potential misnomer that if you start a PR that it has to end in success. Like don't get thrown off by the idea of, I think I have something here.

I'm not certain. And so I'm not going to open that PR. Actually, that opening that PR and even if it gets closed is a potential learning experience, potentially for both sides. So if you have an idea or a thought around trying to do something or contribute, whether that's a bug or a new feature or whatever it is, that doesn't have to end in your code getting merged.

It can end in a mutual learning experience. And then that takes you into a better place for the next time forward,

too. So

you don't have to be an Ember expert to contribute to Ember. You don't have to be a Vite expert.

[00:31:21] Ed: totally. Totally. And if you're just too introverted to share it, like, I mean, first, like, yeah, I'd encourage you to get over that, whatever way you can, but even if you don't, like, even if you just have maintained patches for your own use as a starting point,

[00:31:32] Robbie: that's

[00:31:33] Ed: not bad, right?

Like, uh, it's actually gotten, you know, tools like PNPM, uh, have this built in patching of dependencies now, which is kind of nice, kind of a nice feature. You definitely need it, need that some of the time. You don't want to go crazy, of course, because patches are a liability, open source is not such a controversial thing as it was 20 years ago, that open source is good.

So people don't realize that, , I think they often lose sight of why it's good, and they don't take full advantage of the cornucopia of open source we have around us, which is not just that you can use it. But that, like, you can tweak it when you really have to. That's so different from the days of proprietary software, where even if it's just like a one character bug in this thing you're using, you had to do some crazy contortions to work around that bug.

Well, now you just change that one character. Patch that character. Please patch your dependencies when they're blocking you. I mean, yes, it's great to upstream it. Yes, it's great if the maintainer's super responsive, and they merge a PR, and they cut a release immediately. That's all great, and we should strive for that, right?

[00:32:27] Chuck: But,

when it doesn't happen, it doesn't mean you failed.

[00:32:29] Ed: Exactly. When it doesn't happen, like, the whole, the whole reason it was good was open source is that you're not, you're not blocked, right? Go on your day, run against that, run with that patch, and, like, if you liked the PR, it, great, you have it now, like, run it, right? I'm not saying you should fork all your dependencies all the time, but, it's so nice to not be blocked, right?

You fix a bug that you needed fixed,

[00:32:49] Chuck: You can have it now and you can

[00:32:51] Robbie: that.

[00:32:51] Ed: you can have it right now, right? Exactly. You can have it right now, you should totally submit it for other people. Maybe they'll merge your PR, maybe they'll fix it a different way, and you'll eventually switch to their fix. But like, you solved your own problem, and it feels really good, and you got unblocked.

And it's so much cheaper to fix a bug at the right layer than the wrong layer. I think a lot of people, , are intimidated by going down a layer into something they don't know as much. But, um, if that's where the bug really is, you could do major contortions and add hundreds of lines of code to work around the bug in the wrong layer, or you could do the, like, one line change in the right layer.

[00:33:21] Chuck: or you could do the right layer. Yeah, I think that's an incredibly useful point, and you mentioned PNPM, which, you know, Rest in peace, Yarn.

[00:33:29] Ed: Ha, ha, ha. Yeah,

[00:33:30] Robbie: Yeah, Yarn has its place. I mean, the new version is similar to PMPM, but PMPM gives you more escape hatches to get out of the bad things.

[00:33:41] Ed: you want me to, you want me to trash stuff, I could talk about the whole package ecosystem. I

[00:33:46] Robbie: Please do.

[00:33:46] Chuck: Yeah,

[00:33:47] Ed: I, I think,

[00:33:48] Chuck: mean, you want you the booze so

[00:33:49] On PNPM

[00:33:49] Ed: Yeah, so exactly. You gotta get the rent to come out. No, I mean, I think PNPM maintainers are doing their best. In a lot of stuff I think they make the right choices. , They're trying to do rigorous things and make things correct.

And they're up against some impossible constraints sometimes. Getting package management right is one of the trickier problems in tech, because it's not a pure, it's a, there's definitely hard tech problems in it, but they're not, that's not the only problems in it. There's, to do a perfectly good package manager, you have to be good at, like, general software engineering stuff, and a little bit more of the computer science y algorithmic stuff, because there really are hard problems in package managers.

And you have to be good at the social aspect of it. Which is like, how are you going to get people to cooperate in a way that's productive?

[00:34:32] Chuck: I think, I think that's a job where reversing a binary tree is actually a good interview question.

I think it's the only time where that actually matters.

[00:34:41] Ed: That, well, I mean, that kind of stuff, exactly. Like, it's not, it is a punchline, right? That people get asked those questions and then go, you know, write yet another template or

[00:34:49] Chuck: Center this div.

[00:34:50] Ed: But, um, But that stuff really does matter. So I would in fact encourage anybody who has the opportunity to learn that stuff better.

You know, like computer science y stuff, algorithm stuff. It is absolutely worth it. And the reason why is that, yes you don't need it to write yet another login page, but, until you know it you don't notice that you had the opportunity to use that knowledge when it does come up. I understand why tools for JavaScript ecosystem tend to be written in JavaScript.

It's, it's a good decision. It means your contributors, you know, your users can be your contributors and all of that. But, uh, as soon as you cross that line into I'm building developer tools now, like, pretty soon you're gonna need some of that stuff, right? You're gonna be, oh, I'm like, I now have a big AST of nodes of source code.

How, what's the best way to traverse that graph? It's like, well, all of a sudden, if you do the naive thing, it's going to be horribly expensive, right? So, like, the computer science y stuff starts to come out. So, all of that stuff's valuable, and until you, if you don't know what you don't know, you won't notice that you should have known it, you know?

So, I would encourage anybody who has the chance to, to, you know, keep progressing on that aspect of your career and your knowledge. ,

[00:35:55] Chuck: Gives you more ways to find the answers, and I think that more than anything is what kind of gets you senior and above. It's not tenure, you know, because you can center dibs for 510 years. Does that make you a senior engineer? Maybe in your own context, but when you get out there. And at the end of the day, the really important things is that you have the tools and experiences to draw from to find the answer, because I don't know a lot of things, but I feel like I know how to find ways there and ask

[00:36:20] Ed: things that you have to experience. So like I know how to find those things.

[00:36:37] Robbie: write, like, a big, like, a two sentence description, like, what's the word for when blah, blah, blah, blah, blah.

[00:36:42] Ed: And, and, like, ChatGPT can probably tell you what the word was, right? And then once I've got that, that's enough now for me to, like, go the rest of the way. It's like, okay, I remember that's called, ChatGPT, remind me again, what's the difference between contravariance and covariance, right?

Because, like, I

[00:36:55] Chuck: it writes really good regex, actually.

Oh yeah. Oh Yeah.

I, I, 20 years, I suck at regex. Yeah. I put a couple things in there, and I get things that

[00:37:02] Ed: Yeah, exactly. So I'm, you know, people definitely find the sweet spots of what it helps them with, that they, that's their weakness. But for me, it's the, it's like, ah, yeah, like, what are the, what is the exact word for that thing again?

Because once you, if you, once you have it, then you can go and do the rest, right? But yeah, so like, we, we started talking about algorithmic type stuff because I mentioned it as one of the things you need to make a package manager. and you, and you do. And I think, um, you know, I think over time people have filled in some of the gaps with that stuff in the design of things like npm and yarn and pnpm.

A technology does set a, um, kind of a tone for how you expect people to collaborate in this technology. NPM's original tone was kind of like, everybody do their own thing. And that's really, causes a lot of pain down the road when it comes to package management.

And what, what I mean by that is, the default assumption in NPM was always that, If you want to use the library and some other package is also going to use that library. Like, it's totally fine if you get your own different copies. Because you're in your own little worlds. And all that duplication is no big deal.

Right? And for some things that's true. But for some things it is definitely not. trying to put that on the user to sort it all out. That like, this needs that version, this needs that version. How do I get them to reconcile? What do I do if they don't agree? Can I decide to give them both their own copies?

How am I even aware of this problem? Like, those are hard. Sometimes there's not a perfect technical solution, but there's, there is a good UX solution where you can explain things clearly to the user, tell them what their options are, and like, there was no effort in that area for NPM, and so we ended up with a real mess, uh, of just, it's very difficult to get certain things, where you really care about making all your packages play nicely with each other.

So like, as like a starting point for people to learn about this stuff, I'd say, how do peer dependencies work? Across the ecosystem is the, as a thing that is just why do you need them? Why do they exist as a concept? And how are they, how do they work and how should they work? it's a real weak spot.

That's not the fault of any one package manager client. It's, I mean, if you're going to blame anybody, you could blame the original creation of how Node thinks about packages. But like, it's very hard to reform now because it's not just purely technical. You have to do the good technical thing, but then actually get those changes propagating out through many packages.

So they'll... You know, they'll declare the right things in their package. And they'll, um, they'll say, they'll have the right attitude about their own dependencies and what they should say, you know. So, for example, there's really nothing in NPM that encourages you, as a library author, to express the widest possible ranges of what you depend on.

As a library author, that's a really good thing to do, right? Like,

updating it so that all your deps say, just, these are the latest versions that I, I happen to be using at this time, you're not helping your users as much as you could if you expressed like a super wide range, like, oh, I, my library actually works with like versions two through seven of this other library because it hasn't really changed very much.

The tools don't push you to say that stuff, mostly because for a long time that the activators themselves couldn't even take advantage of that fact to help your users out. You duplicate things so like. In both directions, there's no incentive to do the collaborative thing that's going to help your users the most, so it's just like a

[00:39:59] Chuck: yeah. And then, but then the a ask in that sense has been out into the community to say like, great, now you create a package to help me de-dupe and do these efficiencies because, you know, we've decided to go on a path of, we didn't think of that. Or it's more, you know, it simplify at the base and hopefully the users like come out and, and add that in a good, efficient way and you can choose which one you want.

So, uh, actually it's the reactive package managers

[00:40:25] Robbie: So

[00:40:25] Chuck: there's that in that

sense too.

[00:40:27] Ed: Yeah, it's just like some stuff is really hard to just choose your own adventure with, right? And like, uh, package management is just one of them. kind of thing where even just to analyze what's going wrong, I was recently debugging some stuff. , I don't know yet if this is an actual bug in pnpm or in some other packages declaring what they had, but I had a situation where...

there was confusion, right? It was like, how did I end up with three different copies of this package, where it really seems like there should be one, and they should all be on the same major version? you know, just to even understand the problem, because there's, like, so many things that depend on so many other things going out across this graph, you can't, like, debug it by hand.

I had to literally write a little program that would go crawling around and seeing what depends on what depends on what depends on what, and finding, like, where are all the things referring to this package? You know, none of the out of the box things to explain what was going on were good enough. I had to literally write a program, right?

So it's like, you're not going to ask every user to do that and solve that problem for themselves, right? we need to work together on some of that stuff. So it's just like, it's the kind of stuff that's too hard to do by yourself. You really need to,

[00:41:24] Chuck: Or you might not think about it. You don't realize it's a problem until well down the path, but I want to regress a second here and typically in the show, like at different times, I dear listener, I want to explain something to you and now I have dear listener and audience members. If you're awake, Ed mentioned that, , choose your own adventure.

Do you guys know what that is? So choose your adventure with these books, I don't know, I, I grew, I'm Gen X, I grew up in the 80s and you had a book and you would, uh, get to a point in the adventure and it would be like, if you want to do a thing, if you want to go to the left door, then go to page 24, if you want to go to the right door, go to page 47, and then you kind of decided the whole thing, and it was almost like a game because there were parts where it was like, and you fell off the cliff and died.

And then other parts where you get to the treasure. So, just wanted to take a moment to kind of explain that. Because there are different things. I'm sure Robbie didn't get

[00:42:13] Robbie: it.

Yeah, I had none of those. Yeah, none of

[00:42:16] Ed: Yeah, I suppose that

was a rough reference. Yeah, I mean, and I should probably, and that's what it's like, not probably a perfect analogy to what I'm talking about. What I

really. Okay, yeah, you

got it.

You got it.

[00:42:25] Chuck: I understand.

But it's just, there are certain points where I'm like, oh, okay, yeah. I often do it because of the generational difference there. And then, so I like to just explain that at

different

points.

[00:42:35] Ed: totally. Yeah, so I mean, I mean choice is, choice is still good. It's not saying, I'm not saying choice is bad, but it's really like, it's more about which kind of questions you ask people, right? Are you going to ask them a super low level question that they don't have the context to answer?

Or are you going to be able to synthesize the question for them so that you can ask them something meaningful to them? You could say, like, why are you asking? Like if somebody, if something's like, You know, this dependency is seven levels down in your graph. This conflicts with this other one, seven levels down in another direction.

Do you really want version two or version three? And you're like, how are you supposed to answer that question, right? You, you don't know. So you need, you need an explanation that's going to explain to you why, why does it matter, why, why are these things in conflict? And there is an explanation in there somewhere, right?

If a good system could do it, it could say like, well, it's because this particular package sees both of them. And it really says it needs to have only one copy because this is your renderer, right? You, you don't, you're not going to have one app that's rendering some components in React, one version and another in React, another version, right?

You, like, some things are truly global in an app, or like, really, you want them to be, right? So,

[00:43:35] Robbie: that kind of stuff.

[00:43:36] Chuck: I think you've explained why platform engineering has started to actually become a thing and it's because of, , and it obviously smaller companies or smaller teams, you, you try to manage all these things across the board as much as you can, your shipping product or whatever else. but it's inherently as things scale.

Like the thought process and the architectural decisions around all these or cleaning these things up later is difficult to work into a normal product roadmap, right? And then this is always the discussion about one, you know, two for you, one for me, because we have a product roadmap that we have a, a tech debt or, you know, just a technical roadmap that doesn't really exist in the org, but is really important.

And we keep kicking the can and we do a couple of things and we're trying to make these things realistic, but at a certain scale, you have to make it reality. So platform engineering is just actually evangelizing those things for what they really need to be and understanding that it actually helped.

It's making tools for the people who are putting out the buttons and the, and, and the other parts and the other features and the user feedback and all of that thing becomes a reality there.

[00:44:36] Robbie: when you

[00:44:36] Ed: for the term, are you referring to like, Companies having a group within the company that is responsible for that? Yes. Yeah, exactly. Yeah, no, I'm a big

[00:44:44] Chuck: it's basically DevOps five years ago, right?

[00:44:46] Ed: Yeah,

[00:44:47] Chuck: well There was always like IT ops and hardware and like or thinking about the scale of resources And then there's the delivery of that right and it's the middle ground of I'm creating an application and we have a pipeline We're thinking about getting out there and then where's the onus of that live and we've always sort of like hot potato back and forth and depending on the skill scope that you have within your teams and and but then they said Okay.

No, we're going to just make this someone's job. We're going to give that an actual description, and then everybody on both sides can be

[00:45:17] Ed: Yeah, no, exactly. I think most companies leave huge money on the table by not doing that. I think a good rule of thumb is like, if you aren't spending something like 5% of your developer people budget on the. The people who are gonna make all that other 95% of your developers day more effective.

, you're throwing money away. And so, if you're a 100 developer company, if you don't have a team of 5 people whose whole job is taking care of that platform level stuff, you're throwing money

[00:45:49] Chuck: Absolutely. 100%. Cause it's, they're trying to fake it till they make it anyway up until that point. Because I know, I've ran teams and had great relationships with product people and we have in the aside, we have business objectives and they're not seeing, you know, understanding where that is powerful.

make your hacky workarounds as you said before. You have a hacky workaround within the company. To kind of make that happen regardless of whether they're funneling real money into it and valuing it or not.

[00:46:17] Robbie: Yeah, I think a lot of this is

[00:46:18] Ed: said before.

[00:46:19] Robbie: we just don't have the right,

[00:46:20] Ed: You have a hacky workaround I think that we have titles like Software Engineer that just mean very different things depending on what you're doing. And it's true that a lot of the skills transfer, and so, like, there's something to it. It's not wrong that we have a title called Software Engineer and that means a certain skill set, but there's subcategories in there that are so different from each other that they really almost should be different jobs.

when we call them all the same thing, it makes it look to non technical management that, like, they don't realize they're missing a job function. So, for example, you know, if a company of a hundred people has absolutely no HR, like, they'd start to catch on that they're missing a job function.

And HR is there not because they're shipping direct customer value, but because they, it's generally recognized that your employees can't do their job effectively if they don't have the support of HR,

Right.

And this is just, this is no different than that, right? This is saying, like, if you're going to employ, A hundred developers, there's certain support they need, that if you don't have those people, you just aren't running an effective organization.

So it's great to hear people are trying to evangelize that, I like it, but that's absolutely how I feel about it. I think that's the ideal, is to like make a, a central piece of the company job function be that. I've seen it been used very effectively. At the same time, you know, I've, I've also worked on a lot of really small teams where it's, it, you can't make it a separate function.

It's gotta be instead a small part of each person's job. So then you, then you're, you're back in the land, the land of having to have that conversation. I think

[00:47:45] Robbie: it's a scale and

[00:47:46] Ed: there I do think, um, I would, on that

[00:47:46] Robbie: there I do think, um, I'm not

[00:47:48] Ed: front, I would always encourage developers, whether you're in the big org or the small org, to really think of yourself as a professional in the sense that, your stakeholder, your, your customer, your, your client, , they're paying you to do the software engineering because you understand the software engineering.

And there is a level of trust in that. Like, that's really, when you, when you look at what is, what does it mean to be a profession and to be a professional, that's really what it comes down to is like, are you expected to have knowledge that your, customer doesn't have and they've got to trust you?

You've got to build that trust. And as a software engineer, you definitely have some of that knowledge. Your client, your customer, your, your business representative. They don't know how bad endangered it is to completely ignore security or completely ignore upgradability so that you ignore security, right?

[00:48:35] Chuck: Yeah. You,

[00:48:36] Ed: as a professional, it's your job to look out for their interests in that way. In the same way that a lawyer is supposed to tell you you're doing something stupid. And an accountant's supposed to prevent you from going to tax jail, right? You're supposed to protect your clients and your stakeholders from making bad software choices.

Because they don't have the knowledge to know that that's bad,

[00:48:53] Chuck: that that's bad. And in as a subject matter

[00:48:55] Ed: Yeah, exactly. So it's, your job as a professional to, to take care of that stuff for them and build it into the cost, right? So it's, so it's, it's almost malpractice to present, say to somebody. Well, I could do your feature the dangerous way for this many dollars, or I could do it the correct way for this many dollars.

Like, a professional just says, this is how much it costs. I'm not gonna do it the dangerous way. I'm

[00:49:13] Chuck: Don't, don't offer the

[00:49:14] Ed: Yeah, I'm not gonna screw you. Now, and so obviously I get it that there's market pressure, reasons why, if you're like a client, if you're like a consultant bidding on a project, you've got pressure to try to lower the cost and stuff, but like, that's where you've gotta explain your value.

You've gotta be like, no, we're not the Fly By Nate guys, we're gonna do it right, you gotta trust us.

[00:49:29] Chuck: Right.

[00:49:30] Robbie: I was just going to steer us in a little bit different

[00:49:32] Chuck: direction.

I think

so. I was gonna say like, cause I bet people are getting hungry.

Well, I,

because I can

see that this is a slippery slope. We could have a whole, a whole show about that.

[00:49:42] Robbie: Yeah. So

for the last few minutes here, um, speaking of all these different jobs, what job would you have if you were not in tech?

[00:49:48] What would Ed do if not in tech

[00:49:48] Robbie: Oh, that's

[00:49:48] Ed: a good one.

I, I've thought about that. I might be like a, I might teach people math.

[00:49:54] Robbie: Okay.

[00:49:54] Ed: I don't mean

[00:49:55] Chuck: gonna say that I was like professor

[00:49:57] Ed: yeah, and I don't mean like in like a kind of typical classroom environment. I think I would go nuts there because I think I need my autonomy, but like I could see myself in some like, I don't know, some little independent school where you get kind of more of more autonomy or, um, or just like off on my own being a, like you said, like being a tutor or a professor kind of thing.

Yeah, I, I enjoyed that stuff. I, I find that, I find, um, math in particular endlessly fascinating. I, I studied computer science and didn't really, in my formal education, ever go super far on that stuff. And, you know, in the years since, kind of, like, learned a lot of it on my own, and it's just, it's fun. I like it, and I think I'm pretty, I do like teaching, too.

like, genuine teaching, like, not, I, I think there's a lot of really painful pressures that teachers in typical schools are under where they're, like, They have to do a lot of things that, where like, a small fraction of their day is the genuine teaching part, and then there's a lot of pain in the butt.

Like, I don't want that job. but when you get the chance to really connect with somebody, and work with them, and see them grow, and teach, like, I, I love that stuff. I'd like to find a job like that.

[00:50:58] Chuck: Nice. There's nothing wrong with that. I, I see you as the teacher type. You obviously have that already ingrained in, in you. so let's just say outside of tech completely and math, I'm gonna include that now. Okay. What other hobbies do you

[00:51:10] other hobbies

[00:51:10] Ed: Oh, I could teach people piano.

[00:51:11] Chuck: Nice. So there you go.

Didn't know. I

[00:51:13] Ed: Yeah, I love music. I've played piano since I was a kid. Um, I'm, I don't practice enough, so I'm really not that good now.

[00:51:19] Chuck: That's probably subjective. But

[00:51:21] Robbie: you're better than I am, I'm

[00:51:22] Ed: maybe,

maybe. I, I actually, no, actually I'm, I am very excited right now because my seven year old just like spontaneously expressed an interest in learning and I'm now like his piano teacher as of now.

And so like, you know, that's the kind of thing where it's just like, there's not a lot of things that I would call almost like, Sacred but like a kid who comes to you and is like I want to learn this thing right now. It's like Holy shit drop everything like that's that's when you got a strike, right?

And so that's a really happy moment for something that I love anyway Like music from your kid to come and want to do that. It's like oh, yes. I am ready for you I've been waiting my whole life for you to

[00:51:56] Robbie: have

[00:51:56] Chuck: Yeah, my kid hates soccer and it broke my, it breaks my heart right now. He's only six though, so there's still

time

and it's like, yeah, okay, well maybe later.

[00:52:04] Robbie: if he likes American football? Will you live?

[00:52:07] Chuck: I mean, whatever, but I will support, I will love and support him. Uh, and wife listens to the show, so I will love and support him. Well, whatever, even golf or baseball.

[00:52:18] Ed: the show, so I will love and support him. Even golf or baseball. It is a non profit though.

[00:52:33] Chuck: nonprofit though. And the N F L is a nonprofit, so

[00:52:36] Robbie: Is it really? Yeah, they don't make any money. The owners do.

[00:52:39] Chuck: do fine.

[00:52:40] Robbie: Yeah, alright, well we are about out of time. Before we end, is there anything you want to plug or anything we missed covering?

[00:52:46] Chuck: Next jss or something like that? No.

[00:52:48] Ed: Next. js? I mean,

I guess I'll just tell everybody in the audience to be like, uh, to be curious and just, like, dive into that bug, dive into your dependencies, and don't be somebody who just passively accepts the software you're handed.

Like, go pull it apart.

[00:53:03] Robbie: Cool. That's good advice. Yeah, so, uh, thanks everyone for being here.

Thanks everyone for listening later. Uh, if you liked this, check us out on, uh, everywhere there's podcasts. Uh, there's plenty of extra whiskey over here if you want some.

[00:53:17] Chuck: round if you would like it before lunch or carry around

[00:53:21] Robbie: if you have questions for us, you know, feel free to ask. We're around.

​