Chirag Dugar is a Software Development Engineer - II at Javis. He begins the show by talking about transitioning from being a college student to a Software Developer. He also shares his past learnings in coding and making connections during his internship. Moreover, he discusses his React projects, his experiences in creating those and his challenges.

Welcome back to React Roundup. I'm your host for this week, Jack Harrington, and with me is my esteemed colleague, Paige Neateringhouse.

 

Hey everyone.

 

And we have a special guest today, Sharag Dugar. Hi, Sharag, how are you?

 

Hey there, hi, I'm doing good, what about you guys?

 

So can you tell us a little bit about what makes you famous enough to show up on react roundup podcast.

 

I wouldn't call myself famous, but yeah.

 

Oh no! Come on! Don't sell yourself short. Okay.

 

Okay,

 

Yes.

 

so yeah, so I'm Chirag and I'm working as a software developer in a startup called Chavez and it's based out of India. So here, you know, I've been closely working on React for a long time now and exploring a lot of things in that, you know, from writing code from scratch and, you know, from optimizing them from improving the code quality, code structure and working a lot on that basically.

 

Yeah, I get a lot of questions about that, about how to structure your code, how to do things like CICD. And it would be great to kind of talk about your experiences going from coding school or college or university into the real world, and what you needed to learn to do that. So like, what do you think was one of the biggest things that you need to change when you made that transition?

 

Okay, so I think the first thing that you have to change is the mentality. So you shouldn't be sitting and thinking that you are still in a college and you know you're working, you're not making a project now. You're actually

 

Right.

 

building

 

Yeah.

 

a product. There's a big difference in making a project and building a product. So the amount of thought process that you put in, projects are basic, it doesn't matter as to what coding style you're following, it's just a one-time thing. But a product is something where you have to scale up things. You can't just make something and you know... Just leave it for the other person to come and figure out things and ask him to fix them out. So the major thing was that when I was transitioning from my college days to my company, I realized that there were a lot of things that I didn't know about. In college, you usually feel that whatever you know is everything.

 

Hahaha

 

But then when I came in here and you get to know that there is so much more to explore, there's so much more you can look into and identify. And even a lot of problems or a lot of challenges that you come across, which you would want to cater to, definitely.

 

Yeah, you start to learn that you know nothing. In fact, actually,

 

Yeah,

 

it's the entire the opposite. Yeah, exactly.

 

I'm gonna

 

exactly.

 

go to bed.

 

It's like, you know, from knowing everything in college to coming to the industry and knowing that you know nothing. But that's exactly

 

Yeah,

 

how

 

and

 

it sounds.

 

I always find it interesting to see the different coding styles that companies have and

 

Mm-hmm.

 

try and figure out well, you know, I think early on in your career, you're like, Oh, this must be the way that it's done. And then you find out, oh, actually,

 

Definitely.

 

no, it's done like 10 different ways. And that was actually terrible. You know, that kind of thing.

 

Definitely, yeah. That's how all of us feel, you know, when I'm writing the best code when I'm in college and then when you come here, like this is probably the worst code I've ever seen in my life.

 

Yeah,

 

It's exactly,

 

oh

 

you know,

 

my god. Yeah.

 

I mean,

 

Yeah, closed

 

in fact, you

 

source

 

know, even

 

code

 

when you're

 

is some of the worst.

 

working in a company and then, you know, it's been a year, let's say. So if you look back, you know, look a year back and you see as to what, who had written this piece of shit? I mean, like, you know, you can't even,

 

HAHAHAHA

 

you can't even digest this. Like, was it me who wrote all that? So, you

 

Ha ha!

 

Yep,

 

know.

 

happens to

 

It's

 

us

 

just

 

So

 

all.

 

a phase.

 

true.

 

It's a phase. Yeah.

 

So true.

 

So Sharag, one of the things that you mentioned was that you, were you actually getting to write React in college because that's

 

Thank you.

 

something that I've heard from a lot of developers is that they start out writing Java or they learn C++ or something else that, you know, may be applicable if you're doing backend development, but a lot of people don't really seem to get a lot of experience with front end before they actually get to their first job. So was that something that you did get a chance to use?

 

Yeah, so, you know, in my college, I had a lot of opportunities coming up on the way. So, you know, I had a lot of there were a lot of hackathons which were being conducted in college. So hackathons are the best sources for learning any, any technology for the matter. You know, be

 

Oh

 

it

 

yeah,

 

react, be it a

 

agreed.

 

front end or a back end stack. So hackathons are one of the major pushing thing, pushing points. And then when you start working on projects, when you start building something, you know, sooner or later, you realize that you've made something, but now you want to see as to what the industry wants, or let's say you just start picking up small internships. It might be a basic one, you know, to build a basic web page or to have a website with basic functionalities. But when you pick it up, it boosts your confidence and it helps you, you know, get deeper into the technology. So that was, you know, you know, and once you start doing a project or an internship, there's no going back. You look up to the next one and you look for more challenging ones. So that was the major, you know, push point that helped me learn or probably, you know, make a lot of projects or work. in a lot of companies as an intern.

 

