S9E2 | Maintaining and Updating Legacy Angular | Katarzyna Płocka - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Hello, and welcome back to another episode of the Angular
Plus Show. My name is Laura Newsome. I will be
one of your hosts today. With me, I have q Q.

Speaker 3 (00:30):
How's it going, It's going good. How you doing the day?

Speaker 2 (00:33):
Nice? Nice? I made it through my tax meetings so
and I still have some money leftover.

Speaker 3 (00:40):
So I literally just finished my taxes before we started
this call.

Speaker 2 (00:45):
So yes, yes, yeah. So for people that don't live
in the United States, the United States likes to make
us jump through ten thousand hoops. They know how much
we owe, but they want us to tell them how
much we think we owe and then if we're wrong,
we get in trouble. So it's with me. I also
have Brian. Brian, how's it going, Brian.

Speaker 4 (01:06):
Love, I'm doing good. My taxes are not done. I
think I mess them up. And I filed an extension.

Speaker 2 (01:14):
Too, So like that adds a whole other level.

Speaker 5 (01:17):
Of we have an escorp and so it's uh, I'll
just leave it there.

Speaker 2 (01:25):
That are not American. Brian is playing a much more
complicated game than we are.

Speaker 4 (01:30):
I decided to be like you.

Speaker 5 (01:31):
Know when you start a video game and you're like
you can be like the easy, the medium, and the hard.

Speaker 4 (01:35):
I'm like, I'll take the hard. Yeah, for sure, an
expert level.

Speaker 3 (01:38):
I'm sure you Also you also sold stocks this year too?

Speaker 4 (01:42):
Uh maybe crypto No, I don't know. I did sell
some stocks.

Speaker 3 (01:46):
See they're even harder. Did you bomb plan? Since you're
talking about being a pilot.

Speaker 4 (01:51):
Don't get me started. I want to, but I need more.
I need more. They need to sell more stocks. All
the tariffs.

Speaker 2 (01:59):
Oh my.

Speaker 4 (02:00):
Anyways, we can keep moving on.

Speaker 2 (02:03):
Ahead, add on bundles. You can add on to your
tax complicated. Yes, right, So on the topic of complicated
with us today, we have a guest and we will
be talking about maintaining code that isn't up to date.
So I can guarantee there's at least a couple of

(02:24):
listeners out there going it's me, it's me. I'm doing that.
So with us today we have Kasha Polska. Welcome to
the show. Kasha.

Speaker 6 (02:33):
Hi, I'm from Poland. And in Poland we have really
easy way to do taxes. It's on the website and
basically we just clicked I accept, and I've already got
my refund from Texas because I clicked one bottom just like.

Speaker 4 (02:51):
To make complicated fun. That's so fun.

Speaker 2 (02:59):
But how does the government punish you for being wrong?

Speaker 6 (03:07):
You can still pay tax wrongly and at the end
you will see that you owe government some monies.

Speaker 2 (03:15):
But yeah, let's forget about taxes because nobody wants to
talk anymore, and instead we'll talk about maintaining code in Angular.
So I'm sure there are some people. I know there
are people out there who are sitting on older versions
of Angular, even within the last So I'm I'll be

(03:37):
teaching a workshop at Tecorama and Belgium and may about
updating Angular applications for performance. So shameless plug, you should
buy tickets and go to that conference. But when I
was doing research for this, I was trying to decide
what versions of Angular are people getting stuck at, because

(03:57):
I feel like there are certain versions where if you
go to the package downloads there there'll be like a
spike in downloads at certain places where people seem to
get stuck. And so we know it's a fairly common
problem for people to have older applications that are stuck,
and it's not like Angular hasn't gone through a few updates.

(04:18):
Just hear. So, Kasha, why don't you tell us a
little bit about your experience? I forgot to also have
you introduce You introduced yourself somewhat, but why don't you
you introduce yourself about your taxes. But let's go ahead
and hear a little bit about who you are in
the community and what you do.

Speaker 6 (04:36):
So okay, So basically right now, I'm sendior software engineer
at Motoral Solutions, and also I'm a part of Antika's team.
We organize workshops for women at entry level or Angular.

(04:57):
I bet you know Alisa Duncan for example, she's also
from there. I'm also trying to speak at conferences and meetups.
But but for the last few years, it was hard
for me, you know, to combine all the changes in
my life because I became a mother and it was

(05:19):
it was hard to combine. Uh. But also I'm really
passionate about the great communication in the team, uh, which
I think is also crucial when it comes to writing
maintain maintainable code because when you write good code, you

(05:42):
don't need to communicate as much. Also, and also it
is good to know how to communicate other people. The
struggles you can have when, for example, maintaining the old,
old code or legacy code. So that's me.

Speaker 2 (06:00):
One of my experiences with like when you come into
a new job and it's like older code that's evolved
for a few years, is that it is without fail
The worst patterns are the ones that got copied and
pasted everywhere. So yeah, so it can be really hard
to start to untangle some of those code bases. Do

(06:21):
you maintain a legacy Angular code at your job or.

Speaker 6 (06:26):
Yeah, Actually I haven't had a job without maintaining like
a coat, to be honest. That's why this topic is
really close to me because I was always working at
least two versions behind the latest version, and I had

(06:48):
I had experience with really really old legacy code. Even
with the code that was basically said that it is
Angular but it was valny large. Yes, there was. There
was only one observable for example, in the application that
was called that it is ungular application. So so yeah,

(07:12):
I had a really tough experience with upgrading and maintaining
Angular code.

Speaker 3 (07:19):
Right, you said that there was one observable in the
entire application.

Speaker 6 (07:23):
Yeah, And it was only because this observable was needed
to use their authentication, which was separate, separate library.

Speaker 4 (07:33):
That's intense.

Speaker 5 (07:34):
I've seen many many years ago when I was doing consulting,
I saw somebody use a single observable just like store,
and just like everything just got pulled off and they
just shoved everything to like the single behavior subject and
it was society.

Speaker 4 (07:48):
It's pretty big. I mean, I guess that's kind of
a JR. Global Store is underneath the hood.

Speaker 5 (07:54):
But obviously you get a lot of protection around it
and a lot of patterns around it and stuff.

Speaker 4 (07:58):
But yeah, you can do that. It can be done.

Speaker 3 (08:00):
But I guess it's like log in and then when
you log in, it just sends you done.

Speaker 4 (08:05):
Every next notification you're logged in, you're good. It done.

Speaker 2 (08:22):
So in your experience, do you what concepts do you
see that have been the hardest for people to understand
that make updating difficult.

