113. Principles of Pragmatic Engineering

Speaker 1: Hello and welcome to Code[ish] an exploration of the lives of modern developers. Join us as we dive into topics like languages and frameworks, data and event driven architectures and individual and team productivity. All tailored to developers and engineering leaders. This episode is part of our deeply technical series.

Marcus Blankenship: Welcome to this week's episode of Code[ish]. I am just so excited to have as my guest Karan Gupta and we're going to be talking about the principles of pragmatic engineering. Karan, welcome to the show.

Karan Gupta: Hey Marcus. It's great to meet you. Thank you so much for having me on. I'm really excited to discuss this topic with you.

Marcus Blankenship: So why don't we start. Tell us a little bit about yourself.

Karan Gupta: So I'm currently at shift.com which is a marketplace for cars. So if you're looking to buy or sell your car, it's a pretty easy way to do it. I am SVP Engineering over there. So I run technology and product. I'm lucky enough to be part of the team that helped take the company public last year. Before that I was at The RealReal where also lucky enough to go through an IPO. And other than that, I advise a couple of companies, notably Alfie, which is a platform working for advancing women professionally from very early in their career journey. I also founded AliceApp.ai, which is a pretty fast privacy first recording and transcription service for investigative journalism. What else? A couple of companies before that. Yeah, I founded and sold collaboration startup and took it through into that. So it's been a fun few years.

Marcus Blankenship: So you have a long history in software engineering. And I think that's part of the reason I was so excited to talk about pragmatic engineering with you, because I do see a lot of people who miss the pragmatism. And so let's maybe just dive right into this idea, like what is pragmatic engineering?

Karan Gupta: Yeah, it's an interesting question. What is engineering in the first place, right? Like why did I get into it? I remember very, very early on when I got introduced to computers, it's like super exciting. I was using Basic to create these amazing graphics on the screen. And it's so gratifying. It's so much fun. Right. But then, as you grow up and also as the industry has grown up, technology is now in every part of every business, right?

Marcus Blankenship: Yeah.

Karan Gupta: So it's about kind of tying what we do with technology and the fun and the creative enjoyment that you have at technology tying that into the business. So I kind of define it as it's about having an oversized impact on the business by applying the right technology at the right time. So for me, pragmatic engineering it's about bilingual things, but it's not just about bilingual things. It's about the technology, the process of creating that technology and then its impact on the underlying business.

Marcus Blankenship: So you used the phrase oversize impact. What does that mean?

Karan Gupta: It's probably going to be different for different businesses, but essentially what this means is, think about the different kinds of businesses where technology is being applied now, everything from businesses that are very operations heavy, to sales, to selling ads online, or something which is very purely technology centric. Oversize impact means that the code that you deliver, you actually made a significant impact on the numbers that matter to the business. Whether it's top-line revenue, whether it's profit for an operational business that might be profit per unit, but the actual impact to the financials of the business. I'm a fan of like medium to small size teams, because it's a very quick line between the work that you do, to the financials of the business than it is in larger companies, but I'm pretty sure even at a larger scale, you can still see how the work that you do is having an impact on, for example, on earnings or financials.

Marcus Blankenship: Well, let's talk a little bit more about the pragmatic side of engineering. When we talk about pragmatic engineering, what kind of principles come to mind for you?

Karan Gupta: There are a few, and I've tried to put them down in order, but essentially what I think about is the four key things that matter. They are fastness, so the speed at which a user experiences your product. Then the next most important thing would be functionality, what are the capabilities that you're actually providing. And then after that is the form, how does it look and feel? And then finally, but still like really important is the fabrication of it. How is everything built on the inside? And we can look at a couple of examples that I can think of. You take something like Google, especially in the early days, just very, very simple. The only thing probably was search, but it was super, super fast. The results weren't necessarily perfect, but because of it was so fast, there was nothing else on there.

Karan Gupta: It just made it a pleasure to use. And you can see that with many, the most of the ones that we deal with, whether you're a small startup or a bigger company. No user ever said, "I wish this webpage was slower." Right? So I think speed like really matters. Then when it comes to functionality, it's about providing the right features that the user really cares about. So it's not about providing all of the features. It's not about providing the maximum amount of features, is if you give your audience just the features that they care about, even if they are fewer than say another competitor, but they're fast and they function the way the user expects, that's the only key differentiator for your business.

