Yoav Ganbar joins the Jabber crew to discuss Dev FOMO. He leads the panel through a discussion about adopting technologies and knowing about new niches. The panel discusses how to stay on top of the movements in our ecosystem and when we should prioritize other things.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Yoav Ganbar.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from 100% humidity. 

CHARLES MAX_WOOD: Dan Shappir. 

DAN_SHAPPIR: Hi from Tel Aviv where we've got great weather. 

CHARLES MAX_WOOD: Amy Knight. 

AMY: Hey, hey from Nashville. From a sick house. 

CHARLES MAX_WOOD: Oh yeah. I've got four sick kids at home here too. I'm Charles Max Wood from Top End Devs. And this week we're going to be talking to Yoav Ganbar. Did I say that right? 

YOAV_GANBAR: Yeah, that's pretty right. A gonbar or a ganbar, depending on your pronunciation. 

CHARLES MAX_WOOD: Do you want to introduce yourself real quick? Let us know who you are and what we've been missing out on. 

YOAV_GANBAR: Well, I go out. I'm from Tel Aviv as well, so I can attest to what Dan said. And it's pretty sunny and warm and nice. Although I got a little cold though as well. Yeah, I work at Fiverr. I am working on a new platform that we're building so I can't say much about it. But I'm a technical lead here at Self-Project Tech. Yeah, and I've been in the startup game for about seven years now, give or take. Yeah, I love to code live in it. 

 

Have you ever really been happy with your project management tool? Most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant prodding. Shortcut is project management built specifically for software teams and their fast, intuitive, flexible, powerful and so many other nice positive adjectives. Let's look at some of their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they work. Org-wide goals and roadmaps. The it takes one click to move from a roadmap to a team's work to individual updates and vice versa. Tight VCS integrations. Whether you use GitHub, GitLab, or Bitbucket, Shortcut ties directly into them so you can update progress from the command line. Keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly as their power bar, allowing you to do virtually anything without touching your mouse. Throw that thing in the trash. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burn-down charts and other reporting. Give it a try at months free. Again, that's shortcut.com slash dev chat. Shortcut because you shouldn't have to project manage your project management. 

 

DAN_SHAPPIR: I hate to burst your bubble, but I don't think you can call Fiverr a startup anymore. You're like worth like like public company worth $10 billion or something. 

YOAV_GANBAR: Yeah, well, we're kind of the product we're building is in startup mode. So that's why I like to say it's still the startup game. We're a small team just building something the whole infrastructure we got here. So we're building our thing from scratch. 

DAN_SHAPPIR: That sounds like a dream job. 

YOAV_GANBAR: Yep. 

CHARLES MAX_WOOD: Very cool. We brought you on today to talk about FOMO. 

YOUAV: Right. That's FOMO. 

CHARLES MAX_WOOD: Isn't that a four letter word? 

YOAV_GANBAR: It's a four letter word. Yes, it is. I want to add three more to that. And that's DevFOMO, which I'm trying to call in because FOMO is something that I think everybody knows and lives with. But as developers, I think there's so much more. Like little nuggets of FOMO that we have on a daily basis, which just like sometimes block us, sometimes drive us, and to each is his own FOMO. 

DAN_SHAPPIR: I'd like to clarify exactly what you mean by FOMO because obviously as techies, we need to make decisions all of the time. Choose between platforms, choose between frameworks, choose between whatever. So are you talking about that FOMO that is related to this constant need to choose, you know, make technical decisions, or are you talking about something else, something wider? Can you clarify what you kind of put in this FOMO category? 

YOAV_GANBAR: Categories. All right, well, maybe we should start with what actually is the definition of FOMO. So FOMO is like we stated, this fear of missing out. And I'm gonna quote like the Wikipedia definition I've got in front of me. And that is the anxiety stemming from the belief that others might be having fun while one is not present. FOMO is associated with a fear of regret, which may lead to concerns that one might miss an opportunity for social interaction, a novel experience, a memorable event, or a profitable investment. It is characterized by a desire to stay continually connected with what others are doing and can be described as the fear that deciding not to participate is the wrong choice. So this can play to a lot of things. So specifically as techies, of course it is about the choices we make about like what frameworks we use, like whether we do backend or frontend or what languages we learn or what languages we don't know and want to kind of learn about. It's like these little niche spaces that we might not know about that we feel like we gotta be there and we're missing out on not being right there. So also because this ecosystem is just gone and became like booming in every direction. So it could be even like, I didn't listen to that podcast episode that was on JS Jabber with, I don't know, whoever. And I missed that conference that somebody introduced this new feature to react, for example. But I like went on Twitter and tried to understand like what FOMO means to different people? Well, I didn't get too many answers, but I've got some that are interesting. If you'd like, we could go over it a little bit and see what it means. But I think for each and every one of you, it'll be something different, or there'll be some specific things that are more bigger fears than others. So I wonder, do you feel like you're missing out on something, Dan?

DAN_SHAPPIR: For sure. When you posted that question on Twitter, and I was trying to think about what I would think about when considering things that I might be missing out on, one of the things that immediately came to my mind was even the places where we work. Especially at this time in tech, it seems like everybody's jumping around or over the place, switching pretty explicitly that given the current state of our market, if you haven't switched jobs in the past 12 to 18 months, then you're probably underpaid. And we've got all of these new companies springing up in really hot technology sectors like Web 3, whatever that means, and blockchain, and machine learning is starting to get old, but it's still really hot, and so on and so forth. So I think that one of the big FOMOs that I'm seeing literally has to do with where you actually work. Do you switch jobs just because there might be a better opportunity out there? Do you stay with what you know? Maybe you leave and then the company that you left will suddenly succeed and what will happen to all the stock options that you leave behind. This kind of feeling that the grass is always greener on the other side, but it might be true once you move to the other side. So that's one of the big FOMOs that I'm seeing. 

YOAV_GANBAR: Yeah. Well, it's a funny story. Actually, I got a chance to talk to Chuck, what was it, five months ago, like through the DevHero's accelerator thing that he keeps on promoting, which is a pretty cool thing. And you should check it out. So we had this conversation. And it was kind of at a turning point, exactly. So I was working for a startup in the fintech industry, which was it's very promising and was making money already, but I wasn't feeling like the drive and the passion of being in that ecosystem of finance and making products for banks and stuff. So at the time when I talked to Chuck, it was like I had some interest from a very interesting tech company that has to do that builds developer tools. And I was kind of just trying to get advice and what should I do? I was sitting in a good position. I was getting good money. I had stock options, like, sorry, options ready to be matured. And I was like, well, do I make a move now? I won't get my options now. Maybe I should do something else. Just sit tight, work on my personal branding, work on getting better and some stuff, try and speak somewhere, publish more articles. And you know, and Chuck was like, I don't know what to tell you. And then it was funny because about a few weeks later, then I got approached by Fiverr. They kind of enticed me to come and build this new thing around an industry that interests me and to have the ability to kind of make an impact, which is something that is also important to me. And while at the other company, the impact that I was making was pretty big, but still didn't feel building something disruptive or building something that will make the world a better place. So it's also that kind of feeling. And as I recall, you were saying also about being in the right company. What does it do? What are the benefits that it's bringing the world? It's also something that lives in our minds. You want to make the world a better place, I guess, like most of us at least some of us just want to make money and then go to web three or something like that, you know, or start collecting all kinds of NFTs. Yeah. So I completely feel what you're saying and specifically about like being in the right place or missing out on a better, bigger salary, more stock options, better work life balance. It's like this constant need and tug of, tug and pull of we keep on being confused all the time. You keep on chasing the next big thing, the next thing that'll make you better make you feel better. So it's in almost everything, like I said. 