Speaker 6 (08:35):
I think that the most problematic part is not understanding
the basics of Angular, for example, those observables, because if
you don't understand it, and for example, you start project
as a single person and you don't understand it, and
you understand for example, promises, then you are using it

(08:55):
and then the application is getting bigger, he has more
people in the team, and it occurs that you either
need to rewrite whole code or just go with the
patterns that are already implemented in the code. And I

(09:17):
think I have experience with working with just junior developers
in the project, and when we were working together, we
were trying to follow everything that was the best practices

(09:38):
written on the Angular web page. But when we got
a senior developer who had experienced in different technologies, he
was trying to force us to use some patterns that
he knows, for example React, and in this way, the
code he was writing was not readable for us. It

(10:00):
was working well, but it wasn't aligned with the best
practices for Angular. And I think that and I think
that when we needed to update, like it was three,
we needed to have grade from version six to version
eight at that time.

Speaker 2 (10:21):
Uh.

Speaker 6 (10:23):
For the code that we wrote accordingly to the best practices,
it was easy, but when it it it, when there
was a code that was written with different patterns, it
started to be really buggy code.

Speaker 2 (10:39):
Yeah. So I had a similar experience where we were
I was on a team, we were writing it was
technically a green field application, and I was doing my best.
I was not an experienced Angular developer at the time,
so I was doing the exact same thing, listening to
you know, different reading articles, listening to podcasts into this

(11:00):
podcast actually, you know, watching videos, reading the website, like
trying to do what was right for the code base.
And then other people joined our team afterwards, and they're like,
why are we using observables. Let's just I don't want
to bring in the complexity of observables. Let's just to
promise everything. I'm like, the complexity of observables is already here, Like,

(11:22):
we don't need to also add this other layer that. Yeah,
it was hard to explain to people who weren't used
to Angular why certain things were happening. Like I remember
getting pr comments with the ng container syntax where it's
like ng if else and then it's a template. Right,

(11:43):
it has to be an ERG template. But man, they
wanted it to be an energy container. They're like, why
can't it just be an energy container. I'm like, it
just doesn't work that way, you know, And and it
was very difficult to It's a hard battle to fight
when because people write code, how they know to write
code and yeah, I can see that being a struggle.

Speaker 6 (12:06):
Yeah.

Speaker 5 (12:06):
It's always interesting to me that, you know, you can
come into a code base and you know, you kind
of want to change patterns, and you end up you
end up kind of like at a fork in the road,
and it's like, well, we can we can move away
from every like we can move towards this new pattern
whatever it is, or we can like go back and

(12:29):
kind of rewrite the old stuff so everything's new, And
so you end up kind of like I think a
lot of people end up taking the first path and
they say, okay, well, you know we wrote these modules
or these features or these components kind of in this style.

Speaker 4 (12:44):
We'll just say style whatever.

Speaker 5 (12:46):
And then things come along and either angular changes or
external things change, or the team itself decides to make
some changes, and so you're like, okay, we're going to
start writing things this way, and then you end up
you now have like almost like a fork, right, And
then that happens if you have a long lived project,
that kind of happens again. And then now you have
like this tree like structure right where you have like

(13:09):
multiple forks off of the tree that are like, well
that we used to write it that way, and then
there's that other component that're like, well, we used to
write it before, we used to write it that way.
And so it always becomes like quite a challenge, right
in terms of, like, you know, how much technical debt
does a project want to take on? How much value
is there even going back and refactoring and all this

(13:30):
kind of stuff. And I'm not sure if there's like
an easy answer or perfect solution. I don't know what
your experience has been, Kasha with that kind of thing.
You know, do you go back and do you refactor
or do you just kind of chalk it up? Do
you put a comment at the top of the you know,
back in the day module and be like this.

Speaker 4 (13:48):
Was regular six.

Speaker 5 (13:49):
So we do it all this way and then inevitably,
and I'll stop here and I'd love to hear everybody's
thoughts on this, but inevitably, like something needs to be.

Speaker 4 (13:56):
Fixed in that old path and that old fork, if
you will. So then you go back and you open
the file, and now what do you do? Right, So,
let's say.

Speaker 5 (14:05):
You're a junior or a senior, or you're a senior
sell your principal architect and you're like, okay, well, so
this was written like four years ago, and there's no
component store, and there's this and this and that, and
they're doing this funky binding syntax or I don't know
why this is this way. We moved away from this,
so I just like patch it up and like keep

(14:25):
the technical debt or do we try to like lift.

Speaker 4 (14:29):
It up and bring it into like the modern like style.

Speaker 5 (14:34):
And I guess you know, it's funny because like it's
a technical question, I think to some extent for all
of us, but it's also like.

Speaker 4 (14:40):
Often not a technical question, right.

Speaker 5 (14:42):
It's often up to the organization to say, you know,
that's great, but I can't give you five story points
on that story because you just need to go in
and fix this bug. You know, I just need you
to get it done in like a half a day.
And so it's like the inevitable, Like it's like kick
the can or not kick the can, right, And so
I'm just curious, Kasha.

Speaker 4 (15:02):
What your experience has been with that.

Speaker 5 (15:04):
And then you know, Laura, I know you've had a
lot of experience I'm sure with stuff like that.

Speaker 4 (15:08):
I think we all have.

Speaker 5 (15:09):
And so I'm curious to kind of go around the table,
so to speak and be like, well, here's what I've
done or here's what I've hated, or yeah, I'm just
kind of curious, what do you guys think?

Speaker 6 (15:19):
Yeah, okay, So basically I was working with a few approaches.
One was that we plan our work to rewrite the
old components that use the old patterns, and it was
planned in the sprints, et cetera. I was working also

(15:39):
with the idea of writing the project from the beginning,
like writing a whole new projects that needs to do
the same thing. But the approach that I like the
most is to write new code, new feature in the

(16:01):
new patterns with the new for example, syntaxs if there
is a new syntax, and then when you touch some
old components you rewrite it to the new standard. So,
for example, we need to make change in some template,
we use the new new structure of the if statement

(16:25):
for example. And the and the rule that is crucial
for that is that when you are working on a
bag that is that is uh, that is customer reported,
then there is no fixes like, there is no maintenance

(16:47):
on the code. You are just fixing the bag. You
can use the old approach just to fix the back
customer reported, but it is a bag found by the team,
then you are making everything to keep the code up
to date. So sometimes the work is like easy fix

(17:09):
is just one liner and you can work whole week
on rewriting the component because of the rule that whenever
you toarch something, you fix it. And also if there
is a lot of a lot of that code and
legacy code. I try to suggest having the maintenance sprints,