Karan Gupta: And if it is aesthetically pleasing, if those features, even though they are fewer, but they look good, they're easy enough to use because they're intuitive, again, that differentiates you from the business. And finally on the fabrication part, it's what maintenance. If you built them in such a way that they can be expanded upon, they can be maintained by someone else long after you are gone. That's a core and important part of the product as well. Even though the user doesn't see it.

Marcus Blankenship: Well, let's dive into fast. So I don't think anyone would disagree that fast is better than slow, but how do engineering teams start to see fast as a value that they should prioritize above the next new feature or whatever the shiny thing is that fastness, because you listed that and you said these were in priority order. So how can teams start to make fast a priority? Maybe what examples do you have?

Karan Gupta: It's not easy. Usually in businesses, definitely rolling out features is sort of our instinct, right? Story after story feature, after feature, epic, after epic, let's just get more stuff out there. And so I think design and product and engineering have to work together to make speed. And the performance of said feature part of the acceptance criteria. And famously actually GitHub was really good at this. They made it a very important part of launching any feature that it has to meet a certain performance criteria before it can actually be launched on production. And why not? There are a lot of best practices that we have learned over the years that we can use to find webpages, reduce JavaScript load, improve how [inaudible] is organized. And so on that if you took an extra couple of days or whatever it takes to speed up that same feature, 10, 20%, it might have a huge impact on the usability of that feature.

Marcus Blankenship: You know, I've worked at places where the VP would swoop in one day and say, "The system is so slow. This thing needs to be so much faster than it is." But what they failed to tell us was the part of the system that needed to be faster. It was just a very blanket statement. "It needs to be faster." And therefore the engineers ran around in a pretty chaotic way trying to make everything faster, but that doesn't seem like a good approach. How do we know what to make fast? Or how do we know what to prioritize in our search for speed?

Karan Gupta: I mean, if you look at any... And let's focus on let's say web apps, because that's most of our interactions with computers these days is through web apps. Even if you're opening up an app on your phone, it's still powered by a web server somewhere out there. So there are definitely many layers and that whole request response cycle, where there are opportunities to make things faster. But generally what I'm talking about is about what the user experiences. Network latency is a fact, you can't change that, right? So if your user is on a 3G connection, for example, you as a backend engineer, can't really change that. But what the team as a whole can see and can figure out is, "Okay, you know what? This person's going to face some latency, let's put in something educational to show them that this is what we are doing while they're waiting."

Karan Gupta: Apple has been really good at this way. Like they would usually give you a few bullets or something like, the system is being set up, et cetera. So you kind of know that this is what's going on. So you have a feeling of that you're a part of the system being set up even though there is latency in it. I mean, it could be at the network level at the database level, wherever it is. Getting very tactical though, of course, things like database queries and so on. Those are things that most engineers know that they should tune in and keep tuning throughout the life of the system so that things get better. And the front end, that's another area which has recently began to become fatter and fatter. So there are obviously things there where you can find tune. Maybe you have five analytics livery's, whereas you could survive it two. You know? So there are things like that which teams could think about and discuss with their business partners to introduce performance into the system. But I mean, there is a one pet peeve I definitely have, which is around showing Spinners.

Marcus Blankenship: I was going to ask, I feel like Spinners were all the rage 15 years ago when Ajax was introduced.

Karan Gupta: Yeah. And like I said, latency and delays and so on, they're part of just how the internet works. It's a fact. But I think when we show Spinners without showing a progression, without showing an ETA, without showing, "Hey, this is what I'm trying to do behind the scenes." Pardon me? But I think that's a bit lazy. I think design product managers can come up with something better to inform the user that, "Hey, this is what we are trying to do. So just give us a sec and we'll get there." And so one of our personal goals is getting rid of spinners. And using those as opportunities to inform the user that, "Hey, this is what we're doing behind the scenes." So they can learn a bit more about a product.

Marcus Blankenship: I love that you would intentionally design for that space. It reminds me of when 404 pages went just from being the number's 404 on the server to an opportunity to help. To say, "Oh, maybe you meant this." Or like, "If you're confused, start here," and we see really nice 404 pages now, which take advantage of the fact that problems occur. And sometimes things don't go right.

Karan Gupta: Oh, that's a great example, Marcus. Like some of them, I don't know if you remember, some of them started building the snake game.

Marcus Blankenship: Oh yeah.

Karan Gupta: On 404 pages?