DAN_SHAPPIR: Yeah, for sure. And obviously, as techies, there are the technical choices. Recently, I've been thinking about some technologies that have been very hot in the front end world not so long ago. And all of a sudden, it seems like nobody's talking about them anymore. Like, for example, Elm you know we've had several guests talking or coming on this uh show talk speaking about them it used to be a really this the huge hotness and i don't know I’ve at least have not heard anything with regard to elm in the in the past couple of of months it kind of seems like uh typescript came along and and eight uh every other transpiled uh... language and you know everybody's either just using typescript or javascript and not the other flavors that are out there. Or, you know, I know that a lot of people are definitely using GraphQL, but not so much chatter about it anymore. At least it seems to me like that. So maybe it's because it's becoming mainstream or maybe because starting to, but not such a new hotness and falling out of favor. So one of the big things with FOMO, it seems to me, is that if it's a driving factor for you, you end up skipping between a lot of companies and you end up potentially skipping between a lot of technologies just trying to chase the latest fad and Then you know six months later. There's something new comes along 

YOAV_GANBAR: exactly that's exactly what I'm talking about like even in your episode every time you kind of bring on a guest He's talking about this new techies with or a product. He's building or like specifically like front end is it's a jungle like the speed in which like new frameworks pop up is just astronomical. So, and I remember this, this article from what was it back in 2017 or 18 about JavaScript fatigue, like the whole too many options with Angular and React then, and then you coming along and nowadays you got Svelte and Alpine and Solid and Astro and so many that keep coming out. Like I also remember that Marco once had like a big fad about it and it just keeps on coming. And think about like the big promise of the web of like the frameworks and building UI was web components. Where was that? Like that was three, four years ago. Like this is going to change the industry. And nowadays, like, again, it's, it's there. It can be used, but I don't think anybody's kind of fearing they're not getting, not there. You know,

AJ_O’NEAL: I think part of this is human nature. I think part of it is economic forces. If something is stable and it works, it's very unattractive from the economic perspective. How do you market something that just works? How do you market something that doesn't need improvement? So I've had the same thought. There's so many technologies that were created that actually solved a real problem, a problem that we have, a problem that is not just made up for the sake of exploring something new. But by the time it got through the standardization process, no one cared anymore and people moved on to creating a problem that was already solved so they can solve it in a new way. So I don't know what your thoughts are on that, but I think part of it is how the heck do you market something that you make money off of something being new? You don't make money off of something working well. 

CHARLES MAX_WOOD: I don't know if that's necessarily always true. I mean a lot of people, they really do want a stable solution. But the thing is, is that what I find is that developers are looking for something new, something interesting, something challenging. And a lot of times you hear about some new technology and that seems to be the thing that gets people going. So for me, I'm always looking for a new adventure, a new journey to go on, a new thing that I can go and explore. So that's my nature. But when it comes down to hey, I'm gonna do this thing or that thing. I'm looking for something that is stable, that I can rely on, that I don't have to think about in certain areas so that I can go and have my adventures in other areas. And so I think it really depends on the personality of the people you're talking about, and I think it depends on what area of their life you're looking at as well. 

AMY: Kind of going off of what Chuck just said, I think too, like, we need to make the distinction that, like, you're in control of this FOMO. Like, it's not at least my personal opinion, I don't think it is your employer's responsibility to keep you entertained. Like your employer has an objective. They're trying to make money. You are their employee. If you can learn stuff on the job, that's awesome. But that is not their primary objective. And it's like completely under your control that if you see something that you want to dive into that you can take that upon yourself and do it in your downtime. And maybe you even bring something like that to work and you be the person at your job that presents a new solution to things and can champion that for the team. Anyways, 

AJ_O’NEAL: I want to push back on one thing there. I think that you should be building in time to be learning at work. I don't necessarily think that needs to be FOMO learning, but I think too many people complain, oh, my employer doesn't give me time to learn. Well, that's what you should be doing. That's just part of the work. 

AMY: And I agree with that to an extent.

CHARLES MAX_WOOD: I agree as well, but a lot of employers don't see that as a necessary part of the job. And so what you wind up doing is you wind up doing it on your own and you've got to figure out whether or not that's something that's important to you that they offer or not. Because ultimately your employment situation is an agreement between you and them. Right. 

DAN_SHAPPIR: At the end of the day, if I can just interject Chuck, does your employer really look over your shoulder like every minute to know what you're doing as long as you're working on your project. And I think we discussed this in the past where I said that in the context of learning, just build it into your schedule. And I don't think you'll get a lot of pushback on doing that. 

CHARLES MAX_WOOD: I agree. 

DAN_SHAPPIR: I think that most people are just too worried to actually do it or they feel that if they don't deliver in time, then especially when they're juniors that get a lot of pushback and get in trouble. But realistically, if your timeframes make sense, and if you factor in learning time, at the end of the day, it will actually benefit everybody because you'll actually probably be able to deliver faster by the time the project matures. 

CHARLES MAX_WOOD: I agree with that as well. 

AMY: There's a fine line because, you know, you want to, if we're talking about like on the clock and players time, like it needs to be a solution that helps the team, helps the business. And you can't just toil forever. You do need to produce something because that's what they're paying you for. But yeah, I feel like, I don't know, some of the developers that I really respect and look up to in the community, they've always told me stories about how they wanted to have something new at work. They wanted to work with something new and they just kind of took it upon themselves to. Sometimes, you know, you have deadlines and you don't have the time at work, but they took it upon themselves to spend their free time really learning something and then they can kind of be the champion for that on their team. And I'm sure it's like a very rewarding experience. 

YOAV_GANBAR: Yes, sorry. 

DAN_SHAPPIR: No, I was saying that I'm going to throw a hand grenade your way and then perhaps for the entire panel here. Do you think that the, can you name specific technologies or stuff like that, that you think are successful because of FOMO? 

YOAV_GANBAR: Interesting question. I'd say yes, there are probably a few that are successful because of FOMO. I guess I'd say Tailwind is one of those. Like people have been chatting so much about it. 

DAN_SHAPPIR: Now you're in trouble. 

YOAV_GANBAR: Like, yeah, I'm in trouble. I love Tailwind. I'll say that off the bat. I use Tailwind with Twin Whackrow and it's really, really made like the development process so much easier for me in terms of just sorting out the stuff with CSS. It's just building responsive pages with that is just incredible reading. I like what was it a month or two ago, I had to kind of just make a responsive page from something that was only designed for desktop and it like took me less than an hour just to add a few of the made-to-crease, the MD, the XS. Boom, it was incredible. 

STEVE_EDWARDS: Why do you say that's associated with FOMO then? I didn't see the link. 

YOAV_GANBAR: No, no. So because like Tailwind specifically is, is this technology that a lot of people have been talking about for, for a long time, like right now it's a version almost three, I think is the reason beta, I'm not mistaken. I remember Adam Laffin reading something else that he's working on it. So people were like saying. I don't want to try a new CSS framework. And this again comes back to the not being there with where the flow is going. So if you think about like the old bootstrap days, like on one hand, people would say a bootstrap is, makes every site look as it is, but looks the same. But then again, like the industry was demanding bootstrap. So people who didn't know bootstrap were starting to feel that we're missing out on this great tech that's being adopted by everyone. 