Yeah. So you would say that, you know, some of it was definitely learning in the classroom, but a lot of it was you going out and looking for those opportunities to expand your skill set and your knowledge and your experience.

 

Definitely, you don't learn everything in the classroom. Industry, knowledge is not something that you get while sitting in the classroom. You have to go out, you have to explore, you have to talk to people. That's how you get opportunities and you get to learn new things.

 

And it

 

So

 

changes

 

what kind of,

 

so much. Sorry. Okay.

 

yeah,

 

Yeah.

 

it does. I was gonna say, so what kind of advice would you have for people who are getting into the industry who are maybe still in college, or still in coding bootcamp? Like how did you find those internships or make those connections? Like how did you get out there and actually get into those positions?

 

Okay, so that's in fact actually pretty difficult to start because when you're looking for your first internship, you don't have any experience to show. You know, when it comes to the second or the third one, you already have two internship experiences to show and the company can trust you on that. But when it comes to your first internship, it's just your projects that stand out. The first important thing is that you need to have good projects, you need to have projects that ensure or that show your quality of knowledge in React or any tech for that matter. Once you have that, getting your first internship becomes easier. And then after that, after you get your first internship, then it's all around, you know, how you are hustling and how badly you want to, you know, how fast you're finishing up projects, how fast you're grasping things and moving to the next ones, the more you, you know, we'll try to do the better to become.

 

Totally agreed.

 

So

 

Sorry.

 

did you have like a portfolio website or how did you show prospective employers that you knew React that you had the skills that they were looking for? Because that is definitely something that I've heard from a lot of people who are just getting into the industry. And it is so true what you said. It is impossible to get that first job because you don't have the experience. But once you get the experience, then you can get the first job. And it's just an awful cycle until you do. So, you

 

Yeah.

 

know, how, how do you, how did you do it? How did you stand out and say, I know what you need and I can do it for you.

 

So it was pretty difficult, you know, so I started out by making projects, as I told, you know, I made some projects and then, you know, I opened up random portals and tried applying for internships because I wasn't getting any one because, you know, because of the reason I just gave. So, you know, but I kept applying because there's no end to applying. You can always apply to any number of companies and you might not get a response from all of them, but you can still apply and you can keep trying. So that, that was just what I had done. And maybe, you know, one thing that I... couldn't do then or I didn't do then was making a portfolio as you mentioned. A portfolio

 

Mm-hmm.

 

I realized after my college was a very crucial thing because you don't have to explain anything. The portfolio does it for you. So it was only after college

 

Yeah.

 

that I realized that I should have made a portfolio and that would have helped me more. That would have gotten me better opportunity as well.

 

You've also written some articles. What do you think those would help people who are starting to look for, or looking for jobs? Get your name out there.

 

Yeah, definitely. So I wrote a couple of them. One of them was around building a CI CD pipeline using React and AWS code build. And the other one was about using the best practices for writing a React project. So as and when you're getting deeper into a code base, a React code base, it becomes very important for you to understand that the structure that you're writing. Is that the correct one or are you messing up somewhere? Because... If the base is not set correctly, then anything after that you do is always incorrect. And people start following you. You know, it's not that, you know, after

 

Mm-hmm.

 

a tons of code has been written, no one sits and no one wants to sit and revamp the existing code piece just so that they become better. You then know that they can make it better. But then who puts all these efforts then? So,

 

Right. Right.

 

so this was something that I realized that, you know, if you're getting into a new company or if you're getting in any company for that matter, and if you're working as a React developer. then you should be looking at the structure that you're following. That's very crucial. That helps you to understand as to what you're writing, helps the other person, your fellow colleague, to understand what this code says, and makes everything, makes your life simple basically. That was what I wanted to put forward in my article, because I could see that, me, when I was working with my peers, my colleagues, there were different practices that everyone used to follow. So, everyone has their own thinking, everyone has their own thought processes. You can't say that someone's wrong, but like you, but you can surely devise or you can come to a middle ground. This is probably a better approach. All of us can follow this. That was what exactly I was trying to do to, you know, get onto middle ground, which probably, you know, if everyone uses, it's going to become very simple for everyone to understand code, to make them readable, scalable.

 

And I gotta

 

So

 

say

 

can you.

 

those sound like great, huge articles like doing CI CD

 

Thank

 

and

 

you.

 

project structure and all that. I think what people miss is sometimes like 500 words is a good article. You know, sometimes you would just want to know how do I get the width of a div, you know, and that's it. That's it. It could be like one code fragment and the little paragraph below paragraph below and now boom, you're published author. See, it doesn't need to be anything huge. You know, just get out there with like whatever

 

Yeah,

 

you got.

 

definitely. Less is more, you know, it's correctly

 

Yeah.

 

told. Less is more.

 

Yeah, yeah, yeah.

 

So

 

नुदाटो

 

I'd love to hear what are some of the best practices that you've learned about building React projects? Like how would you, if you were going into either a new company or starting a new project, what would you recommend to have a good project that's gonna scale and be around for a long time?

 