Marcus Blankenship: That's right.

Karan Gupta: It almost became like branding and marketing landing pages, right?

Marcus Blankenship: Yeah.

Karan Gupta: Because that's interesting.

Marcus Blankenship: Well, let's go to the next one and these are in order. So first we started with fast. The second one on the list is function, providing the necessary capabilities. This one seems obvious, but where's the pragmatic approach to function.

Karan Gupta: There are always going to be more and more features that we think we want to introduce into our box. I mean, how many products do we know that have reached an end of life stage? In software that kind of doesn't happen. You're always adding something to it. Right. And you're very, very rarely taking anything out.

Marcus Blankenship: Yeah.

Karan Gupta: And what I'm trying to say here is, with the feature set, it's about being very conscious that once you add a feature, it's probably going to be there forever. It's probably going to need maintenance and love and care forever. So do we really want to put it in? So to use a common phrase, less is more in this scenario. Which is, for example, let's say you're on an e-commerce fleet. You could have search, pivoting, filters, three different kinds of ways to layout your grid of products and so on. I mean, maybe you only need half of that feature set. But but you can be sure that by going with half of that feature set, it's going to be faster versus introducing those two or three extra ways of navigating the same list of products. That I think is a better combo than having two more ways of navigating that list but now the entire thing's a little bit slow.

Marcus Blankenship: I'm curious, you mentioned this idea that we almost never take things away. You are exactly right. Are you an advocate for removing things that either we notice our customers are using as often, or I'm just curious, do you make it part of your engineering life cycle to remove features or UI elements or other things?

Karan Gupta: Absolutely. I wouldn't say I'm very good at it because usually we aren't looking for those things. Usually we are leaning towards what is getting the most usage and let's keep improving it, keep tweaking it versus what is not getting used here so let me remove it right.

Marcus Blankenship: Right.

Karan Gupta: But there are opportunities like, sometimes hackathons and things of that nature can create an opportunity where you can step back, look at what's going on, gives you that chance to be a little bit thoughtful about your product, and potentially then you can take out certain features and definitely in favor, but I'm just saying it is hard to do in practice.

Marcus Blankenship: So being careful and intentional, what we build, knowing that it might take a day to add a feature, but we're going to live with it for a lifetime. Just having that mindset. I love that. Well, how about this next one? So we had fast. We had function, now we're going to go to form. Everybody seems to want things to be beautiful, but I have seen too beautiful sometimes. Where is pragmatic form? What does that look like?

Karan Gupta: I deliberately put this after speed and functionality. Is like, once you have the right things and the user is experiencing them in a performance way, then you have to think about how those features are actually presented to the user. You know, a few years ago we started seeing this trend, right? Where you have flat buttons, we remove shadows. And even to a certain extent, just getting a bit tackier under the reels about using things like links where you should have buttons and using buttons where you should have links and so on. It is just what happened within us. Like as an industry, a few of these changes, but what happens a side effect of that is people who are say, using screen readers, now suddenly they start having a harder time, or people who are used to noticing buttons a certain way, maybe they don't have the latest gadgets with the latest high-risk screens.

Karan Gupta: It's a little bit harder for them to find the thing that they have to click. So I think it's balanced between, of course, let's design something beautiful and pretty, so it's aesthetically pleasing, but it's also something which is intuitive and straightforward for these users to get to. So a couple of things I'd like to talk about with my design teams is, are you reducing cognitive overload. Are you reducing IU traveler? Are things kind of where the user expects them to be, even though they might not fit perfectly into this beautiful design matrix that you're trying to create.

Marcus Blankenship: So I turned 50 last year and I'll be honest. I have a hard time seeing thin fonts with low contrast between the font color and the background, but my younger peers, and then colleagues don't have this problem, but sometimes I really struggle and I wish the designers didn't have such good vision at times.

Karan Gupta: So one of the ways that we are trying to tackle this both at my [inaudible 00:17:12] company and on the place where I work is forcing us to change the browser do use the view ports that our users will use. Most users are now actually using websites on their phones. This is pretty common knowledge now, right? And so we have to make sure that when we design our product, you're actually starting with the mobile web design first versus desktop first. I mean, just making that culture switch, that itself feels such huge benefits for the customer. And it's ultimately has a good impact on the business because you're designing it within the constraints that the user is going to be living in.