AJ_O’NEAL: It seems like React now. 

YOAV_GANBAR: Yeah. 

STEVE_EDWARDS: That was where I was going to go. To me, as a developer and looking at the ease of developing with something like Vue, and I admit I'm going to be biased, versus trying to develop with React speaks more to FOMO and that, oh my gosh, it's Facebook, it must be awesome. Everybody in the employer see that, oh look, here's this great framework. Everybody's using it, so let's use it for our framework and require all our new hires to learn React. Whereas if you sit down and look at ease of use and some other tools, I would think that if it wasn't backed by Facebook or if it didn't have a lot of momentum, then it probably wouldn't be as popular as it is. You know, that's just my not so humble opinion. But I see React as definitely being driven by FOMO. 

DAN_SHAPPIR: Are you sure? Because I'm not, I'm not sure. Yeah, for Svelte, I would agree that it's a lot of FOMO as well. I think that a lot of stuff in Svelte is great. There are a lot of things that I'm seeing in Svelte that I really like, but it's not a contradiction. I mean, a technology can be great and there still can be a lot of people that are coming to it because of FOMO, because they don't necessarily know why it's good. They've just they heard that it's this new hotness and they don't want to miss out on it. But in the case of React, are you guys, you know, do you still think it's FOMO? I feel that React these days, it's more about the front end trying to kind of standardize on something. You know, regardless of whether you think it's good or bad, it's, you know, a lot of people are learning React because that's what they're being taught at boot camps. So it's not like they chose React because they fear missing out on React, they chose React because, you know, it's been chosen for them. 

AJ_O’NEAL: Well, 

YOAV_GANBAR: it's because nobody was fired for choosing React. 

AJ_O’NEAL: That's unfortunate. 

CHARLES MAX_WOOD: Isn't that a kind of FOMO? Yeah. I mean, to a certain degree, right? It's a safe choice. It's a little different than going out and picking up a new technology because you're afraid you're going to miss out. But it's fascinating too that, yeah, 

YOAV_GANBAR: it's a safe decision for the business as well. So for example, when I started up this project, like I was the one that kind of decided on tech stack. And just because of FOMO, I was like, I really have an inkling to use Svelte. And Svelte kit was just draining, gaining traction and was like, oh, this is going to be really interesting. But then I get I really wanted to do it, but the safer choice was to say, this might be risky. Like we're bringing on a new team. They probably wouldn't know it the time to kind of train them and get them up to date and up to speed on how to use it. Granted, it's not in my opinion again. It's not so hard to kind of learn to Svelte, but it's not a right choice. Like in terms of, I didn't let the FOMO like beat me this time. And I say, I'll go with the safer choice that is React. 

DAN_SHAPPIR: I have a question about that though. I mean, in most cases, at least according to my experience, the people who make the technological that the choice of the framework choices aren't juniors, they're usually seniors. And these days, should seniors really be concerned about being let go? 

CHARLES MAX_WOOD: I mean, it's interesting that you bring this up because I mean, just because the today's market is crazy. And in the market that I'm sitting in, I mean, I've got people coming to me all over the place saying, Hey, you've got these podcasts, you know, you talk to people, we need people like we're hiring dozens of developers in a lot of cases. Right. So in this, in this environment, probably not, but yeah. 

YOAV_GANBAR: So you were asking about tech that gives me FOMO like specific one. I think Denno is one of those kind of technologies that really are starting to give people some FOMO. It's more secure. It's all TypeScript, it's written in Rust, it's kind of changing. It's Ryan Dahl built it after he built Node. That one is like really kind of making me starting to feel like... Yeah, 

DAN_SHAPPIR: but do you actually know anybody using Deno? 

YOAV_GANBAR: And I think it's Deno. 

DAN_SHAPPIR: Deno, sorry. 

AJ_O’NEAL: Yeah, yeah, it's Deno. It actually is Deno, but I call it Deno because that's what it should be called. Sometimes the authors get it wrong.

YOAV_GANBAR: But it's like the beat fighting. 

AJ_O’NEAL: I don't know. Yeah. 

CHARLES MAX_WOOD: Oh, there we go. You know, one thing that's interesting that you brought up there though, is that, Hey, it's got these things going for it. Right. Usually it's not FOMO because, or it gains some of this FOMO around it because it's nifty, right? There's usually something to it. Right. So you see people making the decision to go check out deno, Dino, whatever. Right. Because it does have these characteristics, right? There are real trade-offs that we're looking at and going, yeah, the security is important, right? Maybe the performance characteristics are important. It's not just, hey, I'm just gonna write this thing off as a fad, and I've done that before and then turned out to be very wrong. So it's also interesting there just in the sense that, hey, it makes things easier or has some other characteristic that makes you look at it and go, if I don't pay attention to this, am I going to miss the boat? 

YOAV_GANBAR: For sure. 

DAN_SHAPPIR: I think TypeScript is a great example where it was FOMO in the beginning, and then it really quickly became mainstream. 

CHARLES MAX_WOOD: I think that was driven by some other forces, too. I mean, Angular standardized on it pretty fast. So that whole community moved over to it. And then I think there were some other factors in other communities where people started picking it up because they liked it. 

AJ_O’NEAL: Well, TypeScript came out of Angular. TypeScript is an extension of AtScript. 

DAN_SHAPPIR: I don't know if I would say that because Angular is a Google project and TypeScript is a Microsoft project. So just that shows that, you know, this statement is kind of problematic. 

AJ_O’NEAL: Well, it's not problematic because Google handed it off to Microsoft and then adopted it because Microsoft was taking AtScript further and then Google reintegrated TypeScript. This was just, there was a, I mean, maybe I'm remembering history wrong, but we were there guys. We went behind you, 

DAN_SHAPPIR: aren't you the guy who basically said the TypeScript is just C sharp? 

CHARLES MAX_WOOD: Well, Microsoft was already working on TypeScript while Google was working on AtScript. And what happened was they were able to put their heads together and get most of what they wanted from AtScript integrated into TypeScript. And so then they just adopted TypeScript. 

YOAV_GANBAR: What are all those people that chose Flow and then TypeScript 1, they missed a boat there. 

AJ_O’NEAL: Well, so I wanted to go back to the thought of FOMO versus something being useful. And I think there's a clear distinction will arise there. Well, maybe not. I think FOMO is driven a lot by marketing and social media and TikToks or whatever. And something being useful often, I think it's rare that something useful generates FOMO. I don't think anybody had FOMO about Golang. And now every web service that you use is built on Golang infrastructure. And some of that infrastructure that performant enough or rather that Go cannot provide the maximum performance and maximum profitability is being written now in Rust. So Amazon is switching over a lot of their their infrastructure stuff to Rust, because they can eke out another maybe 50% performance on bare metal. So things such as Go and Rust are actually useful. And I don't think of people, and maybe I'm just not seeing it correctly. But I don't think of people going into Rust because they have FOMO. It seems they go into Rust because it's that it has distinct advantages. And the same Node.js was maybe a little bit in the middle ground category because jQuery was known to be useful and this was generating hype for JavaScript. And then Node came out and it was more of a confluence of Node came out when JavaScript was riding a hype train and there was a lot of FOMO. And back then I think there was even more frameworks coming out every day than there are now. There's just more people to be annoyed by it now. Um, but node was useful. It solved a problem that was not solved in Ruby or in Python, et cetera. But I do, I think, I don't know. I, it seems that you should be able to distinguish a little bit between something that's, I don't even know if we're using the word FOMO correctly anymore, but FOMO hype versus it gains popularity because it solves a problem.