(17:36):
so for example, every every four or fifth sprint should
be just for the maintenance of the code, just rewriting staff,
making sure that performance will get better, somethings, just just

(17:58):
to you know, just maintain the culte.

Speaker 2 (18:03):
I think that's a really good practice, and I think
it's important. You know, not every organization is going to
allow that, but if if teams, you know, the more
of us that are like no, this is actually a
very healthy part of the software development life cycle. It
helps keep it performance, it helps keep it helps us
to I mean, because I always do my best when

(18:24):
I make changes to delete dead code, to if I
remove something like fully remove it. But there it's hard
sometimes to actually and if especially if you're new on
a team, it's hard to know where everything might turn up.
Is it ready to delete. It's hard to tell, you know,
And so yeah, I think having those very explicit this

(18:46):
is our this is our sprint to clean house, like
it's our sprint cleaning sprint. I think that's a really
great idea.

Speaker 5 (18:54):
I think also my experience in that Laura just to
kind of tuck on slightly, and I'd love to hear
from UQ, is like, and I know we most of
us don't live in this land, but if you if
and when you do live in like really good unit
test land, those refactors and that like clean up maintenance
things goes so much faster because you can make you

(19:16):
can kind of come in broadly speaking, and make some
pretty big changes and whatever, start deleting stuff and start
moving things around and refactoring. Sure, you can always run
a build and like make your compiles or whatever, like
if you have a great unit test coverage, which again
I know that's probably more rare than it is the reality,
but when you do, like that's when that's been the

(19:38):
few times in my past when you're just like, okay,
all right, I'm good with all these unit tests that
I had to write.

Speaker 4 (19:45):
Now, you know, when you're writing them, you're like, why
am I.

Speaker 5 (19:47):
Doing this, this is ridiculous then, but it pays off sometimes.

Speaker 4 (19:52):
I'm not sure always, but it pays off.

Speaker 5 (19:54):
Sometimes, especially on those refactors, so that the long lived.

Speaker 2 (19:57):
Maintaining yeah ration test to like Cyprus and playwrights.

Speaker 4 (20:02):
Oh for sure.

Speaker 2 (20:02):
Like I've had plenty of refactors where I'm like, oh,
look my unit tests be passing and then totally somebody else.

Speaker 4 (20:12):
It's good to have that safety.

Speaker 5 (20:13):
It's like, it's nice when it's there, but it's such
a difficult I don't want to veer too much into
this land, but it's such a difficult thing to actually accomplish.

Speaker 4 (20:21):
For many reasons.

Speaker 2 (20:21):
If I find that if your codebase is in bad shape,
usually your unit tests are similarly in bad shape.

Speaker 4 (20:27):
White unit tests response you.

Speaker 2 (20:31):
Get the ones that want to commit. That's literally called
getting coverage, and there are no expects on the tests
like yeah, pile.

Speaker 4 (20:42):
Which you got c I'm curious what your experience has
done in this.

Speaker 3 (20:45):
In this thing, I mean, I think it's different company
to company. I don't want to say that our that
my current employer my team doesn't do good because I'm
currently on that team. But shout out to dbut Hunt
and the operation side. We we spent a lot of
time making sure that whoever was final reviewer, whoever was
doing pre reviews, we had like a developers ways of

(21:07):
working and what we've looked for in an MR. And
I know that Laura actually did a talk on that
like at NG comp like two years ago, like things
used to look for in a code review, and we
we took that the heart. I think we went back
that year after m G COMF was like, you need
to go watch Laura's talk at m G conf and
this is what we're gonna be looking for. One of

(21:28):
the things that we I mean this is this is
probably something that every company has done, is absolutely no
functions in the template, Like we don't want any functions.
I know that a lot of the NG there are
a lot of the Angular team has said no functions
in the tiplet's fine as long as they're not making
back it our payloft like huge a sequence calls that
slows down the templeate. But we had a rule where

(21:49):
if you if you had if you're calling or executing
any function the template, we're not approven it. And your
sixteen comes out and now everything's now everything is a signal.
So it's all functions.

Speaker 2 (22:00):
So it's different though because like functions in the template
is like it was never a simple It was never simple.
It would like it'd start that way and people are like, oh,
here's a function I can dump.

Speaker 3 (22:10):
A bunch of stuff into yep, yep, yep, yep, and
there's nothing wrong with that. But it was more so
if we're scanning, if we're scanning real quick and get
lab or get hub, it was, oh, there's a there's
an executing function in this template. I'm gonna call it
out right now. Now it's you have to actually go
in and look and go back in tractive signal, make
sure that's good on the computer. There's a lot of
little things and so and that document. I wasn't there

(22:34):
when the signals were fully integrated in the angular, but
I'm sure they went back and changed that as part
of their process. We were really big on, hey, make
everything a pipe. If you want to make any format
changes to the template, now you don't have to do that.
Now I can do it in compute it. So I know,
for a fact, I haven't talked to anybody over there
about this, but I know that they've gone through and

(22:56):
changed all that stuff because the architecture team on that project,
on that projects really on top of that stuff. On
this one, we're trying to get to market very quick,
so it's it's it's a lot more. We'll come back
and fix it later. That that's that's some tech debt.
We're not going to fix that yet. So I don't
know if it's necessarily good that we aren't maintaining these
things yet. I mean, I know for a fact that

(23:17):
it's not. But I mean those are things that we
do notice. But yeah, we're we're throwing those in tickets
sometimes and we will come back to it maybe.

Speaker 5 (23:28):
But yeah, yeah, if you don't, I mean, in like
startup world, if you don't get that next round of financing,
it all just goes in the trash anyways. And so
like you to just take out you just have to
take out those loans, You have to take out that
tech debt in order to get to wherever you're trying
to get to to hopefully close that next round or
whatever it is, that next financing, and so you just

(23:48):
you just push, push, push, and then you hire consultants
to come in.

Speaker 4 (23:52):
Yeah, I mean, it's.

Speaker 3 (23:56):
It's a never ending cycle. And so right now, we
at the beginning, we were doing some unit tests, like
what you guys said, like we I'm really big about testing,
but hey, when you're trying to get things out really quick, Hey,
you have a deadline of three weeks to get this
entire epic done. Okay, well we've got to get that
epic done with down any tests on the towel it works.
We did some quick manual testing on it. Well, when

(24:16):
the when the partners start using it and it's broken,
it's like a why aren't these things tested? We only
had three weeks to pick to an entire epic. Yeah,
it's it's there's a mixed bag.

Speaker 2 (24:27):
Yeah. Yeah, I think there's always there's pressure to go
fast and there's pressure to do it right, and the
two are hard to do together.