Marcus Blankenship: So I want to back up here just for a minute, because we did put form after function, but in places where I've worked a lot of times the designers get the project before the developers. So for example, there's some new screen and product says, this is what it needs to do. And they go to design and the UX people do the wire frames and the designers do visual designs. So all of that form gets laid out. I think a long time before maybe some of the functional things are thought of, and once it hits Photoshop, it's hard to change just to be honest. The designers get pretty darn attached, just like engineers do to their work. So do you have a kind of a process that you prefer that prioritizes fast over function over form? I mean, any thoughts on what we should do differently?

Karan Gupta: That's actually a really good point, you know. Especially the one about once things are in Photoshop and they look in a certain way, you do it at Ashwood, but then it doesn't translate into reality the same way. Because HTML and CSS don't exactly look the same as they did on a Photoshop on a first or document. Now, some of the tools that we have no like Figma and so on, I think that definitely helped me make that translation easier. I also think tactically, it helps entire team if engineers get involved early in the process, they get involved at the idea stage. Because I think the three working together probably design and engineering very early, it helps the business overall. Like first of all, engineers might have a totally different radical solution, which is simpler and quicker to get out. Which is great for the business. Great for the product owner, everybody, right. Or they might be able to call out certain things in the design, which the designer just as a nature of their work might not be conscious of.

Marcus Blankenship: I got to tell you, HTML check boxes and drop downs, come to mind. I've seen designers spend weeks trying to make it look like a Photoshop mock up. When if the designer had realized what the browser could do for free, essentially, they may have made a different choice.

Karan Gupta: Yeah. You know, some of the best designers I've worked with, they took the time to start learning a little bit of CSS. They're not going to become coders, but they love to use the inspect tool in the browser and start changing things on the fly to get a feel for what different variations might look like. And then take that into Photoshop or sketch or Figma or whatever they're using. They get the limitations and they get the opportunities that are available to them.

Marcus Blankenship: And it goes back to fast, using the built-in power of the browser, use it the way it was meant to be used and it will naturally be faster.

Karan Gupta: Yeah. And I mean, there is one real legit example actually from one of the companies where I've worked at. The team wanted to put in a fancy JavaScript dropdown, which looks nice, it feels great. You can put little icons, et cetera, but it just doesn't work for keyboard based navigation. And it took an industrial researcher who came in and looked at how different employees were using that various aspects of our internal product with that dropdown to tell us that that dropdown and the fact that it doesn't work great for the keyboard is costing us millions in revenue.

Marcus Blankenship: Holy cow.

Karan Gupta: Yeah. Because it added up, it took an extra three seconds, that's approximately 30,000 hours being added to the business.

Marcus Blankenship: Oh my gosh. That's amazing. Well, our last item here I thought was really interesting. So we've of course, as you've heard me repeat, we've hit fast function, form. Now we're onto fabrication. Why is fabrication interesting? Why did you list that in these principles?

Karan Gupta: I think it just comes from this years old, love of coding. It's like art and you can recognize good art if you're an artist. And the same way, if you've been a coder for a while, you can recognize good code and you can recognize bad code. And it just feels good to look at good code, doesn't it?

Marcus Blankenship: It does.

Karan Gupta: It's some of the livery's that we end up using some of the things that are really popular. I mean, they are that way because people gravitated towards making them even better and more useful, improving them, keep refactoring them because they're beautiful bits of code. And I mean, we call our subject computer science, but it's actually more like, it's not an exact science, it's a bit of an art, but yes, it's also a science. So for this particular topic the way I think what it is, is how you're making a product, the way you're constructing the code, the syntactical rules that you use, the coding guidelines that you have within your team.

Karan Gupta: All of those things really matter because even though the user is not experiencing it directly, even though the business is not dealing with that directly, it has an impact on everything else. If the insights of the machine are great, well, it's going to perform well for years to come. So that's kind of what this one's about.

Marcus Blankenship: Reminds me of how on the outside, I've been noticing a trend with cars that KIAs are now looking more like Mercedes, and it sort of tricks me sometimes. But I always imagined that what really matters is actually under the hood, underneath the paint. And I don't want to say KIAs are poor or anything else, but to me, it's clear that the fabrication has a lot of differences between cars like that. And I do think that it matters in the end to the experience the person has and probably the mechanic. I think you mentioned this earlier, we talked about how long features live. Is there an element to remembering the time span of our work as we fabricate it? Like this is going to be around a while.