YOAV_GANBAR:  I wonder what would happen if we would have made it a drinking game. And every time we said the word, we would have had to take a drink. 

CHARLES MAX_WOOD: I know. Right. Well, I think. I think there's an interesting discussion to be had around what AJ's talking about. I think, I don't think it's rare to see something generate FOMO and also be helpful or useful. But because the FOMO is usually generated around messaging and how well people can articulate the problem that it solves versus, you know, something's utility will be proven out over time. But at the same time, how do you determine whether or not, yeah, it's a hype train or it's a useful thing to go and learn, right? How do you figure out, and I have my own thoughts here, but I'm curious to see what you all think, how do you look at something and say, hey, there's a lot of hype around this because it's something I should look at because it's helpful and it's gonna solve specific problems that I have, versus there's hype around this and if I don't go dive into it, well, in two months, it's not gonna matter. 

DAN_SHAPPIR: I definitely think that there is no that something being popular because of FOMO doesn't mean that there's no usefulness in it or that it doesn't actually solve real problems. If it doesn't, then the FOMO will usually die out really quickly and people will just move on to the next one. I would like to give an actual example of this, and I think that's Svelte. I think that the initial, there was a lot of hype around Svelte, simply initially because of Rich Harris. He's a great speaker, he's got a lot of charisma, he makes amazing points, he's a really smart guy, and he comes across really well, and he was intentionally harping on specific aspects with other frameworks that other people found painful and offering something that appeared to be a really attractive solution. So I don't remember, you know if you remember, but at the time more or less whenever some benchmark came out around React or some state management that uses React, he would more or less immediately publish on Twitter a link to a benchmark where he essentially wrote the same thing in Svelte. And it would somehow be half the size yet run twice as fast. So he was doing some amazing marketing work around Svelte and generating a lot of formal for Svelte and kudos to him because he brought a lot of people into that technology, into that framework. But Svelte persists, I think, even though that phase is essentially over because there's a lot of value and validity and benefit in that technology. 

YOAV_GANBAR: Well, you make an interesting point about FOMO being really tied with marketing tactic, let's call it that way. Because if I think about it, the big things that are resonating in my head about that is, like you said, Rich Harris. So I look also at React Query by Tanner Lindsay. That's also gained a lot of traction because he's been going on and explaining how state management at React is broken and how we're actually just doing server state. And you take it to like other providers of other technologies like the cloud infrastructure. So you got Bursall and Garry Moral talking about like, what we do is give the best developer experience. Like if you're not on our platform, you're gonna have a hard time, but like shipping things really quickly and iterating really fast. So yeah, it is kind of really embedded marketing practice, I guess. And I guess, like, I wouldn't say, like, developers are much more susceptible to that, but it is an interesting point there. 

DAN_SHAPPIR: I recently encountered another example of this, I think, and that's around Remix.js. We probably should bring somebody to talk about it, either here or on React Roundup, but they got this huge buy-in from Ken C. Dodds, who essentially rebuilt his own website, like this big project that he now is documented and documenting and speaking about using Remix. And it was in this situation where everybody was thinking kind of that in the React world, Next.js kind of won. And if you're going to build a React application and you needed the server-side rendering or static-side generation or whatever, then you're going to be using Next.js as your application framework and all of a sudden Remix is starting to give them this big fight. And I think at this stage, it's still very much in the FOMO stage. And I think that a lot of this FOMO is because, first of all, the fact that Remix itself was created by some fairly known people like Ryan Florence and Michael Jackson, but also very much because it's getting so much promotion from Kent. 

YOAV_GANBAR: I wonder though, like something I know about myself is because of this constant FOMO I have from like all, not only like new tech for developers, but like new services and products. Like I find myself that I go around and like I sign up for like any service that I find, new products. Like I go to product hunt and like find a new thing or it looks cool. Oh, I sign up for the beta or the waiting list. You guys like have that too. You kind of feel that it's driving you. It makes you going to check out stuff out of curiosity and this fear of not being the cool kid that knows the new stuff. 

DAN_SHAPPIR: I'm too old and jaded. 

YOAV_GANBAR: I don't think so, Dan. 

DAN_SHAPPIR: Also, my wife doesn't let me spend money on stupid shit. Sorry for my French. But yes, I don't know. I'm less interested in most of these sort of things. To be honest, I don't know. Maybe it's something about me that kind of differentiates me from others people in this field.

 

And I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want, right? So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever. I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there. And we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

DAN_SHAPPIR: But I'm also wondering, Yoav, can you recall a technology or a product or a service or whatever where you really bought in big time because of FOMO and then were, you know, felt really disappointed or even burned? 

YOAV_GANBAR: Well, yeah, it's funny you mentioned that. This is actually something that kind of came full circle today for me in some sort of ways. And that is specifically authentication as a service. So we kind of, our platform that we're building needs, of course, authentication, authorization, all that fun. And because of good marketing and because I've had an okay experience with the service, I'll name it, yes, Auth0, I went on and kind of said, okay, we're gonna do because I know they got all these features which are going to be really good for us in the future. Right? So we have like, first of all, it has all these wrappers. So we use Next.js and it has a wrapper for Next.js. We just plug it in and then you have some functions that do it. That's great. And it has roles in permission management, in the user management, and connected to a database. So all these great features that are offered. But then at the end of the day, like at some point we had some bugs or some stuff we didn't understand about what's going on or how to kind of enhance some of the features or functionality we wanted inside our system and our platform. And we kind of like me and my team, we looked at it and said, what are we going to do about it? Like, should we roll our own authorization solution? Should we not? Should we choose another solution? So what happened in the end was like, one of my teammates just said, screw it. I'm going to go with something else and we went with NextAuth, which is kind of hand rolling your own authentication, but like it has the helpers to do it. But then like that is something that we've been like busy with for the past two, three months. Well, it's all kinds of little bugs and stuff that we couldn't. And that was a bite in the ass for us. And just now we kind of deprecated our use of WattZero. I hope that it'll actually work tomorrow when we look at like the PR that we opened up. But yeah, that was fun for me. 

DAN_SHAPPIR: But was that choice of Auth0 because of FOMO? Or was it because it was actually what seemed to be the safer choice? 

YOAV_GANBAR: It's both. It seemed to be, on one hand, a safe choice, but on the other hand, kind of, I don't want to miss out on a product that has figured it out better than I can figure it out. You know what I mean? It's like they have the features, they battle tested it. I don't want to miss out on them having the tests, the updates, the security. They were bought by Okta, which was another big identity management platform. It's kind of the one, I was fear of missing like the cushion, like you were saying about React. Yeah, they're backed by Facebook. So it's that kind of that feeling of security, I guess.

AJ_O’NEAL: So I, Kenzie Dodds actually tweeted about how he chose to go back on his, he ate his words of don't write your own auth framework and wrote his own auth framework. And I was really glad that he did. And he talked about the benefits that he got out of it, which mostly for his, from his perspective was performance because then he wasn't adding extra latency and having all of these switchbacks and forth between these different domains. But I think there's a lot of parroting that people do where someone smart said, don't roll your own crypto. And what they actually meant was don't invent new cryptographic algorithms because most likely you're going to get the math wrong. And what people took it to mean was don't import crypto or use web crypto or use node crypto or do anything to learn about cryptography at all. Which was not what that was meant. And then it.