Speaker 3 (24:34):
So yeah, you get good fast tested picked two.

Speaker 2 (24:38):
Yeah. So Kasha, in your in your experience, let's say
somebody has a legacy Angular application that's pre control flow,
pre standalone components, you know, let's say version twelve, right
twelve earlier. What are some of the things that teams
can start to focus on to get themselves ready to update.

Speaker 6 (25:03):
Wow, that's a very interesting question.

Speaker 2 (25:07):
Because in labor problems right now.

Speaker 6 (25:13):
Yeah, So first of all, the team needs to know
what has changed from the version dire coding in to
the version they need to gratitude. So the update guide
from on the Angler website is really really helpful in that.

(25:34):
But they also need to understand what will be impacted
most and if they want to just update the code
that it will compile and work, or if they have
time and and enough people to update the code and

(25:54):
also update the let's say the destruction to use these
tand alone components, or just to leave it as it is,
to change the templates because the old templates will work
in the newest in the latest version of Angular. But
do we have time to do that or not? And

(26:17):
I think that when we have a lot of versions
to bypass, then we need to make sure as developers
that management will understand that there's a lot of changes
and it might require a lot of work. Sometimes going
just two versions up, which is like still not recommended,

(26:38):
but it is for me. It is most common pattern
that we keep things up like two versions maximum differences
to versions. So sometimes going two versions up is really painful,
like for example recently when we were upgrading from version
fifteen to version seventeen. It was smooth, took us like

(27:00):
two three days to update the whole code. But when
we were updating from version thirteen to version fifteen, it
took us a month to update the code. Because we
had a big application, We had a lot of changes.
Our unique tests stopped working and we weren't aware of that.
We weren't aware as developers of the changes. And management

(27:23):
was madadas because it took more time than expected. But
we as developers weren't us aware of the changes that
we need to make in the code. So I think
that for the good preparation is to note down the
major changes, the small changes, and the thing that you

(27:47):
want to achieve with this upgrade.

Speaker 2 (27:50):
Yeah, I think your advice of I mean, like, so
the one benefit we had, like if you're if you
are maintaining a legacy code based the one benefit you
have is you know what's coming future, Like you know
what it is and so you can kind of you know,
whereas if you're going just from version thirteen to fourteen,
you know, like you're sitting right at the cut like
us going to version twenty, like what's going to be
in twenty one? We don't know yet, So what's going

(28:12):
to serve us better in the future, Like, I'm not sure,
but when you're using legacy code, you kind of have
a time machine that you can see what's coming. And
those the Angular update guides are really good. You know,
you can choose the version you're on, the version you're
trying to get to. You click the advanced choice and
it they list a lot of things that might go

(28:33):
wrong for you. I've also found, you know, googling, bless
the people in the community that take the time to
write about the hurdles they faced when they were updating
from version twelve to version thirteen. You know, like those
kind of articles, even if you are currently writing, like

(28:53):
if you're currently trying to upgrade from version twelve to
version thirteen, just putting a blog post out there to say, hey,
we had trouble with this one third party dependency and
this is how we fixed it, like that can be
valuable to people. So I think that's really great advice
to know what you're kind of looking at so you
can plan that work a little bit. There aren't a

(29:15):
lot of breaking changes, but sometimes there are breaking changes
within the Angular framework where you know, like a function
like a directive will a decorator will need a new property,
or like input needs this now, or this is no longer,
this got deprecated, this is no longer accepted, and so
those changes can affect your code base, Solar.

Speaker 5 (29:38):
I think you hit on something though, Like in my experience,
like maintaining updating through versions oftentimes, like the angular side
of things tends not to be where the blockers are,
Like the most painful blockers tend to be in like
your dependencies, right, and so you've got like this sometimes
like cobbled together dependencies, and you know sometimes they don't

(30:00):
get updated or that you have to force it or
the peer dependencies are wrong. And so this one's a
certain version of typescript, this one's a certain version of angular,
this one's that, that one's that like, and you got
to kind of like spend all this time trying to
get them all these little pieces, kind of like doing
a puzzle like okay, well, okay, we'll update this one
to this lock it at this version, and we'll put

(30:21):
this one to this and okay, now that's good. And
so like those big updates tend to like that tends
to be where I get stuck up anyways, it's like.

Speaker 4 (30:29):
Ah, man, what the heck you know?

Speaker 5 (30:31):
Or you're waiting for I'll just pick on DX. You're
waiting for here roll out their next major Yeah, exactly.
Or it's some random form validation library is locked on
an old version and it's not maintained anymore, and so
then you got to force it and all these kinds
of things, and so, yeah, that tends to be where
I've gotten stuck in the past.

Speaker 4 (30:53):
I know that I don't know if there's a great
solution out there.

Speaker 5 (30:55):
There's probably other things, but like NX has been a
good solution for that for me in the past, like
my great I don't know if there's other good ways
to kind of go through those big changes.

Speaker 3 (31:05):
But regular update too.

Speaker 2 (31:08):
Yeah. Like one thing that's helpful is you know, and
it's like sort of hindsight, right, is be really careful
when you're pulling in a third party dependency follow the
you know, like is it being updated? Is it like
is it an act? Even then, you can still sometimes
pick some like oh I thought it was. It's like

(31:31):
the HS versus Beta max, right, Like I picked the
wrong one, man. Yeah, So it's like sometimes you just
do Yeah, I think yeah, and I think one of
the things that's easy to forget is the one of
the things like ver angular version updates are also including

(31:52):
node updates typescript updates, right, so even if you can
just jump versions, you get better improvements to uh no,
like the way that the browser actually like the JavaScript
engine in your browser, and you know, like there's you
get updates under the hood just by updating that are

(32:12):
meant to speed up your application as well, but then
those underlying dependencies can make it difficult to update. I
mean we always I think we I don't know that
we've ever not been able to use the legacy peered
ups flag. Yeah.

Speaker 4 (32:28):
So yeah, it's interesting.

Speaker 5 (32:31):
That's like a broader ecosystem challenge that's not like an
angular thing. Like I think you're going to face that
in any project.

Speaker 2 (32:37):
Where you and react yeah.

Speaker 5 (32:40):
Whatever or just vanilla j Yeah, you're just writing like whatever,
Like yeah, if you're going to bring in open source
libraries and you're going to bring you know, kind of
bring things together, and then then that's just part of
the You definitely get a benefit, right because you don't
have to write that form library or whatever it is.
But you uh yeah, it's just part of the part
of the I guess you make that deal when you

(33:01):
do that MPM install and so you know.

Speaker 4 (33:04):
I'm interesting, q Oh, I didn't mean to cut.