Okay, so I'll talk in terms of the article that I've written first so that it becomes easier to understand. So when we are writing any React code, we all definitely know every, or at least some of the components require an API call to be done or interaction with the backend, I have to say. So now what usually we tend to do is have everything in a single component file. We don't segregate the logical part and the UI part of it. So that... clutters the code as and when you're making them bigger, as and when you're introducing more UI components, more logic's coming, and it becomes more difficult to understand what the code says and you know, from where, basically what are the touch points to my backend. So what I tried to explain in my article was, to ensure that you follow another format, you follow a structure wherein you decide or you devise as to, there's only a central point from where all your APIs being hit. There are no multiple points or multiple touch points in your code. There's a central source file which is responsible to trigger any backend code of yours. So, you know, that might be, you can structure that in multiple, you know, terminologies or you can make multiple, you know, logics behind them. But the one that I followed was having a, you know, using a component split logic. So let's say if I have a component A and if that component A is responsible to fetch data from a particular back-end API. So I wrote another file or let's say, let's call it a request file, which is responsible to call that endpoint. So what I had to do in my component file was to just initiate or just call the function. That does my job. You know, if I'm interested in knowing as to which API is being here to what body is being prepared, I can always open that function in my request file and look up to it. So that ensures that I'm not cluttering my UI components with my API parts. So it's keeping them different. And you know, by centralizing all this, now let's say there are, in a, as the project gets bigger, there's not just one or two API calls that you're doing, there are N N number of them. So let searching for them throughout the code base is another pain.

 

Mm-hmm.

 

When you're structuring them, when you put that in, you know, in a single file, which says, let's say a URL.js, which has all the backend URLs that are supposed to fit. Obviously,

 

Mm-hmm.

 

you know, you can make an object, you can define. what hierarchy it has to be. But when you do that, it makes it so much cleaner and so much more readable. You're not confused now. You know if tomorrow if I have to add a new API, if I have to do a new backend call, I just need to add an entry in my URL.js and then I just need to call a function or define a function that is hitting that API with whatever the method you're passing to it, with the body and then you just call that function your UI component page. So it makes everything very structured and very simple. Yeah.

 

Have you done much TypeScript?

 

I wanted to explore a lot but you know again you know as you are already so my company's code base was already you know set up before. So now

 

Oh, okay, so it's

 

moving

 

already in JavaScript.

 

an existing project, no it was not in Tri-Frick but moving that to Tri-Frick was another challenge. You know as and when it got bigger it becomes more of a problem because a lot of dependency conflicts are coming in. So I'm still you know kicking and I'm fighting for it because we need Tri-Frick

 

Ah,

 

and that's like super crucial.

 

nice, nice. So what do you think the big wins are going to be for TypeScript? Like when you say you're fighting for it, what do you tell your bosses? Like, hey, it's going to do this or whatever.

 

That's another thing that you know not everyone understands as to what impact they're going to create using you know TypeScript But then it's just that the developers It's especially the developers who know what impact it can create You know we as individuals when we are writing code we get to know what the you know if this code is going to break If I'm already informed about it, then I don't have to break my head after it's gone to production I know it then and then and I am solving all my issues, you know at that instant Well, that's something that you know, I want to pull in for sure I mean, in fact, there are a lot of things that you want to pull in, but you can't do everything at a go. You have to go step by step. You have to transform things one at a go.

 

Mm-hmm. So tell us a little bit about the CI CD pipeline that you built. I'm interested to hear how you incorporated React with this because when I've built them, it's

 

Ahem.

 

only been either shell scripts or GitHub Actions or some kind of combination of the two. So how is it for you? Like, what were you trying to build a pipeline for? Was it for work or was it for school? Yeah. Tell us a little bit about that.

 

So everything that you do, you find a pain point somewhere. A pain point is something that triggers some new learning or maybe a new development from your end. So that was exactly my pain point. When I was sitting around and when it came to deploying things on my dev environment, on my dev servers for the business teams to test, I had to sit for like half an hour, wait for the system to build my React project and then go and go to, and all my... you know, companies architecture is set up on AWS. So we use S3 for deployments. So I had to go to S3, you know, upload that file, wait for that, validate cache, and then all that process usually used to take 30 minutes. That used to make my system unresponsive, totally unresponsive. It was like when I'm building it, I'm only building it. I can't do any other work. But that became annoying after a point, because let's say when you had to make a small change, you know, let's say UI fix maybe, or like a small tweak and push it to the dev servers, that's again a pain. You know, you've... Fixed it for two minutes, but I have to sit for 30 minutes to deploy it. So that's, that's, you know, that was a very big pain point for me, which, you know, which led me to firstly understand. So I tried a POC initially, you know, I, you know, I hope you by the word of neck leafy, so, you know, I tried,

 

Oh, Netlify,

 

Yes,

 

yeah.

 

uh,

 

Mm-hmm,

 

Netlify,

 

yeah,

 

sure.

 

that's

 

yep.

 