transferred over into don't write your own auth, which granted it is difficult to write auth, but you get a lot more control over the user experience. I mean, there's just a lot of pieces to it. And then if your users are an important part of your product, you probably don't want to outsource your users to another service. 

CHARLES MAX_WOOD: So I want to just jump in here because I when we talk really feel like FOMO to me, right? I don't feel like I'm missing out if I pick off zero versus rolling my own, right? I'm making a calculation on the risk that I'm willing to accept and the work that I'm willing to do, and then I'm gonna make a judgment call. For me, FOMO is, if I don't go and check out or adopt this new technology, is it going to impact my career or my reputation, or am I going to miss the boat in some other important way as opposed to some of these technical decisions where we're making a decision between two trade-offs. 

DAN_SHAPPIR: I think I have a good example of FOMO that actually also happened, I won't name names exactly which group, but happened within Wix. And that's using GraphQL. I think GraphQL can be an excellent technology for some use cases, but there are a lot of use cases where RESTful API is still the best choice. And I think that there have been, I can think of several cases where people chose GraphQL where they should have used, just went with the actual, the safer choice of a RESTful API because of this sort of a FOMO around GraphQL. And they ended up adding a lot of complexity into the product that was essentially unneeded. Like if you're collecting data from a lot of services together and pulling data from here and there, and then merging this data together and trying to align it and creating these really sophisticated structures, then GraphQL might be an amazing choice for you. But if you're just making a query against this one particular microservice and it's pretty straightforward, then using GraphQL can be a huge overkill for what you might actually need. And like I said probably adding a lot of complexity. So for example, at Wix, we are almost, it's almost always RESTful APIs internally, but there's this one service that's using GraphQL. And so much of the infrastructure that we're building around optimizing the workflows and the data transfer and so forth just doesn't work with that service because it's on GraphQL and it's gotten to the point where we're now actually talking about, okay, let's ditch GraphQL for this service and just go with the restful API instead. 

STEVE_EDWARDS: Yeah, it's interesting you talk about that, Dan, because I was in that, I think that's one of the cases where I did fall into the FOMO trap with GraphQL, because I was at, in my previous employer, I was the primary, the only, view developer on a pretty important configuration app for our backend service and I was dealing with RESTful APIs to a Java backend and I got really frustrated with some of the limitations of REST and there are some very frustrating limitations with REST that I think GraphQL can address. And so I convinced my employer to let me go do some training. I went to a JavaScript conference in Seattle and got some training and unfortunately I was, me and many, many other people were let go before I was able to actually do anything with it. But in retrospect, I think some of it might've been FOMO and some of it might've been driven by just frustrations with REST and its limitations with what I was trying to do. But yeah, I could see how GraphQL could fall into that category. One of the things I learned about it, and it was interesting listening and reading about GraphQL to that point, everybody was like, oh yeah, you just plug GraphQL in and you can query your endpoints and limit what you get back and specify. You only want this back and so on. And it's all one endpoint. But what everybody failed to mention was that you still got to write a bunch of backend code. You got to write your resolvers. You got to write, you know, the responses to those data queries, but the, the way it was always positioned and everything that I had read and heard was, yeah, you just dropped your FQL and it works like magic. Well, no, it doesn't. 

AJ_O’NEAL: Well, for the front end people, it does. I think that. If you ignore all the complexity of the backends, the auto completion on the front end with GraphQL is really great. 

STEVE_EDWARDS: And the tooling, absolutely, it's fantastic. 

AJ_O’NEAL: And Graph Curl is cool too. So if we could get, with that one, if we could get similar tooling for REST APIs and just have some similar standards of, hey, here's the way we're going to use parameters, here's the way we're going to use query strings, here's the way that we're going to structure the ownership of the what do we call it entities or collections? You know, you could get that with rest but it again It's not easy to market something that is old and stable. So it graph QL really had a great opportunity to create a new wedge in the market to grab that it wouldn't have been as I don't think it would have been successful and I think somebody had tried this to say I'm gonna make a great improvement over rest versus saying I'm gonna make an entirely new thing

CHARLES MAX_WOOD:Well, the other thing just to keep in mind too, is that depending on how your rest is implemented, you may wind up making several calls to the back end in order to get what you need, where GraphQL. I mean, so it had a lot of these features that kind of solved some of the pain that people had with rest, right? 

AJ_O’NEAL: Well, 

CHARLES MAX_WOOD: but the flip side was, was like you said, implementing it on the back end. And I've done this a couple of times now. It's a royal pain. 

AJ_O’NEAL: Yeah. If you can pull pretty much, if you're not using Apollo you're going to have a bad time. Like GraphQL essentially just works in Node and just with Apollo, more or less as advertised. But if you write bad REST APIs, you can have a bad experience. If you create bad GraphQL, you can have a bad experience. I think it's just a lot easier to sell GraphQL on the front end and a lot harder to implement it. There's not a good naive implementation. You can have working naïve implementations of REST but the naive implementations of GraphQL don't work. 

STEVE_EDWARDS: Well, yeah, I think the problems that I had dealing with rest of my frustrations could otherwise be known as arrested development. 

AJ_O’NEAL: Where's your, there it is. 

STEVE_EDWARDS: Thank you, thank you. 

CHARLES MAX_WOOD: Well, and I just wanna tie this back to FOMO. Again, it's like, hey, how's all this promise and saying that it's gonna solve all these problems, it's gonna make life better. And so certain circumstances, it does. And in other circumstances, it doesn't but you see people adopt it because it's like, well, this will solve all your problems for you, or hey, everybody's talking about this new way of doing it, and that's why people adopt it, instead of actually going and doing a little bit of homework and figuring out, you know what, this really isn't what we want. 

DAN_SHAPPIR: I think there was also the point where it was like, in every JavaScript conference that you would go to, or JavaScript-related conference, there would be a talk on GraphQL, and it was, so it was not just the fear of missing out on a really cool tech that might solve all your problems. Because like you guys said, doing rest correctly can be challenging. It was also getting to this point where you were starting to think that, Hey, if I don't know GraphQL, will I be able to get a job in a couple of months? Because it seems that everybody's going there. 