Speaker 2 (33:06):
Trast Well, it's typically less bad and angular because you
don't have to pull in quite as many. But there's
it's a pipe dream to think you're not going to
have to pull in Yah.

Speaker 5 (33:17):
I'm curious, like Kasha or Q, like, are there things
in your like do you have processes that you have
followed in terms of installing dependencies? Do you like only
certain people are allowed to install dependencies or there's an
approval process or or do you just let them like
and that's fine, there's no judgment, Like do you just
let people MPM install and go for it, you know,

(33:40):
and just like all right, so there's a new dependency,
all right, cool. I'm just kind of curious what you're
experiencing done in that that regard.

Speaker 6 (33:49):
Apparently, I'm working in the project that needs to be
really secure, so we try not to install anything that
is third party. We try to install only uh the
company libraries. We have sometimes separate separate teams to handle
the common common things like common come com on your companies,

(34:15):
common play video players, common things. I'm also developing the
one of the common libraries, and we try not to
install anything that is open source UH and just just
to you know, have everything as as motorial oriented as

(34:36):
it is possible. And sometimes we just follow the the
recommendations from Angular because and if we want to install
something that is not not already approved, we are asking
our security champions and if we can do it UH.

(34:59):
And I think it is really good practice because it
helps us to maintain the colde easily. UH. In the
in the past, I was working in the project where
we were using the every library we we were able
to use UH and it it was leading to some bugs.

(35:23):
I even my first talk ever at conference was about
the bag, about the bag that was caused because we've
used our library that had wrong implementation of of checking
the time left like did the interval and we had
to rewrite the library like we still use the library,

(35:48):
but rewrite some logic of it. Uh and and yeah,
we were using library that wasn't updated for quite a lot,
quite a long and then after after my talk, I
saw that the did the library has changed the mechanism
and used the workaround we've used seen our code so

(36:10):
that's good. Yeah. I don't know if anyone has seen it,
but it looked like it was fixed after my talk.

Speaker 4 (36:18):
So I'm curious. And it's a motorola, right that you
work for?

Speaker 6 (36:24):
Yeah? Right now?

Speaker 2 (36:24):
Yeah?

Speaker 5 (36:25):
Yeah, do you guys you said your security team and
stuff kind of gates that. Do you guys have your
own like like artifactory or like NPM repository in order
to like control that, so everything has to go through
Nexus or something like that, or do you still go
directly to NPM for your those artifacts we have.

Speaker 6 (36:49):
It depends on the on the projects because we have
also not only Angular but most we have like the
private private NPM. We have our some some asure h
some Asia resources that we store some stuff in there,
and we have we have everything kind of private private

(37:16):
how do you call it? Private instances of the most popular?

Speaker 5 (37:22):
So yeah, that makes sense, Yeah, that makes sense, kind
of approxiate or whatever. How about you Q, like what
do you guys do for like managing either currently or
like a JB hunt. What was the process there for
like managing dependencies and stuff? Was there a process or
there was it just kind of generally known be careful?

Speaker 3 (37:42):
Yeah, feature teams kind of had their own run of it.
There is an artifactory a JB hunt that that it's
still tied to MPM. I think it still pulls the
mp M stuff in prob. Yeah, you might. You might
get a buzz if something is like a security risk
or something like something that's not mean team. Yeah, but
that's it at the current spot. I mean, I believe

(38:04):
that we have free rein to.

Speaker 4 (38:07):
Do an installs.

Speaker 2 (38:09):
Yeah, I mean it, but fast.

Speaker 3 (38:13):
Yeah, we were pretty fast for the most part. So
anytime there's an update, we have an internal design system
so bit to make sure that we're on pace with them.
We can't go too far beyond that to break, so
whenever they're updated enough to speed, then we can. So
it's anything that's third party that's new, like hey, I
want to try out this new data Finis version, all right,

(38:36):
I guess we would say data this. But let's say
if there's a a date something else that's not data
fin s, then I think we would have to be
under under a microscope and be scrutinized, like why don't
you do your datas So yeah, I think I think
for the most part, though, we have free reign to
update as long as we steal within the confines of
our design systems update and you are looking for other

(38:58):
than nprs.

Speaker 5 (39:00):
You're just saying, Hey, I see a change to package Jason,
what's going.

Speaker 4 (39:03):
On in here? All right?

Speaker 2 (39:04):
Ye? Literally, anytime that changes, we're all like, but why, Yeah, like.

Speaker 4 (39:09):
Why did you do that? Yeah?

Speaker 5 (39:11):
It should probably be in the comment, like in your
commit or whatever, like you know what I mean, your PR.

Speaker 2 (39:17):
Like it usually gets discussed. We have a whole like
channel of technical leads that an architect like level engineers
where if we say we're going to bring something in,
we go through it and have a whole like process
for sort of you know, is this the best choice?
Are there other choices that?

Speaker 4 (39:38):
Yeah?

Speaker 2 (39:39):
What are the pros and cons? Like right now we're
talking versus ballabot so fun.

Speaker 4 (39:46):
I'd like to be the fly on the wall for
that conversation.

Speaker 2 (39:51):
It's so exciting, exciting validation.

Speaker 4 (39:56):
But yeah, sounds like that.

Speaker 3 (40:00):
We'll go ahead, go ahead.

Speaker 5 (40:01):
I was gonna tell a quick story. I did a
contract then many years ago for a company that fly
satellites around like an Earth synchronized orbit and feeds data
into Google Maps and stuff. And they had because of
the like the security constraints of it. I wasn't involved
in this, but I remember talking to developers and stuff

(40:22):
about this. But any dependency they use has to be
like dood approved. So somebody somewhere, well they're probably fired
now by must But anyway, someone used to go.

Speaker 4 (40:33):
Line by Laurel. Yeah, yeah, it's fine. Like somebody used
to literally like, let's say you wanted to use.

Speaker 5 (40:42):
Data FNS, right, you like you want to add to
your project, like some version somewhere somebody had literally like
honed through the code and like reddit and not just
like automated, but like a manual review process to make
sure that that code can be included in your code
because it's in this whatever lel a certain level of

(41:03):
security because you're flying satellites around the Earth, and which
I guess is a good thing, like as a person
who lives on planet Earth, satellites like you know, like
data NS is like somehow whatever hacked or or whatever
compromised and that can cause an issue somehow I don't know.

Speaker 4 (41:22):
But anyways, I thought that was really interesting, but it
was snow Like I asked them, I was like, how
long does it take? Like let's say you just want
to like, look, you already.

Speaker 5 (41:29):
Have like an existing but you want to upgrade it
like the next major. They were like three months four
months between like request and like approval. I was like, cool, cool, cool, cool,
Like all right.