Karan Gupta: Yeah, I think definitely. You have to think about, once I code this up, or once I include this livery, which looks like a quick hack right now, we may be stuck with her for a while. Like long after someone's moved on to a different team, or even if they moved on to a different company, another coder, another engineer has to now maintain that, maintain that feature and that livery or two that we introduce to support that feature. So something which is a quick hack and a useful hack at the time may end up being a burden two years from now. So this is definitely worth thinking about. Another aspect of this is actually, it's also not reinventing the wheel. Our industry, we've done a lot of things over the past few decades, web development, especially mobile development.

Karan Gupta: A lot of the things have matured. I can remember when ORMs were so complicated and new and I'm giving away my age year. But when trying to do this with Java many, many years ago, well, there wasn't a standard conventional process for how or how you were supposed to work with databases. Everyone kind of had their own flavor. And we reached a stage now with several frameworks where there are certain conventional processes we can take advantage of. So when it comes to thinking about how you construct your product, it's worth thinking about, is there something off the shelf that I can leverage, which is mature, which is well thought out to handle a lot of scalability problems or maintenance problems so that I can focus my time on things that are unique to my business and to the users in to the myself.

Marcus Blankenship: What about the old phrase, "Perfect is the enemy of the good enough." How does that fit in a fabrication principle?

Karan Gupta: I've seen this happen sometimes, and you see this more with certain teams, which may be more like design oriented and by design oriented, I mean like technical design oriented, where you're trying to perfect what you're going to make using documents, et cetera, before you actually started implementing that technology. Right? And what that does, I mean, it's great. It's great have those discussions and it's great to reach alignment, but if you don't time box it, you can get into analysis paralysis trying to figure out every single edge case, which can take much longer than simply creating a POC, which we'll show you in a much quicker manner, if this is even feasible or not.

Karan Gupta: Another aspect of this, getting closer to say to the features that you're trying to provide, your user might be that if you want to test something out, you feel like you have an inkling, you've done some user research is showing you that this particular feature is something that users might want. Then you could either spend something like, I don't know, four sprints making it really high quality and releasing it. Or you could do a small POC, which you expose to a small group of your audience, your users, and see what kind of response you get spending very little effort versus trying to get it perfect from the get-go.

Karan Gupta: And I think, I mean, this is like a lot of startups not follow this mentality, which is, just moving quickly and iterating. So I really believe in that.

Marcus Blankenship: Well, in our last moments here, I would actually like to do some quick hits on what I call tips and traps. Because I have a feeling that you've got some things for us to avoid and maybe some things for us to do. So some do's and some do not's. Let's start with those things we should avoid. What do you got for us?

Karan Gupta: I'd say when thinking about putting out a certain feature set, or if you are very young company thinking about the startup and being very conscious about your budget and your runway, or even if you're a big company, don't start with the technology choice. We have this particular product or this particular feature that we are going to put out for users to use. So we need to get people to visit our site. They should find us easily. So our SEO must be good. Our pages should load fast, hopefully hit 90 plus on page speed insights. And we should be able to move quickly enough so that we can tweak things as we are observing our users behavior and attention to our product. And we have to operate within the constraints of X money and Y time. So once you think about it from walking backwards, from what you're trying to deliver, I think then you have much better insight on choosing the right technology for the job. I mean, maybe you write your web app in the act, maybe it's using the we on rails, or maybe it's just putting your site up on Shopify.

Marcus Blankenship: What, that's not engineering, is it?

Karan Gupta: But if it's good for the business. That's kind of like this one way to think about it and it may seem obvious when you hear it. Like, of course, but I've seen this happen with a few different teams where we start with the technology because we love it and we enjoy it. But I think it says a business and of course, your own personal learning, much better if you tie that technology choice directly to the business impact that you're trying to have.

Marcus Blankenship: Okay. We're not going to start with technology choice. What's another trap that you see people fall into, or you can choose Karan, that tip. You choose which one you want to hand us.

Karan Gupta: Yeah, let's go the tip next. I think this one again, I suspect that these will sound obvious once we will hear them, but be a learning organization. I've seen this with some really stellar engineers. They're really good at what they do, they're really strong in certain things, but they're always open to learning a little bit about what new thing is coming out. They are open to very different opinions. They're open to different frameworks, different ways of thinking. I mean, I've actually experienced this with Elixir and Phoenix. I mean, Elixir and phoenix are taken off, especially within the Ruby on rails community, but it's great. You already had a strong framework and feature sets that you could have relied for the next many years to come, but still a strong engineers choose to open invest in something like Elixir and Phoenix, and now it's helping them in different ways. Right?

