Bleeding Edge Transcript.txt

Hey, everybody. Hi, Byron. Sanchita, welcome to Devampplifier. Glad you're here. Sanchita is from from actually, remind me where you're from. Australia. Australia got it. Where in Australia? Perth got it. I used to have a client in Perth. It was a product called Rewardal. You ever heard of Rewardal? Or if you go into a coffee shop where they've got that loyalty program and one of them is called Rewardal. They're based out of Perth. Really good company. There is Cristanto logging in. So, hey, we will go ahead and get started. I know some of the other Devs are logging in, but I want to show Sanchita that we are serious here. So we're going to start on time and the other guys will just have to pay the price. So welcome, guys. Let's talk about the bleeding edge. That's our task for tonight. Sometimes when we say cutting edge, that's when we want to say that we're paying attention to what is most advanced technology, the newest thing. But bleeding edge is taking it a step farther. It's getting so close to the cutting edge that we're bleeding. We're cutting ourselves. And another reason why the bleeding edge is called the bleeding edge is because it's painful sometimes, because getting into brand new technology can be a bit difficult. Not difficult to get into it, but sometimes to get out of it or to get out of the messes we make for ourselves. So can any of you all think of something, a technology that you've used lately that you consider cutting edge or bleeding edge, something that is way before anybody else has used it? The only experience I have on the bleeding edge was with TerraForm. Yeah, TerraForm for spinning AWS architecture as code. So we started using the latest version of TerraForm. And since we created a lot of reusable modules for all the micro services and after upgrading, there were a lot of breaking changes. Things were handled differently. So we needed to literally roll back because too much changes. So we needed to go test it one by one and see what it works and whatnot. So that was on experience for me in a bleeding edge. As far as another technologies, I can't really tell that. Yeah, that's all right. Jr. Jose, we're talking about the bleeding edge tonight. And I just asked if you've had any experiences recently working on what you would consider bleeding edge, cutting edge technology that's maybe a little bit ahead of what everybody else is using, maybe a little bit too early to be adopting something, but curious about experiences that you all have had doing things like that, cannot think of anything, nothing comes to mind. Yeah, that's okay. When you're working on a team where safety is a big concern, the bleeding edge is often something that we don't get to work on, because if we're dealing with a very cost conscious or safety conscious client, then we may not get the opportunity to work on bleeding edge or even cutting edge stuff. But I'll tell you a few stories about when I have in the past. Of course, being the CTO of a company has its benefits, right? There are some nice things that come with being a CTO and having a lot of developers working for you is that sometimes you can just kind of like send somebody a message and say, hey, man, or hey, lady, try this. Try this library out. See how it goes. Just do a quick 30 minutes on it or something like that. And it's interesting what might come out of that sometimes I've done that with several different technologies. I've also done it on my own. Some of the biggest decisions, actually, that I've made as a CTO have come out of experiments like that. As far as, like, technology decisions, one of those that comes to mind. Years ago, I want to say, six or seven years ago, I had a feeling about a technology back of the mind feeling. I was like, this technology is going to take off. This is back when JavaScript was a lot more Wild West than it is right now. It actually somehow JavaScript feels stable now. But this was back before JavaScript really felt stable. It still felt kind of squishy. And so this library came out, or this technology came out, and it started to make JavaScript feel like a real language. And it actually in those days, it gave us access to future releases, future features of JavaScript that had not even been released to the public yet. We were able to actually use this technology and actually start using those future features that were just like, Earth shaking kind of features, like things that really made JavaScript awesome. I told some guys I was like, hey, I know that there's this client that he's a really nice person, probably will be very happy for us to try this new technology on his project. And this is back when it was still Alpha. It wasn't even in production release. This library, this technology and people around me were like a buyer. And that's not a good idea. That's not going to fly. But I have a knack. I don't know if you want to call it a gift, but I've got a knack. I've got an ability, apparently, to pick technologies. I've done it before. I'll digress just for a second. Years and years ago, like, even more than seven years ago, there was this technology called Phone Gap. And it was a technology that allowed you to create a web application using some special JavaScript stuff. And you could use a tool that would take your web application and then it would wrap it up in an iOS or an Android Deliverable container. And then you could send that into the App Store, and you'd have a mobile app that you didn't have to write with Objective C or Java, which in those days was extremely attractive because nobody wanted to learn Objective C. Any web developer hated Objective C. I don't know if that has changed much, at least now we have Kotlin, which makes Java better, and we have Swift, which makes Objectivec better. But back then, Phone Gap was so cutting edge, bleeding edge. It was not even in production release yet. It was in like Alpha and beta. And I made a call and I said, I think this Phone Gap thing is going to take off. Let's just go for it. So we started creating mobile apps for clients using Phone Gap. Phone Gap turned into Cordova or Cordova. I don't know how you pronounce that. Cordova still lives to this day. And Cordova is one of the reasons why we have things like React Native and other web technology based mobile application platforms. So I made that call back when a lot of developers weren't willing to make that call. So I've got a knack. And this other technology that I was telling you about that made JavaScript feel legitimate. Years later. Today, most new JavaScript is written is written in this technology. It's TypeScript. I was using TypeScript back in the back end, back when it first came out, when the only time people would use it, for example, was for front end. And I was like, this is going to work in the back end. So I was one of the first developers that was actually compiling TypeScript for Node and Express and the back end languages. I love making little bets on technologies. So those are some stories that I've had. Now, TypeScript didn't always work out well because as you know, you got to import types, and if you don't have types, which back then nobody had types, especially for Node. Basically you had to write them yourself, which really sucked. So it wasn't always good. I mean, sometimes the bleeding edge causes you to work a little bit harder. Did anybody figure out that I was going after TypeScript that I was talking about TypeScript? No, I hit it that, well, another one now, this one, I don't know if this one is going to work out, but years ago I decided that I was going to learn a new language, and I wanted to learn a language that was completely functional. I wanted to go into a language that would force me out of my object oriented mindset, and I wanted to just learn functional so that I could really get functional programming ingrained in my head. And so I chose a language that at the time, and I think that it's still happening, that Facebook had invested in to start building some of their new web applications, which at that time it was called ReasonML, which I don't know if it's still going. I haven't really checked on it lately, but Reason ML was a functional syntax of OCaml. Has anybody ever heard of OCaml? Yeah. Okay, so OCaml is a functional language it's kind of a cool language in and of itself, but the syntax is kind of weird, a little bit haskellish, but reason is basically JavaScript. I mean, it's very Javascripty in its syntax, so I felt. I felt very at home, but it got rid of all the object oriented stuff that's in JavaScript and I just fell in love with it. And that may be a technology where I didn't bet. Right, because it still hasn't taken off. I don't know that anybody is really writing anything much in it now, but I have a full application. The entire company is based off of a product written in this language, Pistol. And that company may completely go under because of the software, because it was written in a language that nobody knows how to program in. This is the price that we pay sometimes to go down the trail of the bleeding edge. What do you think about Dart for Flutter? Well, I think they look awesome. One of the things though, that I like even more, did you say Dark? No. Dart. Dart. Oh, yeah, Dart for Flutter. So here's what I like about those languages. The Flutter as a technology language or Dart as a language. What I like about those more than anything is the fact that the community likes them. See, this is one of the things that I look for when I'm looking at a technology to try out. I look for how is the community talking about it? And when you hear people talking about Flutter and Dart, they talk with stars in their eyes. They talk as if it's the thing that if they could just do this, this language, that everything would be okay. And people seem to really love Flutter. So that makes me want to learn it. I haven't yet. Oh, you should try this if you're familiar with JavaScript and Java is like. I think that Dart is the son of Java and JavaScript because it has everything from JavaScript and everything from Java and more stuff. So I had an experience with this framework. A friend of mine was running a software company and he was like trying this new technology, right, Florida and all that. It looks like react native because of the component based UI and state and all that. So he started implementing that in the company and then the developers started like slowing down the process because of the learning curve. And they were confused because if you're don't know how to use Dart, he makes confuses sometimes. So he asked me for help. So thank God I have some experience on my own. So I was proud because I taught them how to tackle Dart and how to think in a new way. The new paradigms introduced, like mixings and all that. So it's really cool. It was a really fun experience for me. That's awesome. Maybe you and I can work on the project together in Dart and Flutter anytime a community does what Jorge just did, endorsing it publicly. People who try Flutter do that all the time and they don't even get paid for it. When a community does that with a technology, it's a good sign. It's a really good sign. Another really good sign. If you're trying to pick a technology to try out, here's some different criteria that you might try. Another really good sign is that the makers of the tech are actively doing things to make the tech work well for developers. So that may sound a little bit weird, but the tech is supposed to do things to solve problems. But honestly, problems can be solved with any tech. You can solve any problem at all with objective C. You can solve any problem at all with C. Can do a web framework. You could build a website with C Plus Plus. Sounds weird, but you could the difference between building a website with C and building a website with like a Django or a Jekyll or VJs or just some of these different things is that those frameworks, those technologies make it good for the developers. C, I wasn't made for the web. Who cares? Manage your own memory. That's what C Plus Plus is going to say. But if you're going to build technology for developers to use, then you've got to make it good for the developers. And Flutter has done that. Flutter has done a really good job of making something that is a joy for developers. So if you're trying to figure out whether technology is going to make it, then A, yes, of course, does it solve problems, but B, is it good for the developers? Is it nice? Does it feel good? Does it make developers lives or jobs easier? And if the answer is yes, then the technology has probably got a pretty good chance of making it. Another good sign is that it's getting talked about in podcasts. So if people are willing to go on a podcast and actually talk about a technology, it's probably got legs. I can't say it's a guarantee, but it's probably got legs. If people are out there actually talking about it, what am I saying publicly? Youtube, on the other hand, is not a really great indicator. Why? Because anybody can make a YouTube video in their bedroom and push it into YouTube. It takes a little bit more effort. I know technically it doesn't, but typically people put more effort into a podcast, and therefore they're not going to put just any old trash on a podcast. It's actually going to be something pretty good. Do you all have any other strategies that you might suggest about how to stay on the bleeding edge? I don't know about you, but I follow some influencers, let's say tech influencers on Instagram. One of them, which is a girl, which is called Jackie, talks a lot about technologies, about Amazon, AWS and stuff like that. So I've gotten to know many of those just because she talks about it. Even though I don't dig deeper into them, I know that they exist and I know their name. So that's how I get to know many of them. You have kind of a routine of when you listen to those influencers or watch those influencers? Not really. Okay. All right. Anybody else? Maybe look for a showcase page landing page where maybe. Okay. All these websites, all these sites or these apps were built with this framework. So take a look at why you can build with it. So it gives you the confidence. Maybe you have some idea, or maybe your business has some requirements that need to be met and maybe you find something similar, like, okay, I can do that. So I can based on it and give it a shot. Yeah, I've got an idea. Let's try something here in general, in this black channel, I'm going to post a message. What are some podcasts, what would you call that? Twitter profiles, YouTube channels, et cetera, that you like to use to stay on the bleeding edge? When I say stay on the bleeding edge, what I mean is, I'm obviously not saying that you're going to go out and try every technology, but what are some things that you do, maybe even on a daily basis that help you just be aware of things like, who's heard of Dino? D-E-N-O. You've heard of Dino. Whether you've tried it or not, you're aware of it. You know that it exists. You might have even looked into why you might choose it over Node. I actually still don't really know. I haven't looked into that much. But how did you find out about that? You may have found out in your company chat, or maybe there's like a stream. And that's kind of what I'm looking for is what are some streams we can be subscribing to as developers that will help us stay on the bleeding edge. One of the ways that I've always benefited from is listening to podcasts. So I've always liked handful minutes. I know I'm old, so I don't know what you all like the young people out there, but I've always liked handsome minutes. I used to listen to Herding Code all the time. Back when Stack overflow, when Jeff Atkins had a podcast, that was him and Joel's Ki. When they had a podcast, I listened to that every single week. It was awesome. I loved it. There's also that.net podcast really cheesy. I can't remember what it's called.net. Rocks. So back when I was bigger into net, I would listen to that podcast all the time. I loved it. And so between just listening to those podcasts on my drive every day to work, I know we don't really drive to work anymore, but I would use that time in my car to listen to podcasts. And that was one way that I was able to stay ahead of everybody because none of my coworkers listen to podcasts. And so whenever somebody would say, I wonder how we can solve this problem, I'd be like, well, we should use this library. And they didn't realize I had just heard about it that morning. But just knowing that something exists is a really good way to stay ahead, even though we're not using this stuff right away. So in that little thing that I just posted, in general, if you like to listen to a podcast, pop it in there, share it with everybody else. Even if it's just the name of the podcast, it's fine. Or an influencer that you follow in Twitter or Instagram. I still haven't figured out how to use Instagram. Isn't that horrible? And just the other day somebody told me I need to have a Tik Tok account. I'm like why I don't want Tik Tok, but apparently I should be posting my videos on TikTok, so that's coming too. But fill that up. If you guys can think of. I'll think of a few, too. I'll put them in there and then take some time tomorrow and look over that list and see what you might join, what you might start to follow for yourself. And what Jorge mentioned is a great strategy once you know a technology and you want to dig in. What I'm talking about here is a stream. What's a stream of information that you can subscribe to that is on a daily basis, giving you, just serving you on a platter, the information about the different technologies that you could use. So I'll leave that there, look for some updates to that later on whenever enough people have posted in. All right, so one thing that I was going to suggest to you all is if you want to be on the cutting edge or the bleeding edge of this, there are a few different ways that you can be there on the bleeding edge. One is like we were talking about the other day. We were talking about the difference between awareness and mastery and how there's a continuum between awareness and mastery. Awareness is powerful. Just being aware that something exists helps you in the future. Because once you need it, if you have enough awareness that you know how to use the technology or you know why it's used, what kind of problem it solves, then once you have that awareness, then you can go and research it when you need it. So if you at least have that much information in your head, then it's still useful, because then you can increase your mastery by researching it. Like what Jorge was suggesting. How do we stay on top of those technologies? My suggestion is to have a morning routine or an afternoon routine or a lunch routine, but a routine where you've got something that you do on a daily basis. This is kind of going back to a little bit of the discipline idea where you've got some rhythms that you're involved in. I suggest the morning. I feel like, well, at least for me, my mind is sharpest in the morning. And so if I start to notice some things that are available out there, if I'm seeing some influencers talking about a new technology, if I hear a podcast, then my brain is probably going to lock onto it a little bit better in the morning. That's me. That's my internal clock, my rhythm, whatever your rhythm is, then choose that even 15 minutes a day, 15 minutes a day is not going to cause any problems at all at work. So you should feel fine incorporating this into your daily work schedule, especially if you've got something that happens on a daily basis. You could put this right before that thing or right after that thing. For instance, lunch. When you come back from lunch, don't you kind of flounder a little bit after lunch, just even trying to get back into the swing of things, getting your brain back in into the game. And so if that's the case, it'd be a really good time to go ahead right then and spend 15 or 20 minutes looking at your stream, your cutting edge stream. You might even have like a bookmark folder in your Chrome that has all the links to the places where you want to go. And you just go from one to the next to the next. And then once you're done, you're done 15 minutes a day. 20 minutes a day. That's one possibility. Another thing is using that drive time. If you happen to drive, then don't waste time. I was going to say don't waste time listening to music, because sometimes listening to music is nice. But if it feels like a good option, then maybe use that time for podcasts. It's a good time. The other thing that I suggest and this has a lot to do with the quest for this week is to try sharp spikes. If you work in an agile environment, you're probably used to the concept of a spike. Spikes are great for learning about a new well, not a new technology, but a new something that's new to you so that you can remove some of the doubts so that maybe you can improve your estimate on a card or a feature on a story or something different. Agile teams use spikes for different reasons. And so I'm introducing to you a twist on that concept in this term called a sharp spike. You're not going to find sharp spike anywhere out on Google to find a definition of a sharp spike, because this is a term that I came up with. Who knows, maybe somebody else came up with it. But to me, a sharp spike is if you think about a spike, it's like this. So it's got a wide base. You maybe spend 8 hours on a spike. Maybe every spike should be time boxed here. This is some free advice. If anybody ever tells you, hey, go and do a spike on whatever. Don't walk away from the conversation until they give you a time box. Every spike for the rest of your life should have a time box without exception. So if somebody says go and spike on that tech or that thing, then ask them for what's the time limit they want. All right, so that was free. That's not part of the message for tonight. Just don't let spikes go without time boxes. It's horrible, really bad practice, and it really shouldn't be. Sorry, I'll keep on going. It really shouldn't be you defining the time box either. It shouldn't be you asking for a time box. It should be the people that know about scrum and agile that should be assigning a time box. But a lot of times they forget and so you have to help them. But definitely don't ever let a spike happen unless you got a time box. Okay, moving on. So a sharp spike, if a regular spike has a wide base, meaning it might be 8 hours, a sharp spike is very narrow. It has a thin base, meaning it's a very quick, sharp spike. You want to dive deep into something and dive right back out. And so the way you do this is you take a problem that you're working on and instead of solving the problem the way you normally do, which if you're a programmer, a full time programmer, you're solving 100 problems a day. So finding a problem is no problem. Finding a problem to solve is a piece of cake for us. Being intentional though, about picking a problem is maybe a little bit more challenging. So let's just pick something. Let's say you normally normally solve a problem from the front end, calling the back end using fetch. Let's just say you just normally use fetch. You're about to call an end point in the back end. You've been using fetch for the whole application. But there's this new cutting edge, really cool Http library that you want to try out that you've heard about them talking about on podcasts. This is a great opportunity to try a sharp spike. And a sharp spike is going to be you start a branch, call it your sharp spike, 109 branch, or whatever you want. Just something that is completely separate. You branch off from the same place that you start normally, and you're creating a very temporary branch that you intend to delete. And that's when you go ahead and load in that library. Try it right then. 30 minutes, 30 minutes time box. 30 minutes, 45 minutes tops. I mean, now if you feel like you're really, really bringing some value to your client or to your team or something like that, then you can let it go a little bit longer than that. But the idea here is not to waste anybody's time. It's to get in and get out really fast and experience some new type of technology or new way to solve a problem with just a very quick dive in. And then after you're done, you delete the branch and then you solve the problem like you normally would. So make sense. It's called a sharp spike. No one's going to complain about a sharp spike like this. A because it will never make it into the code base, and B because you just discovered whether or not a new technology might work and you've expanded your knowledge and thereby your team's knowledge. So the next time the conversation comes up about that library and they're like, I wonder if we should use this library. You happen to have a horrible experience using that library. In your sharp spike, you can speak up and say, Well, I've tried this and it did this and this. You've brought value to your team with a simple sharp spike. Okay, the other thing that I wanted to mention that is incredibly important or incredibly helpful as you are trying new things is to write about your experience, write about what you learn. So if you were to try that brand new shiny Http library and you try it out, it seemed good, or even if you don't have an opinion, but you just want to copy the code and put it somewhere, then start an account over at Dev To or start your own blog. And it doesn't have to be a long academic post. Just post something out there. Give it a quick title. Say, hey, I tried this. Be familiar with your audience. Act as if they're your friends from 20 years ago and say, hey, I tried this library out today to solve this problem. Describe the problem that you're solving. Say that this was my experience. I liked it. I thought it was pretty cool. I like to try it out some more. Here's some of my code paste. You're done five minutes. It doesn't have to be long or really time consuming article. But if you write about that and you publish it to the community, not only are you potentially helping them, but you're also helping to solidify your own knowledge. And so writing about things, posting about it publicly is a tremendous awesome way. Now, if you don't like writing, another way to post about something is to just grab loom on your computer or have a video recorder that's kind of really easy to use on your computer, where you can draw a box around a section and record screen videos and just shoot a video. If you're not scared of hearing your own voice, then shoot a quick video and describe what you did. Here's the problem that I solved here's. The code looks pretty cool. You should try it out. And then in and out. Two minutes. Two minute video. Post that sucker to YouTube. Now you're a YouTuber and you've helped the community. So these are things that you can do that don't cost you a lot of time, but really do. They can increase your social credit, they can help the community, they help solidify your own learning. And you never know. You might come back to that like two years later. And look at your old post about this technology that's now your bread and butter, the source of your existence is now this thing that you wrote about two years ago. It might be it might happen. I wrote about TypeScript years ago. That post is still out there. I wrote about actually writing Hubot with TypeScript, and I even wrote in my post that everybody thinks this is the stupidest thing that I've done, but I think it's going to take off. So now it looks like the smart one after six or seven years. All right, so let's talk about the quest really quick. So you should already see in the reply for the post where our Zoom link is, you should already see the quest for this week. It's actually called Sharp Spikes. Another interesting, another way to remember Sharp Spikes is that it's the bleeding edge, therefore it's sharp. So this is basically just asking you to do a sharp spike per day. Like I said, as a programmer, you're solving hundreds of problems a day. My challenge to you is to pick one per day, spend 30 minutes per day on a problem, and try to solve it in a way that you've never solved it before. Try out a new library, try out a new technology, try out a new NPM package, try to solve the problem in a way that you've never solved it before, even if it's going from okay, normally I solve this in an object oriented way, and in this case, I'm going to use a functional way, or this time I'm going to use reactive programming instead of this other thing, just spending 30 minutes on it. But in order to make this work, how are you going to know about which technologies exist? You're going to have to get into a stream. You're going to have to add the stream as part of your daily rhythm so that you are aware of what's going on. That way, when you find a problem, you recognize what kinds of problems that new technology solves. So I know that the quest is all about sharp spikes, and you may be completely ready for that. But I'll bet you're only going to be able to do the sharp spike if you also have something in your daily rhythm that is filling your head with all the possibilities that are out there. So I'm any questions about the quest for the week or any comments or questions about what we talked about so far? Not all at once. I'm thinking of a question, but I just lost it. Let me think of it for a minute. Sanchita, I know you're new, but you can always jump in and add something. So how do other people do you work on your side projects and try to complete your quest on those projects? Or it's like you're working in your office and that is confidential and everything. I cannot share that with community because that is confidential. So how do you work? Right? Actually, our quests are always meant to be done on your job, and you don't necessarily share the exact quest with everybody else here. The notes that the quest asks you to take are general. So it's not sharing trade secrets or secrets about your particular client or software. It's more like, let's say Axios. Let's just pretend like Axios is brand new and you normally use Fetch. So one day for your sharp spike, you choose Axios. So your findings about Axios would be more like, I tried Axios. I used it in this way. It returned this kind of response when I used it. I liked it because of this. I didn't like it because of that. None of that is trade secret. None of that is proprietary information. So all of that is completely fine to share. You can share it with everybody else here, but what you'll get is an email. As long as you start the quest today, you'll get a message on Saturday asking you've for your results. That's where you'll be able to paste your notes, and that will go to me, and then you and I will talk about that after a few months. And when it comes to writing about your experiences, the same thing. If you're going to do a video or a post on the web on Dev two or something like that where you're just trying to post and share your findings there again, you need to be careful to not put your clients intellectual property on your blog. But there are ways to do that that doesn't break any confidence or doesn't break any promises with your clients. You can remove certain information or you can start a separate project, things like that. There are ways great question. Yeah, but I'll say one more time, the quest that we do should always be done on the job. So I'm not necessarily you could be working on a side project and then you do the quest on the side project, which is fine. But to me, the bigger benefit is if you actually perform these quests on your actual projects. Like one week a few weeks ago, it was seeing the big picture. So the quest was all about you going to somebody in your organization that understands the project in its fullness and asking questions about the roadmap of the product, asking questions about Where's the product going, what are we doing here? What's the purpose? And trying to get a bigger, a bigger picture view of the product. And like Jorge said, that because of that quest, it saved his team two weeks in productivity that they might have lost if they had not gotten that kind of bigger picture. So I recommend highly doing these quests on your actual projects as much as possible. I'll never give you a quest that you can't do that. My goal is not only to help you, but to help your team through you. So I'll always target to give you quests that that are are doable on the job. What else? Great question. So I had an experience with spikes without a time box. Yeah. So I think we added like 8 hours for the spike because it was something that nobody was familiarized with. So it was AWS with Open ID Connect and OAuth frameworks. I didn't know anything about OAuth or Open ID Connect. So we needed to expose two endpoints but still be protected through Open ID Connect. So our platform was about notifications, right? We're using SendGrid for emails and Twilio for SMS. So we did our spike, we learned about Open ID Connect and blah, blah blah. So we closed the spike and we started solving the problem. So with SendGrid it was good. So we assumed that Twilio it was going to work the same way because it's like, I don't know if the two companies are related to each other because when you go to Twilio it says something about Sangrid and vice versa. So in the end we discovered that only Sangrid was going to work fine with Open ID Connect and we needed to implement our own authorized method for Twilio because it was not supported. So sometimes you can do a spy, but you have to think all the aspects like don't take things for granted just because you can assume things because you can find a Pandora box in there. So that's what happened to us. He cannot give us a hard work. Thank God we saw that on our side. So instead of Authenticating or IPI gateway endpoints through Open ID Connect, we created a land to intercept authorized proxy. It back in service. Nice and all. Good. So sometimes a spike is not enough, you have to really give it some time and study all the path like end to end. Right? So if you think, okay, I know where this is going. So I know the protocols. If it works here, it's going to work there. But sometimes. Yeah, well, I mean, you're actually illustrating a good thing here too. That I should mention. When you do a sharp spike, you definitely need to think through the scope of the sharp spike. So a spike that wide base spike that maybe has a longer time box, 8 hours, two or three days, sometimes for a spike, which is fine, those can take a really long time and their scope is massive. Can be. It might be just like, hey, go and learn how to use Twilio. That might be the spike. Go spend 8 hours learning about Twilio. That's it. So when I talk about a sharp spike, I'm talking about something that doesn't necessarily require quite that much research. I'm talking about a small problem, so I'm not talking about like choosing whether you use Send, grid, or Mailgun, choosing between sending grid and Mailgun. You might need a longer spike to pick which one. But choosing between Axios and fetch is a pretty small choice. Choosing between the middleware that I always use in the back end versus another middleware that is experimental. That's a smaller thing, and that's kind of what I'm talking about with the sharp spikes. Sharp spikes should be small enough that you can actually go in and out in about 30 minutes. Jr yeah, a good example can be I had one project where I was trying to paste the URL in the text editor, and I needed to choose from all the text Editors there were for Reacts, and one that was perfect for me was Quill and choosing one over the other. I needed to have mentions hashtags, being able to paste URLs and so forth. And I need to do that. And Quill was the only one that solved that issue. Yeah, and that could have been especially with Quill or a text editor. That is the kind of thing that's a very small thing. You could let's say you normally solve it with Quill and you want to try this other library that you've been hearing about. That's typically kind of a quick in and out kind of thing. You can just use a new NPM package, follow the instructions, the quick start to get it wired into the framework, and then you can try it may time side by side with something else, but always in a branch that you can easily delete the branch or stash your changes or whatever you like to do to provide yourself a way out to back out of something. Jorge I actually had to look, I didn't realize that Twilio bought SendGrid. Sendgrid used to be independent years ago, and I guess at some point Twilio decided to buy them. Cool. Yeah, but since same grid started out as its own product, I'm not surprised at all that they're not synchronized on how they work. Yeah. So kind of makes sense. Yeah. So about Http clients. I know it seems small and all that, but think about, okay, maybe I'm going to plan. Let's say I'm building API, so I'm doing the back end and you buy the front end. Okay, so you're required to use Axios. I'm not sure, but what happens if one of my end points is a get endpoint? But you are required to send a body in a get. Do you know if Access is going to support that? Well, I know a fetch would, but if we're talking about picking a sharp spike, then I might say I usually use Fetch here, but I want to see whether Axios could do it. Not because Axios is a new product, but because I'm curious about whether Axios can support that. And so in a sharp spike I might start up a branch, try it out real quick, see if Axios can do it. How does Axios react? Can I get that special case to work and then delete the branch when I'm done? Go right back to fetch like I normally do. And actually, I don't really know much about the scenario that you're talking about. So now I'm curious and I want to try it out. Yeah, it's because we had a scenario with one of our clients as well that they had 100 endpoints and we found that they were doing get with bodies so that's like they're not complying with best practices and all that. Because sometimes the body how does that even transmit? I don't know. But you can accept the body. If you're doing an API with ASP. Net, it can work, but it's not a good practice because some Http clients just don't support that. So that's what happens. And maybe you can think, okay, nobody is going to make a get endpoint with a battery, but then you start working just fine. And then when you hit the 50th endpoint, you need to send a body in a get request. I think that sounds really stupid, but that's actually a really great shark spike. Just like being kind of silly in our mind. I wonder what would happen if I tried to send a body with a get. Could I make that happen? And that could be a great sharp spike. That's a great little mental exercise too. It's like just try to make something. Do something that it's not meant to do. That's one way to be on the bleeding edge. Not because it's the right thing to do, but because you understand the borders and the boundaries that a tool has. That's a great way to actually try it. I mean, this would be really stupid, but like, try instead of a post, try a patch. Try sending in a patch request with a query string and a body and just see what it does. See if you can send in a delete, a delete verb as a put and see what it does. Actually, delete would be more like a get. But anyway, just try different things. That's actually a really good way to come up with a sharp spike. So if you're not sure whether you can find a library that's on the cutting edge or some new technology or some new method that you're curious about that other people are talking about, then just try to do something silly and see if you can test the boundaries of something. And we're only talking about 30 minutes here and it's throw away code on your actual project. Not a spun up temporary project, but on your actual project, try it out and see if you can get it to work. This is actually a really cool way to help you expand and help you also solidify what you're learning. So we're coming to the end of our time. I really do encourage you all to hit that link at the bottom of the quest as soon as you can, maybe even tonight to go ahead and just think really quick about what are your expectations for this. What do you expect to happen and that's the only field that you got to fill out to actually just start the five day timer that ends in the message that asks you for feedback. The only other thing that I want to mention to you is that next week is the fifth Monday in the month and the fifth Monday in a month. It happens once. A quarter is going to be show and tell. So we're going to break from our normal coaching pattern and we're going to have show and tell. So next Monday. What I'd like for you to do is for each one of you to bring with you a story about the worst thing you've ever done as a programmer. The worst thing you've ever done in software development. If you've heard my blog, sorry. If you've heard my podcast then you know I have a segment called confession time. We do that every time. I do that with every one of our guests and it's always a fun thing and so we're going to do that this time and show and tell. So bring a story. It can be funny, it can be sad, it can be horrifying. I will also bring a story. I've got a really good one for you about the worst thing I've ever done as a programmer and we will just have a good cleansing confession time and then we'll all leave the coaching program absolved of our programming sins. Okay. So I hope everyone has a great week. Enjoy these sharp spikes. Learn a lot and get into a rhythm. Get into a rhythm where you're hearing and seeing what is coming down the pipe. Okay. Alright. See everybody. Sanchita, thank you so much for being with us. Welcome. You all talk about this program. Get other people to sign up. Let's grow this group. It'll only get better. Bye.