Speaker 2 (41:42):
Some people release cadence is slower than that.

Speaker 5 (41:45):
That's okay, Yeah yeah, that's fair.

Speaker 4 (41:48):
Oh yeah yeah yeah. But anyways, I thought it was
a fun story, go ahead, So I was.

Speaker 2 (41:53):
Going to say, let's I wanted to bring it back
around and have ask Kasha a question. So, when you're
introducing your teams to some of the newer features and Angular,
what do you see your team struggling with the most?
What features do they think are sort of the best?

(42:14):
Like what do you have? Do your teams have opinions
that way about some of the newer Angular features?

Speaker 6 (42:23):
My current team doesn't have like many struggles I have.
I have a team member that started learning Angular very recently,
and he has still some you know, this power of
junior that he wants to know everything. He's senior developer

(42:45):
right now, but he still wants to learn stuff and
he really enjoys that. And I have a junior or
maybe even I can call him a meat developer who
is also really really into learning new stuff, using new stuff,
testing it, so we don't struggle a lot. We sometimes

(43:07):
struggle with implementing new stuff like you because you know
the rule touch something and then and then bring the
new stuff is working. But sometimes we have just the
months of fixing the customer bugs and during that time

(43:28):
we do not fix the code like like we don't
we do not maintain the code, so we have hard times.
But right now I have really really good team to
work with that is really open and we we tend
to understand things a lot, and we go to conferences

(43:50):
when where people explain stuff the new things that so
we already understand now we can talk with people there,
which I think is really really great that that we
have a support from the company that we are allowed
to go to such such events. But from in the past,

(44:16):
most of my most of my colleagues struggled with with
just the change. It wasn't the specific thing. It was
just that that the idea that we need to change something.
We need to change the approach, we need to learn
something new. For example, we need to start testing our code,

(44:39):
we need to start writing its tests, we need to
adjust the templates, we need to uh, we need to
have stand own components right now, we need to do
this and that. And I were like, no, I don't
want to learn a new thing. Yeah, because I'm in
this business for this, I'm an expert. I don't want

(45:01):
to learn a new thing. And I truly didn't understood that,
because you know, you're okay, you're a senior, but your
responsibility is to write good quality code, to learn constantly,
to develop yourself, to help other people learn new things.

(45:26):
You have some seniority in your experience, so you understand
you should understand new things quicker than the person who
is at entrance entry level. So it's your responsibility to
you know, to learn new things, to implement it, and
to just maintain the code. That is, to write the

(45:51):
code that is really easy to read, that when you
will leave the team, other people will still be able
to to use it, to write to fix the bugs
if some occurs, and just just the change itself. And
I think it's just the mentality of people, not the

(46:13):
changes in Angular itself, because to be honest, those changes
are very well, very well documented. Those changes are very
well explained. There are many tutorials on this topic. There
are many many posts on on that on on those upgrades.

Speaker 2 (46:34):
So like the CLI schematics and everything.

Speaker 6 (46:38):
So exactly exactly so so the the the the upgrades
itself aren't as painful as you know, adjusting your mindset
to having changes in your coding style, uh, in your

(46:59):
in your template, in your in your you know, just
the just the way you work and developed features.

Speaker 2 (47:07):
Yeah, and I can totally like I can understand that
mindset because software engineering can be extremely overwhelming. I I'll sit,
I'll relax and scroll through Blue Sky and I'm like,
oh my gosh, I don't know what that is. Oh no,
I need to read about that. Oh gosh, what is that?
Oh no? I got to read that too, And it
really like I have days where I'm just absolutely overwhelmed

(47:30):
by everything because there's just so much happening all the time.
And my advice to people when that happens, because it
happens personally to me, is to just focus on one thing.
If you're just focused on all, right, I'm gonna understand
why I might want to use standalone components. Like for me,

(47:52):
the standalone components change, I was like, why, Like, I
don't understand why we're doing this. It feels like a
pain in the butt. It doesn't seem to make a
big difference. But once I started to understand, oh, modules
make it so that if you accidentally import something into
a module that's not being used, it's still in the bundle,
I'm like, oh, okay. Like once I started to understand,
like there's a definite performance benefit to using a standalone

(48:15):
component because you're less likely to pull in code that
you don't need that can't be tree shaken out. Okay,
that makes sense. Or like the control flow, I mean, honestly,
once you take it when kesha, do your teams use
the schematics when you update the code, like the CLI.

Speaker 6 (48:32):
Commands yes we do, Yes, we do, yeah, so.

Speaker 2 (48:36):
Yeah, and they're they're great, right, And like once you
see you run a schematic on a super complicated template
that's like a thousand nested NG containers with if statements,
and it turns it into this like very readable, easy
to like reason about template. It's like, okay, okay, I understand,

(48:57):
I understand this now, like this is a superior style
to write this code. But I think it's sometimes people
there are people that they almost just need to see
it to believe it and to understand, you know that
there is benefit to it, but I get the impulse
to be intimidated by it. But at the same time,

(49:17):
I didn't get into software engineering because it's easy. I
got into it because it's a challenge, because I'm always
getting to learn something new, and you know, there are
definitely engineers out there who don't want that, and that's fine,
but you know, it's hard to be it's hard to
have the two types on the same team. I guess

(49:37):
the one.

Speaker 6 (49:40):
Experience definitely. And also when you are working in the
technology that is in changing as quickly as circular, then
it's easier. But a'mngure it's changing really quickly. New versions
comes really really fast.

Speaker 2 (49:57):
So when you are working, want to change your attitude?

Speaker 6 (50:02):
Yeah, exactly, exactly. And I understand the overwhelming as well,
But because I want to learn about a lot of
stuff that isn't that isn't actually really related to angular,
but I limit myself to the Angular stuff so not
to be overwhelmed. So when I when I check my

(50:26):
my list of the things I want to learn about
and I limit this list just to Angular stuff, I'm like, okay,
so that's not as overwhelming as I as It could
be I can learn on those different things the other day.
The day I don't have a capacity to even think

(50:46):
about it, so just did it.

Speaker 2 (50:48):
Yeah, And I think sometimes you know, working on an
Angular application, you will find opportunities to learn about you know,
scheme of validation for example, Like that's something that we
have to use. So okay, somebody go off to a spike.
Do you do your teams do like lunch and learns
or like sharing like learning opportunities within your organization.

Speaker 6 (51:15):
We we had some some knowledge knowledge sharing meetings. We've
tried to do it like internally we uh did the
company hosts the inside meetups where where people can share
their knowledge, their experience, their expertise. Uh and but but