fine. Yeah. So, uh, you know, initially I made a POC on that and I, you know, I tried doing it through that. So it worked perfectly fine. And it was perfect. But then. Since we had all our architecture set up here, I obviously wouldn't want to create an overhead by having Netlify in place. So my next task was to ensure that I create a CI-CD pipeline on AWS. So when I researched a bit, then I got to understand that there was AWS code build, there was AWS code pipeline, which helps you, you know, trigger actions, you know, decide a order of flow. So

 

Mm-hmm.

 

basically, you know, now what I had tried to set up was you just push your code to a particular branch on GitHub, let's say a dev branch, that automatically triggers your address code pipeline. The code pipeline is being triggered. Code pipeline initially pulls your changes from the dev branch. It installs all the necessary packages because it's possible that you might have included more dependencies in your fix. So it installs the dependencies, and then it attempts and it runs a build on its own system. So my system is free. I don't have to wait for anything. And it posts that I've got to invalidate the caches as well. So you write a small script for that, which helps you invalidate the caches as well. So in about 10 minutes, you're good to go and you just have to sit, you sip a coffee and then in 10 minutes you have the website as well.

 

I was just gonna

 

That's

 

say this

 

awesome.

 

is defeating the point. The idea is that you have 30 minutes, you can go off, you can play a couple of greater rifts in Diablo, you know, you can

 

Ha

 

do

 

ha.

 

you can make some traction, you know, in your game, you got time,

 

Go have

 

man,

 

a snack.

 

like, why you want to be

 

Yeah,

 

faster?

 

definitely.

 

So okay, I have you heard about per branch deploys?

 

Yeah, I've heard about branch deploys and I've used them on Netlify.

 

They're really

 

I've

 

fun.

 

used them

 

Yeah.

 

extensively. It's fun. It's very good.

 

Yeah, yeah, yeah. When you're thinking about like making those small changes, I mean, if you've got the thing where you're talking to your product manager, and you're like, hey, maybe we can make it look like this or something like that. And then you do a per branch deploy, and they can actually

 

Ahem.

 

see it in that branch and then go, yep, that's what we want and go. It's so much nicer than having like one, one branch that everybody fights over, like the dev branch,

 

Definitely.

 

you know, and then.

 

That's another pain. Don't even talk about that

 

Yeah.

 

because when there are multiple people working on the same code piece and then when

 

Ugh.

 

all of them have to deploy together, firstly there are

 

Right.

 

n number of configs that have to come. I mean they come and then you sit and resolve them and then you start deployment. So that's

 

The dead

 

another

 

branch

 

challenge.

 

is mine

 

Yeah,

 

for the next hour.

 

I'm gonna

 

definitely,

 

go.

 

definitely. I've felt that. I've seen that throughout.

 

Oh yeah!

 

Yeah.

 

So how is your experience with getting AWS code pipeline going? Because I'm assuming that there's pretty good documentation for it or good tutorials that other people have written to help you get started.

 

Yeah, I mean, AWS has great documentation and I have to say that. Uh, so I, yeah, I mean, I refer to a lot of, uh, AWS documentation and then I referred to a lot of tutorial videos as well, because it was not, uh, I couldn't find a one stop place for all my requirements. No, initially

 

Mm-hmm.

 

I first had to look up as to how to pull data from GitHub and then, you know, uh, for the latest changes. Then second piece was to make sure that you're creating a build environment there. And the third thing was to invalidate cache. So all of them were in three different stages. So I had to look into three different. things all together, then club them together and then put it in a single place. So that is exactly what I was thinking when I wrote the article because it was me who had to look into multiple places to get this particular flow ready in peace. But if I can put it down for someone else tomorrow, he is definitely going to thank me later for making his life easier.

 

Absolutely. I mean, future you will probably thank you later because

 

Yeah.

 

I can't tell you I've written so many articles that I end up referencing again.

 

Who wrote this article? Oh, it was me. All right, that's great.

 

Definitely.

 

Exactly.

 

Makes it easy to follow.

 

That's another feeling. That's a great feeling.

 

Yeah, because we always have we all have like a set kind of structure and flow and presentation. And it's because we're really just telling ourselves, you know, through an article and if hey, if other people tend to like like that style, and that's great, too. But, you know, it's good to see something you've written. And even if you don't want to publish stuff, just having like your own markdown files, or using something like obsidian or notion or something like that

 

Mm-hmm.

 

is just a really nice way to just kind of keep everything organized. You know,

 

Yeah, for sure.

 

it's a good

 

It

 

habit

 

helps

 

to get

 

you

 

into.

 

as well, you know, because when you're writing an

 

Yeah.

 

article, you are basically recollecting everything that you've done. And it makes your understanding even better.

 

Exactly. Yes. Right.

 

So Shirag, tell us a little bit more about what Javas.ai does, the company that you work for, because

 

Oh yeah.

 

I'm interested to hear.

 

Okay, so

 

AI.

 

AI is the trend today. Yeah, okay. So

 

Mm-hmm.

 