AJ_O’NEAL: So I want to talk, I want to speak to this because I think they're. You don't have to go all in on something. And I want to, I want to talk a little bit about my experience with NoSQL versus my experience with Go versus my experience with Rust and Node. Because these are all things that I don't know if Go and Rust are really a hype train per se, but Node definitely has been a NoSQL was especially at the time, because again, there was the JavaScript hype and NoSQL was JavaScript. And so, but when I look back, I, I was very young and in my career, I was still in college when the NoSQL craze hit. I was still in college when Node hit. With Node, I had been learning a little bit of Python and a little bit of Ruby. I was trying to figure out how web programming could work. And there were some people that identified really well problems with Python and Ruby and how Twisted and Event Machine kind of sort of solve those problems. And that led me onto this track of Node.js where some of the people that were working in those spaces had had figured out JavaScript is a language that's well equipped to solve this event handling problem so that you can handle many requests at a time. And I was able to understand technologically why it was superior and I also had played around enough with the competing technologies that when I used it, I understood why it was useful. Now I wasn't a Rails expert, but I had played in Rails enough to get a feel for what it was like. And the same thing at Python, I had even less experience in it, but I played around with some of the frameworks just to kind of get a feel for it. And so when Node came out, I had enough experience to realize, hey, this is really useful. And in part, I decided to dedicate myself more to Node than to Go because I did see that there was more FOMO in Node and that was giving it traction. But I also saw that it solved a useful problem. With NoSQL, I don't think that my brain was quite as active on understanding, one, how databases work and what the problems are. I don't think I had had enough experience to understand the difference between the SQL and NoSQL debate. And so I was getting into NoSQL thinking this was a great thing. And I had had arguments with people who were more SQL people. And they were pretty cool and rational about it. And and steady and confident that the NoSQL fad was a bad idea. And I was on the side of thinking, no, this is going to be great, but I really didn't understand enough about it to know. And so I built some stuff with NoSQL, thankfully nothing that got any traction. I used CouchDB and it turns out that that was a bad idea and NPM tells the story of that pretty well, but I didn't really have the experience that I didn't wait and see. With Node, I had maybe enough experience and I didn't really wait and see. With Go, I could tell that it was great, but I took a wait and see approach. So I went to Go meetups, I listened to Go conference talks, I stayed abreast of Go and I introduced Go to other people and then other people would get excited about it and they'd go build things and they'd tell me what they were building and they'd tell me how great it was and I'd keep in contact with those people. So I kind of vicariously learned Go and by the time I actually got in it, I was actually, other than not having the muscle memory of it, I was actually quite adept at using it. And then with Rust, for the longest time, I thought that, you know, that there's just this language craze of, oh, we need more languages. We've got Go and then, you know, Apple wanted to create their own Swift and, you know, and everybody's trying to create their own new modern language. And Rust was just Mozilla's take on trying to create their own new modern language, but as I kept on encountering people, I took the wait and see approach because Go is good enough. And so I took the wait and see approach and as I kept on encountering people who were smart people that I respected, that had an affinity towards it, eventually I started to see, oh, this does have a niche. This does solve a problem that Go doesn't solve and that Node doesn't solve and that C++ doesn't solve. And so right now I go to the Rust meetups. I'm actually in Utah, I am the organizer of Utah Rust. And I have done a little bit of paid programming in Rust, but not that much. But I just got a wait and see approach. I surround myself. Well, it's not even a wait and see. I know that it's clearly it's got a benefit and it fills the niche, unless something else pops up and takes that niche away, it's gonna stay there. But I'm writing it out and I'm surrounding myself with people that are interested in Rust. And I tell people about Rust. And the same thing is happening with Rust. It's happened with Go. And I think that when I see things start to become a little more stable, when there's a little bit less community, it's not quite friction, but let's say surplus of opportunity of choices. When it comes to certain standard library features, such as which web framework is going to win out. You know, you wouldn't want to have been in Node when you were figuring out whether it was going to be Express or one of the 10 other frameworks. You'd want to you know, coming at the time when Express has already chosen. And same thing with Rust. I feel like it's not quite there. So I'm taking this wait and see approach because I do believe that it's a good technology, but I don't feel that my career is at stake. If I don't learn it today, my career might be at stake. If I don't pay attention and surround myself with smart people. 

STEVE_EDWARDS: So is it fair to say that Go is still your go-to language? 

AJ_O’NEAL: I love Go. I think that Go is the smartest language to be using because it is designed by people who really have a good head on their shoulders. It's something you literally can learn in a weekend, assuming that you know programming at all, whether it's been Python or Ruby or JavaScript or whatever it is. Go is, it's a tiny, tiny language with an expansive standard library, which means that learning the language takes a weekend and using the standard library, which is idiomatic to the language, you can build anything without ever needing a dependency. I mean, there's a couple of things that they are convenient enough they're worth using but you don't need anything outside of the standard library to get serious applications built. 

YOAV_GANBAR: There you are creating FOMO again for people. 

AJ_O’NEAL: But there's no need to have FOMO about it. Because again, the pitch is you can learn it in a weekend. Where's the FOMO in that? 

YOAV_GANBAR: Oh, that still is. You've got to try Go. Find a weekend to kind of learn it. It's worth it. I'm telling you, this is like, again, the marketing of it. I'm not saying Go is not good. Not at all. I've tried playing around with it. It's pretty cool. But it's again, it's kind of this thing. Like I think one of the most, like what creates FOMO for people, the most of these for me is like when a friend or a conversation, something, so somebody comes up to you and says, hey, have you heard of, and have you tried this? Like, oh, I don't know what it is. Should I try it? Should I do it? Should I find the time? So it's just one of those things that keeps on coming up. But I think like we've kind of discussed what gives FOMO so much. And I think we maybe it would be a good idea to kind of segue into how to deal with FOMO. How do we kind of manage that? 

STEVE_EDWARDS: Oh, then you go right into my next thought. I'm going to cut my turn, AJ. My turn. 

AJ_O’NEAL: Let me finish my sentence. 

STEVE_EDWARDS: Fight. 

AJ_O’NEAL: That's what I'm trying to get into is how do you take the wait and see approach without missing out? 

STEVE_EDWARDS: Yeah, I guess my approach has been, you know, trying to avoid the phrase jack of all trades, master of none. And this is something that's true outside of programming and professional life, personal life activities. How many things do I want to get involved in where I'm spread so thin that I can't be really good at anything? I can do a little bit of this and a little bit of that, but when it comes down to really needing something good, I don't have those skills. And so from a development standpoint, that's what I've tried to do is to focus on getting really good at a few specific things and avoid the call of the wild, come learn this tool, come learn this new framework, come learn this new language, because it's very easy to get sucked in and spend a few hours looking at something that you decide you're not gonna use when you could have spent those getting better and what is really useful and what you're good at. So it's, I mean, it really just comes down to discipline and deciding how disciplined you're gonna be and what you wanna focus on 

YOAV_GANBAR: best way like to kind of try and do this is kind of also in life, I guess, not only as a developer is kind of being content with what you know, say don't stop learning, right? But you kind of don't need to worry about it that much. And kind of when you feel or when you hear that something like from people you respect and adore, or people that you really find that are the ones that you look up to talk about something more than three times. And I think I'm paraphrasing, I think it was West Boston, Scott Tulinski saying this, that when they talk about something more than three or five times, that's when you maybe should start paying attention. So I think you need to find like those people that you find that are right aligned with your kind of way of how you're developing as either a developer or as a person. Kind of other than that, try to kind of put on the horse blind and be like, okay listen here and kind of be aware of that. 

DAN_SHAPPIR: Yeah, that's kind of like the flip side of FOMO that you, if you do become too jaded, if you can chalk up any like new technology as, you know, this is FOMO, I'm just gonna take a very long time checking out what might happen. You can get set in your ways and will actually miss out on interesting technologies and I'm not even talking about the fact that you know you could potentially eventually over time become unemployable because you kind of paint yourself into a technological corner if you really take too long with it. I do think that we need to kind of go with the flow with technologies so not go wherever the wind happens to blow that morning but we do need to be attentive to what's going on within the technology field that we're in at large, I think. 