(51:42):
internally it depends on the team. Sometimes some some teams
have like a monthly meeting where they uh they share
thy share what they've learned, let's new, what they want
to want to use. We have meetings called coffee talks

(52:04):
because we work remotely and we just gather together to
talk about stuff not work related. But sometimes it becomes
talk about the new technology, new conference. After saying, after
saying few words about conference, we check out the uh

(52:25):
the topics that could be covered there, then we can
discuss it. Sometimes we have regarding spikes for the new features.
Sometimes we try to decide if we want to use
some other technology that we already we are already using,
So then we delegate one person to you know, to

(52:48):
do the spike. Then we discussed together the pros and
cons and we we try to to do it this way.

Speaker 2 (52:58):
Yeah. Yeah, I think it makes a lot of sense.
I also it's a great opportunity. So if any of
any of our listeners are early in your career, it's
a really great opportunity to practice like first of all,
to have the opportunity to dig deeper into a topic,
and then it's also a great opportunity to practice speaking

(53:20):
like I know, I'm sure you have a similar situation
where you know, like you want to get into speaking more,
but how do you do that and a great way
to do that that's I'll stay safe. I guess it
depends on your company. Is through these internal copy chats
or lunch and learns or like learning sharing type meetings

(53:41):
where you can I mean honestly, whenever I do a
conference talk, I do quite a few, so I don't
do it every time. But if I have a new
talk that I'm a little anxious about. I'll present it
to my team first because I trust them. I know
they'll give me good feedback. I know they'll call me
out if I say something that's wrong, but they're gonna
do it in a way that doesn't make me feel

(54:02):
ashamed or embarrassed, you know. And it's a it's a
great opportunity, and if you've taken the time to build
trust among your teams, it can be a really great
place to develop talks to deepen your understanding. And for
junior and early career developers, it's a great way to

(54:22):
really expand your knowledge quickly without you know, because I
I don't I learned the best if I'm doing and
trying stuff out, Yeah.

Speaker 6 (54:34):
Yeah, I learned the best in the same way. I
also want to mention that the when you have a
junior developer in the team and you are, for example,
meet or senior developer, it is really good to explain
to them why you why you want them to change

(54:58):
something in their code. So when you are doing in
COLDE review, don't say just use this and that you
explain in this project, we are trying to use this
approach because it brings us this, this, and that. The
cons of the stuff that you've used is this, this
and that. In this way, people who are afraid to

(55:21):
ask can learn something, because junior developers should ask a
lot of questions, even if they sound silly, but they
are afraid to do it. And if you will provide
the explanation on a daily basis that I will learn
quicker and you will understand topic better. The moment I've

(55:44):
understood observables fully, like I was able to use it,
but to understand it was when I've tried to explain
it to someone else.

Speaker 2 (55:53):
Yes, yeah, and then you started to be like, oh gosh,
there's all wait, I don't know why it was that.
I'm going to go find out yeah, yeah, yeah. And
I would encourage for people early in your career get
on like review poll requests. You don't have to, you know, like,

(56:15):
even if you don't have right access and even if
you're not like on the list of people who can
actually approve it, go on and ask questions. And I
encourage senior and later career devs also to do the same.
I literally go into poll requests and I ask, hey,
why are we doing it this way? Just asking, you know, like,
this isn't like a this isn't me criticizing it. I

(56:37):
just don't understand what this is doing. So, you know,
and when you build that culture on your teams, it
really it allows junior devs to to grow faster because
they're less afraid to ask questions. I think one of
the best compliments I ever got as an engineer when
I first started on a team the very first retro,

(56:57):
one of my teammates called me a fearless questioner, and
I was like, oh, okay, yeah, I'll take that as like,
and it was meant as a compliments. Yeah, I like
give the Fearless question or award out right because and
as as as seniors and other developers on the team, like,
when you hear a question, even if it sounds silly,

(57:18):
treat it with like, treat it with dignity and seriousness,
because if you shut down a question, you're pretty much
shutting down all questions because people are going to be
intimidated by you and afraid to ask you questions. So
but yeah, I think those are all really great points.
So we're coming up on the hour here. I want

(57:40):
to be respectful of your time and everyone's time. Are
there any other thoughts that you have on maintaining code
that maybe we forgot to ask?

Speaker 6 (57:51):
And I have just one thing that when you are
working on the call that is the in the in
the version in the older version. I forgot the word older, sorry,
when when when you are working on the code that
is in the older version of any technology, you need

(58:14):
to remember to check the documentation accordingly to this version.
Because there are many many problems with developing staff or
developing new things or fixing new things because you are
you are looking at the documentation or stack overflow answers

(58:35):
that are related to different versions, and those won't work
in every version.

Speaker 2 (58:42):
So that is a great call out. And I am
guilty of that. Why is it this working? Literally? Yeah?

Speaker 6 (58:51):
Yeah, yeah, exactly.

Speaker 2 (58:56):
Yeah, so agreat. I love what you're saying. I you know, like,
know what you're updating to, what's in those versions, know
what patterns you're working with, you know, keep your teams educated.
Have that first for like first, to improve your code,
to write better, more performance, easier to read, easier to

(59:17):
maintain code. All great advice.

Speaker 6 (59:22):
So yeah, and actually I think that one of the
side effects of writing really clean and maintainable code. Is
that this code also performs better.

Speaker 2 (59:34):
Yes, it does, it does. It's also easier when you're
doing a PR review and you're looking at the code.
If it's if it's terse, if it's well written, if
it's you know, if it does what it says it's
supposed to do. It's so much easier. Otherwise you're like, wait,
why are you doing this one little weird thing in here,

(59:55):
Like what is this related to? I just I've been
working on we have an application generator and for the
last three months we've all just been adding to it,
and it's just one update Jason after another, and it's
a lot. It's like it was really hard to tell
what was going on. People would come in to change it,
they'd just PLoP it in somewhere. So I just refactored

(01:00:15):
it out into like this is add our design system,
this is add internationalization, so that it's a lot more
clear if you need to maintain it, like okay, I
see this is so this is not where I'm going
to update that because this is doing this instead, and
so it it really does help people understand how to
add to the code base as well. When you write

(01:00:37):
code that is clear, well, Lara's the worst thing. The
worst thing about maintaining legacy code is when you're like,
I need to refactor this. The first thing I always
ask myself is what is it doing?

Speaker 4 (01:00:54):
Yeah?

Speaker 2 (01:00:54):
And then you'll be like, wait, why is it doing that?
You know, like, yeah, what is it doing? And why
is it doing that? Or like two of the biggest
questions you have, and sometimes there is no rhyme or
reason for why it's doing something. Like I've been definitely
in legacy code basiness where I'm like, oh, I think
you're doing this because you introduced the bug at one
point that made you have to do this, and then