in Java, it's basically automates purchase orders, automates parsing, purchase order parsing. So let's say a company or let's say a distributor who wants to place an order, he sends over a purchase order that goes to a particular company. The company parses the, so what initially used to happen was the company used to sit and. the employees of those companies used to feed in every single detail on their own manually. So what Chavis enables is the automation basically. You just pass in or throw an email on them, throw a document on them and they have the ability to parse that document perfectly and feed it in all your systems, do all the necessary checks, take care of your stocks and then you know directly just send it off for you know dispatching basically.

 

That's

 

So

 

Nice.

 

awesome.

 

I mean,

 

So are you actually

 

yeah.

 

using artificial intelligence for it or machine learning at all?

 

Yeah, yeah, we use I mean my team uses but like I'm not directly involved in that But yeah, I mean we have a huge team for NLP AI ML Data, I mean big data as well

 

Yeah, I mean accuracy is a big one on

 

Yeah,

 

this one.

 

definitely. And

 

Yeah.

 

when you get that accuracy that you need, it's a great thing. You're solving or you're making 90% or 95% of the processing perfect, which is great.

 

So is it just a React Web API, Web UI then, or are using React in their places? Like where are you using React in this scenario?

 

Okay, yeah, so all these clients that use Javis, they have a portal to them. They have a company facing portal to them wherein they can update all their information, you know, let's say, I mean, every stock information, be it, you know, product information, all their distributor information and extra tracks, right? There are a lot of things that come in. So they have a portal to them. And from there, that interacts with our backend services, which any, and that's basically a side line thing, because when you're processing a purchase order, you need all this information to ensure that the data is being correctly processed or let's say if a particular item has a stock or not is only when you look into its database you look into its tables and you find out that this item has this one stock left. So that is when you put it from the front end So that's an entire chain, you know, that's not just one

 

Mm-hmm.

 

process that

 

Oh,

 

works

 

yeah.

 

completely fine. It's it's a chain So we have another,

 

of which portion.

 

we have an admin console as well. Sorry to interrupt. We have

 

No?

 

an admin

 

Oh no,

 

console

 

I was

 

as well,

 

just...

 

which is internal to Javis and all the Javis customers support, people use that for obviously helping out or assisting with the clients with any issues they come across.

 

So which portions particularly do you get to work on? Because it sounds like quite a large application overall.

 

So I've been working in Java for like two years now. And initially when I started, so I was the first person to start writing the entire code base. So in this sense, I've been lucky enough to start off with the code base that I wanted. And

 

Mm-hmm.

 

so continuously modifying it throughout the year. So I've more or less worked on the entire product, be it the company side or the admin side. I've worked on building different parts of it. Obviously it was not just me who was doing it. There were a couple of my colleagues as well. and they build different parts and I build different parts. So when you combine it becomes like a full fledged product.

 

Nice. And can you tell us a little bit about the structure of it is like, is it next JS? Is it VEAT? How do you build the application?

 

I mean it was a pure react, there's nothing else because two years down the line I was just another student graduating

 

Oh

 

from

 

yeah.

 

a college knowing my, you know, my the information that I had and from that you know you start with, I started off with react and then started to bring in changes, bring in things that I felt was pretty good enough and we as colleagues also when we discussed we felt that these were the necessary things to bring in that's when we framed it step by step and yeah over the two years I should say that we have come a long way when it comes to improvising the structure, making things faster, making them better, making them more readable because readability I feel is the most important thing.

 

Oh, no kidding. Yeah,

 

Mm-hmm.

 

absolutely.

 

You can compromise slightly on your performance but you cannot compromise on readability because readability is, I mean if no one else can read your code, there's no point in writing the code.

 

Yeah, it's key to

 

What

 

maintainability.

 

am I going to do with it? Definitely.

 

Yeah,

 

Yes.

 

if you can't read it, you can't maintain it. And

 

Yep,

 

just

 

for

 

pull

 

sure.

 

that thing out of there. I don't know. I

 

Yeah.

 

had no idea what this thing does. I'm just going to pull it out, put

 

The

 

it

 

best

 

in something

 

part

 

new.

 

is that you yourself won't have an idea to what you have written or your back. So

 

Yeah.

 

you yourself have to figure it out. Okay.

 

Yeah.

 

That's true. So did you add any component libraries or any particular styling or what did you decide to do for the CSS and things like that?

 

So, we used Ant Design.

 

It's a

 

I

 

good

 

should

 

one.

 

say that Ant Design is very good. I loved it. Thanks for watching.

 

Yeah.

 

I hope you enjoyed the video.

 

Okay, you're happy with it. All right.

 

I'm very happy with that because in the past where I was not... I started Andesign only when I switched... when I came to my company and that's when I realized the power of Andesign. It has so

 

Mm-hmm.

 

much, it has so much flexibility, it has so many components. You can do literally everything that you want, especially when it's a B2B product. You don't need a lot of UI components in place. You basically need the tables, you need the drop downs, you need the form elements and you need them to be perfect.

 

Yeah. Yeah.

 

Mm-hmm.

 