CHARLES MAX_WOOD: Well, and that's, I think we've kind of put a lot of the pieces into this episode already, where both Amy and AJ and I think you, Dan, I think everybody's kind of said, hey, you should be learning on a regular basis, right? Which does give you the chance. I believe that a lot of your effort and learning should be focused on things that are going to directly career progress, right? So you should be making choices that you can justify, but there's also room in there for you to go and experiment with other stuff, right? So if you are hearing about stuff and you're going, okay, well, a lot of people are talking about this, I'm gonna go check it out. There's no reason why you can't go evaluate it and then start to form an opinion about it without necessarily whole hog adopting it, which is a point that AJ made. And then as you explore and you kind of watch and get a better understanding of what's there, then, then you can begin to benefit from it. And you can say, okay, well, this is a direction now that I want to take my career going forward rather than in a panic while everybody else is doing GraphQL. And so I feel like I need to too, pulling it in and then figuring out that GraphQL wasn't a great fit for your application. 

AJ_O’NEAL: Well, you also need to make mistakes as part of, so all businesses, well, let me rephrase that. Many businesses are built on investments, large businesses in particular, the ones that the 50% that you're likely to work at. And then investment is built with risk built in. And this is all aspects of life. This is childhood. This is this is everything, you know, and continues on to adulthood. We make mistakes and we learn from our mistakes. And so I think we there's some amount of exploration we need to do. If I hadn't learned a little bit of Python and a little bit of Ruby when I was first learning programming, then I wouldn't have known that Node.js was different and that it was something that really solved the problem. If I'd known more about databases, then I would have realized that NoSQL wasn't really different and was kind of GraphQL-esque in the sense that the problem could still be solved with the existing technology in a relatively normal way. 

DAN_SHAPPIR: What I try to do is when I hear about a technology that sounds interesting and I want to see if this is really worth getting into for me is I try to find what looks to be a good presentation or conference talk about that topic by somebody who is considered to be like a leader or an expert in the field. And then I listen to it and see if I get it, if I find something in it that makes sense for me. And if I finish a talk by somebody who's kind of, you know, leading in this field and by the end of the talk, I still don't understand why I should look at this technology, what's, what's in it for me as a developer, then, you know, I, I pass it by now. It doesn't mean that I might not go back to it sometimes afterwards, you know, test the waters again, but that's kind of a litmus test that I use. 

CHARLES MAX_WOOD: All right, you have, we're going to let you have the last word and then we're going to go to picks. 

YOAV_GANBAR: Well, kind of hard to find the last word for the slum discussion. Like. There were really good points made out here on just how to kind of look at things. And I think just also talking about the things that kind of give us the fear and makes us scared of being irrelevant or making the wrong decisions on tech. I think they also kind of coincide with like the imposter syndrome, that it's something that a lot of people feel. Like you always feel you're not good enough at something or you're missing out on something. And it's just human nature that brings us there. And there's always a lot more to learn. There's always so much to learn. And I myself am a philosophy major, by the way. So I like to always remember the Socratic phrase of, all I know is I know nothing. And the more you know, the more you understand, you don't know almost anything about what goes around. So yeah, just kind of don't they try and feel more content with things that you already know and try and kind of focus? I think that is the main takeaway out of this. 

CHARLES MAX_WOOD: Yep. I like it. If people want to kind of follow up on this conversation, I mean, obviously we'll have show notes with comments, but if they want to continue this conversation with you, how do they find you online? LinkedIn, Twitter, GitHub somewhere else. 

YOAV_GANBAR: Yeah, so LinkedIn, just my name, Yoav Ganbar, G-A-N-B-A-R, and Twitter, GitHub, all those. My, well, how do you say it? Screen name nowadays, or username is Hamato Yogi, just like it sounds. Yeah, yeah, find me in the show notes. 

CHARLES MAX_WOOD: Cool. 

 

Hi, this is Charles Max Wood from Top End Devs, and lately I've been coaching some people on starting some podcasts, and in some cases, just taking their career to the next level you know, whether you're beginner going to intermediate and intermediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching. 

 

CHARLES MAX_WOOD: All right, let's go ahead and do some picks. Steve, do you wanna start us off with picks? 

STEVE_EDWARDS: Ah, not saving the best for last. Okay, I can appreciate that. So I'll go with a couple of the high point of the podcast, my dad jokes. So my male character told me the other day he was traveling to Spain tomorrow, so I asked him if he was going to Barcelona. He just sort of ignored what I thought to be was one of my best jokes, but I figured maybe I didn't say it right because the key to a good mailman joke is the delivery. And then I found a new organization that I want to join. You know, everybody knows AA. This is called the AAAAA and it stands for the American Association Against Acronym Abuse. Thank you. And those are my picks for today. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_O’NEAL: All right. Well, I'm going to have to start out with U L I D. So it turns out I've been wrong and lied to and lying to others. There is, uh, so there are actually problems with using UUIDs as the primary key in your database. I think that by now, most of us know that auto incrementing keys are a bad idea for a variety of reasons, uh, being publicly guessable and not scaling, not being able to insert records in multiple places, but I don't think that very many people are familiar with the problems of UUIDs, which is that at least in MySQL, maybe not as much in Postgres, it defeats the indexing. And even if you think about this intuitively, a binary tree, if you insert things into a tree at random, then you're going to be taking different branches every time, which means that you don't have a place in memory that's quote-unquote hot and then you you IDs are very long and they take up a lot of space yada yada So there's this middle ground called a UL ID where the first component is based on monotonic time Meaning that it essentially increments. I think it's 48 bits of milliseconds Until it eventually rolls over and then the other component is random so you get fast inserts and you get data that is somewhat likely to be accessed together being indexed similarly based on on the time portion, but then you still get the random piece so that it can't be guessed and then it's a bit shorter. So I think it ends up only being, I don't know if it's 16 bytes or maybe a little bit more than that, but plenty of space. And it's base 32, which databases, as we all know, are typically search case-sensitive on strings. And so this gives you something that you can store as a string and get efficiency in it and not have to worry about the case sensitivity losing half of the bytes of your UUID anyway. So ULID, and I'll link to the spec on that. 

DAN_SHAPPIR: I thought that you were going to say that it's mostly because we're running out of UUIDs. 

AJ_O’NEAL: That's preposterous.

CHARLES MAX_WOOD: Yeah, they're universally unique by definition. 

AJ_O’NEAL: So I wanted to let our listeners know we're running out of random numbers. 

DAN_SHAPPIR: There was this great Dilbert where they go around the company and they end up, I think it was in accounting and they have this random number generator, which is this guy sitting there going seven, seven, seven, seven and they asked him, are you sure this is random? He says, that's the problem with random generators. You never know. Wait a minute, is AJ done? I interrupted him, but I'm not sure he's finished. 

CHARLES MAX_WOOD: Oh, are you done, AJ? 

AJ_O’NEAL: I will wrap up quickly. I've got one other thing to pick other than my usual spiel, which is the Cores Playground. So my nemesis, Jake Archibald, released an excellent article on the history of cores, that's cross origin resource sharing, current problems with cores in today and modern browsers, possible workarounds for different, for other ways to work around the same type of problem that cores solves. And I just have to say it was an excellent article. So despite being my long time nemesis, I have to pick his excellent work. And then aside from that just the usual spiel of if you're interested in following along with my live coding sessions or the high quality content that I put out, you can catch me live at CoolAge86 on YouTube and Twitch or follow Beyond Code for the high quality content only. 

STEVE_EDWARDS: Why is he your nemesis? 

AJ_O’NEAL: Because we had a row in a prior episode that I didn't realize at the time was a row and so now it's kind of a little bit of a joke amongst us panelists that he's my nemesis. 