(01:01:15):
that bug isn't there anymore, but that code is still
there because you're not sure why it's there in the
first place. The case nobody touch.

Speaker 6 (01:01:24):
It, Yeah, I have. It reminded me of some practice
that we have because we have a lot of dependencies
on different applications in our ecosystem. So if we have
something in our code to that is written only to

(01:01:46):
handle the bag or the exception from the other application,
we are always commenting it with the to do and
with the expected version fix in the other Likebrary. If
we know it if not. We just simply to do

(01:02:06):
refractory or remove it when the newest version of vision
that will be available. And because we always add it
to do at the very beginning, it is easier to
find the things and at the refinements we can we
can bring up that. Listen, there's a new version of

(01:02:30):
this application of this library, we might try to check
if we can get rid of our workaround. So we
try to keep our hour to do with the let's
say third party COUTE like up to date, and we
try to review it every time.

Speaker 2 (01:02:53):
Y's one thing to slapped and it's another thing to
go back and actually to do it. So, yeah, at.

Speaker 6 (01:03:01):
Least you have but at least you have documented the
part of the code that is just you know, you
know that it is a workaround. This part is a workaround,
so it is easier to you know, to understand it
because sometimes you have plenty of workarounds and you are

(01:03:22):
asking you why and you why yeah, because there is
there is no logical reason to do that. But it
occurs that in third party or there is a bug.

Speaker 2 (01:03:34):
Yeah, and somebody might be saying, well, but can't you
just check your commit history? Wouldn't the pull requests say
it and I'm like, oh, but you know, well that
happens when you migrate to a different code repository or
a bucket to GitHub, and like, yeah, we lost a
lot of history when we moved our repository on the app.

(01:03:54):
I was maintaining just the way it got moved. We
didn't have any commit history. Know. It was like yeah,
like literally one person had the entire like one person
committed the first commit to the entire republitory. So dud wow,
I know right, because literally that would happen. What does

(01:04:16):
this do? And they're like, I don't know, I just
moved the code, leave me alone. And that's why you
use get move right, because if you just like move
it yourself. I've been there too. Anyways, all right, I
think this is the topic we could probably talk about
for hours, because like the more you talk about it,

(01:04:38):
the more you like you pull off the old like
old bandages and you're like, oh, yeah, I remember this
one time, this horrible thing happened. We all come out
with this kind of like dead eyes, messy hair. So Kasha,
do you okay? One last thing I want to ask

(01:05:01):
when your company sent you to conferences, which which conferences
do you like going to?

Speaker 6 (01:05:09):
I really like going to Angie Poland. Angie Poland, that's
basically my favorite conference. And last year I was at
Angi comf and thanks to Motorola, and it was amazing experience.
The Angi cons is totally different than any European conference

(01:05:32):
I've been to. I had also an opportunity to have
the hostile workshops there as workshops, which was also amazing.
But at at Anchi Poland, I think that because it
is inside the cinema, so you know that you're in

(01:05:55):
the biggest cinema cinema room in Poland, I guess right now.
And seeing all all of those people sitting there, there
are many people, people are really open to talk doing
the breaks, and I think the atmosphere is just amazing there,

(01:06:18):
so nice nice.

Speaker 2 (01:06:20):
Yeah, I've I've heard great things about Anjie Poland. I
have not been able to go myself, but it's definitely
one that's on the list. And for our listeners, stay
tuned to the NGI comp uh, follow AGI comp on
social media, sign up for the NNGI comp newsletter because
ng COMP will be announcing the dates for the conference

(01:06:41):
probably after this episode has aired. But we will have
ANNGI comp again this year, so that's exciting.

Speaker 3 (01:06:48):
Hopefully it's in Northwest Arkansas.

Speaker 2 (01:06:51):
Hopefully House Q is having Angie comp in his basement.

Speaker 3 (01:07:04):
We're having a Walmart home office.

Speaker 2 (01:07:08):
Kasha. If if people would like to reach out to
you or to learn more about Angie Girls, what's the
best place to do that?

Speaker 6 (01:07:17):
Okay, So at Antie Girls. If you know do want
to know more about antie girls, you can you can follow.
You can enter our webpage girls dot org. You can
also find us on LinkedIn and Twitter as Angular Girls. Also,
if you like to find me, you can find me

(01:07:39):
on LinkedIn with my name and surname. There's on LinkedIn.
I have two names. It's Vodka. You can also find
me on x it is it is hard to pronounce
it so so people that are English girls understand it

(01:08:01):
because it's my my nickname. It's Pelaga one to three two.
I can share links with the Yeah, yeah, I can
share links with you. Basically you can. You can search
with via my name and surname. So Vodka and I

(01:08:23):
should put up put up there.

Speaker 2 (01:08:26):
Uh.

Speaker 6 (01:08:27):
If it comes to girls, you can also contact or Robert. Everyone.
Everyone is listed on our web page.

Speaker 2 (01:08:37):
Nice nice, all right, and I have found you here
on linked then and so I will get this put
in the show. Excellent. Well, thank you so much for
taking the time to join us today. We appreciate your
contributions to the community and I love sharing battle stories

(01:08:59):
with people about like see Angular code. So I'm not
gonna lie like one of my favorite hobbies is deleting code.
So you and me both so so yeah. Thank you
once again for joining us to the listener. If you
have not subscribed to the podcast, be sure to do that.

(01:09:22):
That helps us keep making this content for you, and
thank you for joining us and have a great day.

Speaker 7 (01:09:30):
Hey, this is Pressom. I'm one of the ng Champions writers.
In our daily battle to crush out code, we run
into problems and sometimes those problems aren't easily solved. Ng
comf broadcasts articles and tutorials from enngie champions like myself
that help make other developers lives just a little bit easier.
To access these articles, visit Medium, dot com, Forward Slash, ngcom.

Speaker 1 (01:09:51):
Thank you for listening to the Angular Plus Show, a
chicoff podcast. We'd like to thank our sponsors, the NGCOFF organizers,
Joe Eames and Aaron Fraut, our producer Genebourne, and our
podcast editor and engineer Patrick Hayes. You can find him
at spoonful ofmedia dot com

All Episodes

S9E2 | Maintaining and Updating Legacy Angular | Katarzyna Płocka

Episode Transcript

Popular Podcasts

New Heights with Jason & Travis Kelce

The Breakfast Club

Fudd Around And Find Out

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S9E2 | Maintaining and Updating Legacy Angular | Katarzyna Płocka