That's where Andesign comes in and it helped. improvise or make things so easy for us. But that was one thing that we had, I mean, the CSS. So another thing that we introduced was, so initially, if you see that you don't have different environments, you're just always working on a single environment. So you have a single environment file, let's say using that particular environment file, you're trying to

 

Mm-hmm.

 

run a production build or run or start a production server basis the endpoints that you put in. Let's say if I feed in my production,

 

Oh, yeah. Uh

 

let's

 

huh.

 

say if I feed in

 

Yeah.

 

my production back in URLs, I'm starting my production app and if I'm doing my dev once, then it's a dev app. So another thing that we

 

Mm-hmm.

 

pulled in was segregating the environment files. We now have an environment file for production builds, we have an environment file for development. So now what that helps

 

Thanks.

 

is I don't have to continuously sit and toggle my URLs in my environment files and look for the correct one that I have then sit and break my head as to okay this is not working and I have to change my URLs back and restart the server. So you know this was another pain point that we had which you know which helped us a lot you know by fixing them.

 

So do you do all that

 

Nice.

 

by environment variables? Do you have like, this is our, you know, you're in prod, you're in dev, that kind of thing.

 

Yeah, so now as of today, let's say if I want to start my dev server, I just do I, you know, in my script, I just have, I just have to write npm run prod colon a dev. So that automatically

 

Oh, right. Yeah.

 

picks up my

 

OK.

 

dev environment files with all the variables that I've declared and it runs my

 

Right,

 

dev.

 

I get it. OK, that makes sense. All right, very cool.

 

Very good.

 

Nice.

 

So did you also add in unit testing and end-to-end testing or any of those other automated tests to help give you more confidence that your code was continuing to run as expected?

 

on the front end know that that's not something that we have added yet. But again, you know, as I told, we have things down the pipeline and we want to add, but we can't do everything, you know, at a single instant. So this is something that we don't have on the front end right now because it is, it's not a lot logic driven. It has more on visibility on data collection. It's not heavily logic driven. So you know, by not having that in the start is not affecting us. It's not creating a lot of issues for us. So we do have it in our minds that we want to integrate, or we want to implement unit testing so that things become easier and we can manage errors in a better fashion then.

 

Mm-hmm.

 

Yeah, interesting. Okay. So in hindsight, what structural changes would you make now? If you had if you were going to start today? Would you? It sounds like you'd use and design for sure. Sounds like you use TypeScript. Are there any other changes you'd make?

 

I have

 

Sorry

 

to think

 

to put

 

about

 

start

 

you on

 

it.

 

the

 

with

 

I

 

spot.

 

mean,

 

TypeScript

 

yeah,

 

Nah,

 

perhaps.

 

that's okay, that's fine. Next.js

 

I knew

 

is

 

you,

 

an example or...

 

yeah, next year's an example. Next year's is there.

 

Okay.

 

That's in my pipeline. Next year's I have TypeScript and then I have unit testing in place. And I want to have a proper documentation as well. You know, using,

 

Ah, yeah.

 

I was exploring

 

Yeah.

 

DocuSaurus and

 

Okay. Oh, DocuSource is great! Yes.

 

That's

 

yeah,

 

a really good

 

that's

 

one.

 

great. That's

 

Yeah.

 

amazing. And that's so neat. I mean, I should again say that's very, very clean. The design's very neat. So yeah, we have to get in. Frontend documentation is not treated to be super important by everyone but you know when a new developer comes in and he sees as to you know what you know if he's just you know mind blown as to what is this code I just want to understand this, can you give me a documentation for that so

 

Yeah.

 

yeah that's going to help us out as well and apart from that we're also trying to competentize things so you know initially when we all started we had redundancy. We had a lot of core redundancies because poor people working on different, you know, parts of the code base altogether, you know, putting in whatever they need at that instant

 

Right,

 

because no

 

right.

 

one

 

Yeah.

 

can restrict you then. And now what you're trying to do is we're trying to centralize components. We're trying to, you know, make, reduce the redundancy by clubbing things which are similar and, you know, which I can, you know, just do by a component call. So

 

Mm-hmm.

 

one example is A very simple example is an Excel export that we had. So there was a code piece in our, you know, so we have tables in our code base, a lot of tables in fact. So all

 

Mm-hmm.

 

our tables almost require

 

I imagine.

 

an export. Yeah.

 

Yeah.

 

So all of them require an export, you know, because the clients need an Excel format for it. So they require an export. So we had implemented Excel export there. So now what happened was initially when multiple people were working on it, everyone had their own ways of exporting that particular table set. So everyone followed their own approaches. So I looked in, if I have to look into the code, you know, one year down the line, there was so much redundancy because, everything was just repeated. And there was no

 

Yeah.

 

use of having all of them together, you know, in different, different places when all meant the same. So what we did was we split that entire piece of code and we turned that into a component with obviously passing to it a lot of props that made it more customizable by adding colors to the headings, by customizing fonts, by customizing values inside it. We made a central component and now what we do is tomorrow if I need to make a new Excel export I just need to call that component with the props that it needs.

 