Karan Gupta: So I think being a learning organization, if you want to make engineering your career, I think you kind of owe it to yourself to keep picking up what's out there and it'll help you make more informed choices, and it could be that your choices to stick with the tried and tested, but at least you will know that you look at the other options.

Marcus Blankenship: Yeah, absolutely. I think engineers love to learn. And I think I always look when I'm hiring engineers. I look for those that are really curious about other ways to do things. Not that I want them to spend all their time outside of work doing that, but do you have that curiosity and are you looking for opportunities to learn with every project? All right, well, let's do two more tips and traps today. So you pick, what do you want to hand us next?

Karan Gupta: Next might be the, be aware of the sunk cost fallacy.

Marcus Blankenship: What? Okay. You're going to have to start by telling us what that is.

Karan Gupta: All right. So this phrase might actually feel familiar to quite a few of your listeners, but let's say it's something you've already paid for, which has no impact on our decisions about the future, right? So let's say we build a lot of custom code around code deployments and at the time it was the best option. So you spent a lot of time on it. You spend effort designing a good system. You have a team that is dedicated to maintaining that code deployment pipeline, and the business spend a bunch of money on it. And over the past few years, we continue to spending money on it to keep it up and running. But now, Heroku comes on the scene. And I say this as a happy Heroku user, of course, I'm not being paid to say it I've used it for many years.

Karan Gupta: And I've also used GCP and AWS for many years. But like Heroku comes along and code deployment is now a piece of cake. Is just auto deploy. Is it automatically runs your tests. Everything is quick and easy. Now you have a fork in the road. You can continue investing in this beautiful code deployment pipeline that you build, or you could leverage this new and simple thing that's out there right now. And that's kind of the choice that you have to make as an engineer, as an engineering team, as an engineering leader, right? Is the time and effort and money that you spend making your own code deployment pipeline. That's already a sunk cost. Now you have to think about, do we keep putting more money into it or do we not?

Marcus Blankenship: So the fallacy part comes when we think, "Well, we've spent so much, we can't abandon it. I mean, we spent years on it. We can't just throw it away."

Karan Gupta: Absolutely. And it's also a little bit emotional. It's natural for people to get emotionally attached to a project or a technology choice that they made. Especially if they themselves made it. But going back to where we started, like if our north star is oversize impact to the business with technology, then we kind of owe it to our team, especially to our future team and the business to think really tactfully and rationally about choices going forward. So we have to keep what we've built, keep what we've done, keeping in mind, but kind of don't let it stifle us. The whole point of doing engineering is because it's creative and it's fun. So it'd be better if we continued thinking more things that way.

Marcus Blankenship: All right, last tip or trap, what do you have for us?

Karan Gupta: We kind of touched upon it, but I'd said, don't forget about maintenance and support. Really think about the cost of anything being added. And I'm talking about more internal right now. A quick hack now may cost a million dollars to repair in four years. Anything that you build, like it has to be supported, livery's have to be updated. So it pays off to take a little bit of time thinking about what you're putting in before you open up the PR, with the latest livery. It seems pretty cool and fashion right now, but it might be out of fashion sooner than you think. Like react and view TypeScript they are kind of the top choices for front end engineers right now. And a few years ago it was Angular. Not saying Angular is gone, but I don't about it as much as a year word React anymore.

Marcus Blankenship: Before that it may have been Ember or Backbone. And before that it was jQuery. And yeah, I think that's a great point and a great way to end the show. Karan, thank you so much. Tell us where people can find out more about you and your company online.

Karan Gupta: Yeah. Thanks. Thank you so much Marcus. It was awesome to talk to you and thanks so much for having me on the podcast. You can find our work on shift.com. I am Karanmg on Twitter. That's K-A-R-A-N-M-G, and I can also be emailed at karanmg.com.

Speaker 1: Thanks for joining us for this episode of the Code[ish] podcast. Code[ish] has produced by Heroku, the easiest way to deploy, manage, and scale your applications in the cloud. If you'd like to learn more about Code[ish] or any of Heroku's podcasts, please visit heroku.com/podcasts.