DAN_SHAPPIR: I think you were there, by the way, Steve. 

CHARLES MAX_WOOD: All right, dan. 

DAN_SHAPPIR: Yeah, so okay, so I have two picks today. The first, if you may recall, we had Rick Viscome from Google on our show on episode 486, talking about the crux and Core Web Vitals. Rick runs essentially crux within Google, and also heads up the HTTP Archive open source project, which is kind of a sister project to Crocs. Both of these collect essentially lots of interesting data about most any session to any website that's open on Chrome, on a Chrome browser. In case you didn't know, again, we talked about it in that episode, but in case you didn't know, unless you opt out when you visit a website using Chrome. It actually records a lot of information about your experience browsing that website and then sends its information anonymously to this database where Google can look at it, but also where essentially almost anybody can look at it because it's really open. And then they also run synthetic tests on those same websites. So they collect lots of information about, for example, how much JavaScript gets downloaded, how much images. Which image formats are being used. They even looked at stuff like the largest Z index that ever gets used in a website. But anyway, the thing that I would like to pick this time is that Rick actually built this great thing on top of all this data, where you can go in and then basically just see a lot of graphs generated from all this data that they collect. So for example, if you want to compare the performance of websites built with, I don't know, let's say Svelte versus React or versus View, or you want to look at how much JavaScript they download, or which image formats are primarily popular with various different technologies and so on and so forth. You can generate a lot of comparative graphs there. It's a really excellent tool if you're interested in how the web is actually built and it's just free to use. So I'm going to link to that. So that will be my first pick. My second pick is that with everything going on in Afghanistan with the US forces pulling out, the Taliban taking over, and the people there really suffering, I was reminded of this excellent book that I read a while back called The Kite Runner by Khaled Hosseini, who relates his story about growing up in Afghanistan and Kabul back in the 70s, all going all the way to when the Taliban took over. So we're talking about the end of the monarchy there, the Soviet invasion, and you know, the Soviets pulling out all that time period. It's an excellent book, highly recommended. And I will link to that as well. And those will be my picks for today. 

CHARLES MAX_WOOD: Awesome. Amy, what are your picks? 

AMY: I'm going to go with one from the Teleport blog anybody who knows me knows I'm like a huge fan of the Cloudflare blog. They have so much, so many articles about like anything you could ever want to know about networking. And I'm starting to like the Teleport blog too. So this is a blog post on how SSH tunnels work, more of like a deep dive into that. So I'll drop a link for that. Oh, sorry, that was a bad noise. I'm not feeling well. My nose is very congested. Anyway, so then the other one. All this, this is like an opinionated article. I have been like really diving deep into a better understanding economics and investing and all that kind of stuff. So again, a little bit opinionated probably but it does get into just things that are going on here in the US about our economy right now, quantitative easing which is what the federal reserve started doing last year for COVID and just, I think it's important for people to know that you can have your opinions on you know, whether you think it's good or bad, but at least I understand what it is. So I'll jump in for that. And that's going to be it for me. 

CHARLES MAX_WOOD: Awesome. I'm going to jump in here with a few picks. First of all, I think I'm going to do a board game pick like every time. So, uh, this last weekend I was at a conference for board games. It was just a small local conference, uh, in Provo. And I was actually volunteering. A friend of mine owns a game store and needed some volunteers to help teach people games. So I got to go play board games all day and then teach people for the last few hours I was at the conference which was totally fun. One of the games that we were teaching is called the search for Planet X and essentially it's kind of like a logic puzzle that you take turns getting clues basically in different ways and it's kind of a race to see who can figure out where Planet X is and what's around Planet X first and so anyway it was it was a ton of fun the first time I I lost to a 12 year old and 10 year old. Granted, they started with four more clues than I did, uh, but I did lose to them the second time around. I started with four fewer clues than everybody else playing, but I actually won that game. I did not find Planet X first. You can win without doing it. Anyway, it was a ton of fun. So, uh, definitely check it out. You do need a smartphone to download the app and then the app is what gives you the clues. So, you know, as you take turns, anyway, it's, it's really, really fun. The second pick I have, I am working furiously on topendevs.com. Somebody pointed out that the devchat.tv website is now behind on listing episodes. That is going to change because I am going to be forwarding everything over to topendevs.com this week. At the latest, like Monday next week. But what I'm doing there, there are a couple of things. One is I'm consolidating a place where you can come and get all of our content. It is still going to link out to fireside, which is where we're hosting the podcast websites. But i'm also then going to be working on a series of courses that you can get at top end devs on a subscription so you'll be able to see what those are and what the deal is there and if you want to get in on kind of the pre-launch you can do that up through black friday so it's going to be black friday cyber monday and then you're you know, then it's going to be regular price. But we're going to have some master classes and some some courses on bettering your career and things like that. But I'm also looking for authors. So if you're interested in putting together a course or courses or just a one hour tutorial on how to do something that people need to know, then go to topendevs.com slash author and fill in the form. And then I will have a look and see if there's something we can figure out. And yeah, those are my picks. Uh, Joav, what are your picks? 

YOAV_GANBAR: Well, I have a few. I've got to keep them short though. First, the take is going to be generally help in doing Pilates. Like we sit in a chair a lot of the time and just stretching out is really good for my back. I had sciatica so I recommend that. Second take is going to be anything lately that Zach Jackson has been putting out. He's the guy, one of the guys behind Model Federation, Webpack Model Federation, which is a really cool feature of Webpack to kind of share JavaScript modules between remotes. It's super complicated to explain like that to words, but just check out it and you can just put out, maybe it's also been doing lots of cool stuff around Next.js. Another pick is Next.js Conf is in less than a week now. I'm excited about that, because I'm a big fan of that framework. Yeah, other than that, something a little bit controversial, but I highly recommend it. I don't know, I really enjoyed it, was Dave Chappelle's Netflix special. There was kind of a buzz going around about that. 

DAN_SHAPPIR: Ooh, that is controversial. 

YOAV_GANBAR: It is controversial, but I think in general, I've been following him like his whole career and I think he's one of the funniest people in the world. In Israel, we're far less sensitive, I'd say. Other than that, yeah, talking about FOMO, like a lot of things that happened, like keeping up to date with stuff is something that I guess is on everyone's list. So I have this great little tool that I use almost on a daily basis called daily doc dev. It's basically a browser extension, but also kind of a web app that curates articles all around like developer communities. So just creates a plethora of articles from dev to the Kenzie Dodd's website, medium and whatnot. It's pretty nice. Other than that, stuff in CSS and CSS and JS. I'd say CSS aspect ratio has saved my ass, and I like it a lot. Stitches is looking interesting. Vanilla extract, two solutions to kind of do the zero runtime CSS. Vanilla extract is more like the script CSS. Twin macro, shout out to Ben Rogielson. 

DAN_SHAPPIR: You know what also does zero weight CSS? The style tag. 

YOAV_GANBAR: Yeah, the style tag. Just CSS. For sure. Last one I'd say is the new season of The Boys. That's going to be pretty cool. Check it out. 

CHARLES MAX_WOOD: Cool stuff. 

YOAV_GANBAR: Thanks for having me. 

CHARLES MAX_WOOD: Yeah, well, thanks for coming. We'll wrap it up here. Until next time, folks, Max out. 

STEVE_EDWARDS: Adios. 

YOAV_GANBAR: Cheers. Bye-bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.