Yep.

 

So, you know

 

Beautiful.

 

that's made thinking minimal. I don't have to think what I'm writing. I just have to call the component, pass what it needs. And you know, it's clean. That's most important. The code's clean.

 

Mm-hmm.

 

Yeah, the trick is always finding the one components that are big enough to where people are like, I don't really want to write that to not so big that they require a million props and are blind and crazy. You know, you know,

 

Definitely.

 

difficult

 

and customizations.

 

to use. Yeah, yeah. So it's finding that sweet spot in there that really Yeah, it's not like a button. Like I just write a button. But then again, you've got the design. So you already have buttons and things like that. But

 

करेक्क।

 

yeah. Excel export is a fantastic example for that. Yeah.

 

Mm-hmm.

 

And most importantly, you need someone to take that initiative to convert that to a company. Because if no one takes initiative, then it's always going to be redundant throughout. So

 

Yeah,

 

taking the initiative

 

exactly.

 

and then reducing that and then making sure that the next time everyone uses your component is something I'd have looked forward to.

 

Mm-hmm.

 

Speaking

 

Good

 

of that,

 

advice.

 

do you do code reviews?

 

Yeah, I've been doing co-interviews for 5 years.

 

Okay, so if somebody makes their own Excel export, then you're like, hey, whoa, you need

 

Yeah,

 

to do that.

 

It already

 

I'm

 

exists.

 

very clear on that. You can't make things that are already made. I mean, you don't have to make things. Why waste time on that? In fact,

 

Yeah,

 

you can

 

yeah,

 

improvise

 

yeah, for

 

the

 

sure.

 

existing one. I'm completely fine with that and I love to do that. But don't rewrite things that are not written. That's very simple.

 

Well, that's

 

Yeah.

 

a trick is to find the things that you want to reuse. That's often

 

Mm-hmm.

 

the

 

Correct.

 

problem. And that's where a docuSaurus might come in handy.

 

Definitely. And as the code base becomes bigger, you don't tend to find out what you need. You just feel that who's going to look for an entire particular piece in the code base. Let's just make it on our

 

Right,

 

own.

 

right,

 

So

 

right.

 

that's where people get confused.

 

Mm-hmm.

 

And then the code base gets out of control.

 

Correct.

 

Yep.

 

Messier and Messier.

 

And sometimes it can be just one little conversation like, hey, as you're going as you are dealing with this bug, by the way, we already have an Excel export, just FYI,

 

Yeah,

 

look over here, you know, one little

 

yeah,

 

conversation

 

that that's

 

can keep over a ton of work.

 

definitely and that's another, you know, a good feeling because when you know that someone's finding a challenge and you know, is not able to or is looking for another approach to export in an Excel and then you already have that built, you just tell them

 

Right.

 

it's already done, you know,

 

Yeah,

 

fuse

 

you

 

that.

 

don't want to run into that circumstance of the guy being like, yeah, but my Excel export is better. And you're

 

Yeah,

 

like,

 

definitely.

 

oh, no, oh, man. No.

 

Not again.

 

UGH, right exactly. UGH. Hate that. Well, Shirog,

 

Cool.

 

this

 

Well,

 

has been a lot of fun, man. Oh, yeah. Oh,

 

yeah, I

 

hey,

 

was going

 

Jim,

 

to,

 

another question?

 

well, I was just going to ask, you know, you were talking about bringing in new developers to a code base. So, you know, good documentation, good structure that is easy to follow and replicate. What other pieces of advice would you have either for people who are coming to a new company and just kind of trying to get familiar with the code base or for people who are already working somewhere, helping people get ramped up, new people who join the team.

 

So I think the first and the foremost thing is to give some space and time to that person, to the new person who's coming in, because he needs to understand what you've written. He's not used to what you're writing. So he needs to understand, you know, let him take a couple of days or three depending on the code base and then let him understand how things are written, what structure the company follows. And because now he is expected to follow the same structure, you know, he can't bring in his own structure unless it's better than the existing one. So

 

Hmm.

 

that's the first and foremost thing. And, yep, after that, you know, it's all about communicating. You know, if I have, if I'm reading something, if I don't understand who's written it, I mean, if I don't understand what's written in it, you know, I go back to, you know, you go back to the developer who's written it, ask him, what is this? What does this mean? You know, can you tell me more about this? And that's how you learn more about the code base. And that's how you will be able to grasp things faster, because you might not know everything, you know, why is this code piece written is something that you don't know of. And only the person who's written it knows it. You have to go and you have to ask him. as to what this means and then that make you understand things better.

 

Yeah,

 

Yeah, another

 

good

 

thing

 

advice.

 

you can do if you know you're gonna be onboarding someone in the next couple weeks, or month or whatever, then as you're going through the bugs that you're trying to deal with, you can kind of take the ones that are pretty easy to do and kind of carve those off and be like, okay, that's for the new person. And then that

 

Mm-hmm.

 

करेक्ट।

 

gives them a way to kind of get into that. Yeah, that code base a lot easier. It's like, oh,

 

Yeah.

 

all

 

Yeah.

 

I need to do

 

Yeah.

 

is it changes

 

Okay.

 

piece of text. Okay, I gotta go and figure out like, where is that piece of text, you know, and if it

 

Yeah.

 

If you got localization, then they start learning about localization. Oh, I see. That's not, it's not hard coded in the, it's actually over this file, blah, blah, blah.

 

Mm-hmm.

 

And all that. Yeah.

 

Save some easy wins

 

You

 

for them.

 

have to start it simple, you know, you can't run into

 

Hmm.

 

complex things and by starting simple the person is going to be super comfortable and he's going to have a confidence booster in him. But you know if you just drop on the most difficult test of tasks on him, he's just like, I'm done with this, I can't be here anymore.

 

Right?

 

You know,

 

Exactly.

 

Right.

 

you don't want

 

What

 

I

 

that

 

don't

 

do you

 

to

 

belong.

 

mean

 

happen.

 

I had to Excel export? I don't know anything about

 

Yeah.

 

Excel export. And you're like, that's actually really easy. We've got this component over here.

 

Definitely,

 

Hehehehe

 

You're gonna

 

yeah.

 

love it. We're gonna make you feel like a superhero. All right. Sherag, are there any questions that I should have asked or we should have asked along the line here?

 

No, I think you've pretty much covered it all. Everything, more than what I had written in my article is something that I've spoken

 

Haha,

 

about here. So

 

that's

 

yeah.

 

our

 

I'm going to go ahead and close the video.

 

Yeah.

 

that's our thing we kind of get in there and take a look around.

 

Yeah.

 

Yeah.

 

Cool.

 

Yeah.

 

All right. Well, it sounds like it's time for picks then. So, Paige, when you start us out with your pick for this week.

 

Sure. So my pick is going to be a VS code extension that I was just made aware of this week. And it has no purpose except that it is adorable and it's called VS code pets.

 

Aww.

 

It is it's so cute. So it's just these little 16 bit animals that you can download and they'll hang out in the bottom of your VS code editor just on in one little corner. And you can I mean, people have contributed cats and dogs and.

 

Oh.

 

There's a crab that somebody made and a parrot and all kinds of just random little animated characters and they just hang out. They run around at the bottom of the screen. The cats climb up the side. You can play fetch with them. It's really cute. So

 

Oh, I'm

 

I just

 

in.

 

installed it. I love it cause I've just got a couple of little cats running around back and forth. Yeah, and then you can always close the window too if they're being too distracting for you. So yeah.

 

Yes, exactly.

 

It's fun

 

I'm

 

to

 

sorry.

 

look at them when you're writing code and that's just a

 

is.

 

mind.

 

Okay, so VS code pets. All right,

 

Mm-hmm.

 

sounds good. We'll put a link in the description. And for me, I found a thing called raycast is if you're on OS 10, or your Apple, basically, it is essentially I would say like a replacement for spotlight. So if you use command space a lot, you know, to bring up an application

 

Thank you.

 

or whatever. This is a much better replacement for it and is much faster. And it's got a whole store of extensions that you can bring in and some of them are very valuable, you know, like AI extensions and others are not so valuable, like a meme generator that generates memes on the fly for

 

Ha

 

you, which

 

ha

 

actually

 

ha!

 

I found really good. Because I use memes a lot. And yeah, that's it's just really great. And actually, you can extend raycast. And the way that you extend it is, ba dum dum dum, react. So, you know, it's good for us

 

course.

 

to react devs because it works like we do. So there you go.

 

Nice

 

Sharag,

 

comes full

 

what

 

circle.

 

do you, right? There you go. Sharag, what's your pick for the week?

 

So there was another package called commit lint. Commit lint

 

Hmm. Mm-hmm.

 

or commit lint, I'm not sure of the name. But that was super good because commit messages are another pain. Everyone writes

 

Ugh.

 

their own format, they just try it, they

 

Mm-hmm.

 

bug fix, issue solve. There's no sense to it. But just by introducing that, you are ensuring a structure has been followed when it comes to writing a commit message. So that definitely helps

 

life.

 

in a lot of... readability and I think that was a good pick for me.

 

Okay, yeah, absolutely.

 

suggestion.

 

Yeah, absolutely. A really good commit message can be fantastic. And it really is hard to like come up with them, especially when you're doing like your CICD debugging. It's always

 

Thanks.

 

yet another try at blah,

 

Right?

 

blah, blah, blah, blah. Yet another try to get the iron variable

 

Yeah.

 

set properly. Yet

 

Okay.

 

another this, yet another that, you know. And like you have like 20

 

Yeah,

 

different, yeah, pushes.

 

that's

 

Yeah,

 

right.

 

it's craziness. Alright, Sharag, this has been wonderful. Thank you so much for being on the show. Paige, good to see you again. And we'll see you all next week.

 

Thank you

 

Alright,

 

for

 

See

 

having

 

you then.

 

me.

 

see you

 

It

 

then.

 

was

 

Yeah,

 

great. See you.

 

alright. Bye.