Hello everybody, this is another episode of React Round Up. We have our
panelist today's Leslie con Wine He y'all, and Thomas Aila. Hello. And
our guest today is Monica Lent. How are you doing, Monica, I'm
doing great. Thanks so much for having me. That's great, so Mondica.
First of all, we would like to know a little bit about your
background. How come did you get involved with software engineering? Great question,
So to begin, I kind of started a bit of an untraditional way.
Let's say my dad was an electrical engineer, so I kind of always grew
up around computers. And thanks to looking at Internet archive recently, I found
my first ever domain name, which dates back to when I was nine years
old. Wow. Yeah, it's a work of art. You can tell
that I was taking word art and bringing it into Microsoft Paint and then turning
that into an image map. I'm so excited all of a sudden. Yeah,
it was honestly worse than I remembered it. So yeah, that's kind
of how I got started, like learning HTML and CSS, making my neopets
page amazing. Then eventually I went to university and I actually studied Latin and
Ancient Greek. But yeah, I graduated and didn't really have a plan for
how to use these things. Didn't want to become a grad student, And
yeah, keeping my developer job that I kind of started in university was well
a pretty convenient fallback. So that's how I inadvertently actually turned my childhood hobby
into the career that I have been doing now for more than ten years.
That's funny. So you start studying legacy languages, the oldest languages of them
all for the language. Oh my god, that's a yeah. I liked
in your talk that to say that your first job was the student web master
role exactly. You talked about like the has at the same time student and
master in the name, which is really cool. I love it. Yeah,
definitely. I was nineteen years old when I got that job. It
was pretty funny because they asked me, like how much experience I have.
I was like, well, I started PHP when I was like fourteen,
so I guess I have five years of experience senior. They didn't laugh at
me openly, I don't know, but I was completely serious when I told
them that that's amazing, that's really good, and today you're working at so
I actually just quit the job that I've had for the last five years.
So I was working at sum up, which is a fintech company based in
Britain. In So I was there for five years and I worked as the
lead front end engineer, and there I grew the team from being like basically
me to more than fifteen people located in this run end team worldwide. But
I left to build my own startup. So that's what I have been doing
for a grand total of a week and a half. Congratulations, Thank you
very much. Tell us more about it. Great question. So it's a
bit of a tricky one because I think sometimes when I talk to developers about
it, it's like it's a marketing tool. So marketing is kind of like
a little bit to a lot of developers when you talk about it, it's
not maybe as sexy as I don't know the latest library. But in essence,
it's an analytic tool design for bloggers. So you might know that some
bloggers write articles that are intended to convert people through links to third party e
commerce shops, for example, going to Amazon or booking dot com or something
like that, and then they earn a commission. This is called affiliate marketing.
So in essence, the application is an analytics tool specifically designed around that
use case. So typically bloggers are not like ultra technical, or they are
technical in a way that's very specific to blogging. They know a lot about
WordPress plugins, optimizing their theme, things like that, but it's not really
the same kind of stuff that you would know if you were I don't know
a product manager or a business analyst who uses all of the traditional tools.
Plus those tools are too expensive. So in essence, we kind of take
all of the kind of things you might do in Google analytics or hot jar
or optimize lead, these types of things, and then we bundle them together
in a use case strip and analytics tool around affiliate marketing. That's really cool.
I love the overall theme of taking all this insane power that we have
in technology and making it accessible and hyper focused at a specific kind of use
case and focusing on their particular needs and in a way that makes the most
sense to that specific audience. I love that kind of thing. Yeah.
Absolutely, It's really interesting because you have so much data. I recently calculated
it and we are collecting over two and a half million events every day just
from our beta testers. So this is a lot of data. But the
question that's really hard is how do you make this useful to people? So
it's a bit of a process of discovery for myself as well, because you
just have no idea what kind of interesting correlations are waiting in that data,
honestly, until you start coding some graphs and you start to see where it
takes you. Yeah, this is Yeah, it's really interesting because I think
that at least from the world maybe twenty or thirty years ago, we were
coming from from an age where we did not have enough data, right,
did not have enough information. So it's like the age of the amazing libraries,
or you would go into a library and it's like, oh my god,
now I have all this information. This is awesome. Today it's kind
of the opposite moment, where there's so much information out there and now we
need to like try to get the wisdom and the knowledge from the amount of
like try to understand what is noise and what is not right m h.
It's it's a crazy absolutely, and especially when the audience that's consuming this data
is not necessarily interested in spending all of their time digging through it, right,
They're busy people, business owners, Right, So you can't just leave
them to their own devices to hunt through things. You have to really like
surface that in an actionable way, and that is something I'm learning every day.
Nice. Okay, so I have one question for you related to to
your react fillin talk. First of all, let me say it's one of
the best thoughts tech talks I've seen, like at least in the past year.
It's really good. It's really good, Thank you very much. It's
really interesting, Like when you hear someone talking about like actually building software,
I mean talking about the problems that the way you were talking, I don't
know, it's really good. First of all, would before we go into
the tails of that talk, I would like to understand like from you now
that you're building something from scratch, you we're like the only dav for a
while. Maybe it's the only DV up until this day. Maybe someone is
helping you. I don't know, Like what's the difference when you were talking
about when you think about building software in a company that has fifteen hundred people
and a company that has one person. Does it changes the way you think
about things? Of course, I think not only the fact that the technology
is different, but of course also the fact that you have different needs and
level of stability as a business. Right, So of course, when you're
in an early stage business, you don't really know if the code you're writing
is going to be around in six months. You don't really know whether you're
going to end up becoming profitable, and of course that puts a different level
of consideration of where to invest your effort. Definitely. But of course,
on the other hand, what I find really interesting so far about building something
myself. I'm also working on this with my boyfriend who's my co founder,
who's also a software engineer. It's interesting because you know where you want to
invest in quality, and you know where you shouldn't be investing because that would
be a waste of time. For example, one thing that makes the analytics
application we're building unique is that it can scan an existing website to find affiliate
links using an algorithm, And by algorithm I mean a fancy function, right,
But this fancy function, you better believe it is the best tested piece
of code you can imagine. It has so many tests because if it doesn't
work, it means that people aren't actually finding the thing that they need to
track. And it can be really easy to say Okay, you know,
I just want to get this working fast, But when something gets more complicated,
you realize, really, what's the value in testing? And on the
other hand, the user interface has pretty few tests, I would say,
and I think that's okay, because honestly, we don't even know if the
UI is totally good, We're going to need to change it. So at
the end of the day, I think it's about finding that balance and understanding
really what context am I in in order to make those appropriate decisions that make
sense for the business and also for realistically how long is that software going to
need to be maintainable. It's like the challenge of finding a connection to the
ultimate value, like what is the point, what is the purpose? Why
why are we doing this? So often developers get so caught up on well,
this is the task right in front of me, and don't think about
the bigger picture, how it connects, how it fits in, how it
actually connects to some outcome in the real world that anybody cares about. So
kind of that valuing hierarchy gets lost, and that seems to be where a
lot of especially like junior devs, especially myself when I was a junior de
just like going all in on like I'm going to make this one random thing,
the investing all your time and effort without like getting permission to do that,
or getting like really defensive like I want to do this really really high
quality, or I spent three weeks on this thing and they were expecting you
to spend three hours on that thing. And then there's just like there's that
miscommunication that everybody just has different assumptions, assumes that everybody's on the same page,
and then there's just like emotions get in, Like how do you deal
with with those kind of unspoken assumptions that just kind of get lost in the
weeds. Distilling that down a little bit, right, I mean, Monica,
Like, now you're in this position where you sort of get to call
the shots. You're making this decision, so you sort of inherently know what
are the things that are worth spending the time on, what are things that
are probably going to get refactored, you know, going down that path,
So putting yourself back maybe in that first student webmaster job or any of the
jobs you've held in between, right, how do you sort of distill get
that information from the product owner or whoever is running the project to be able
to make some of those decisions as maybe just a developer on the team.
Yeah, that's isn't that the age old question? Where do I actually invest
my time? To be honest, I think this is something that it's a
so contextual and b it comes with just so much experience and also so much
failure, right that it takes the failure in doing it wrong, I think
in order to actually recognize all right, I've actually been through this before.
So at the end of the day, I think it just comes down to
being able to evaluate if I mess this up, how much is it really
going to hurt me? And there are a couple of places I think you
can really focus that. For example, if something is very business critical,
for example, is the business going to lose money if this stops working.
This is why it makes a lot of sense for us to be investing tests
in our onboarding flows right when people sign up, anytime they're putting in payment
information, all of those critical pieces that come together for their very first experience.
This warrants a whole lot of testing and to some degree a little bit
of paranoia, you know, like if it goes wrong, especially at certain
times of the year, I can say working at sum Up when it came
to the end of the year, right before Christmas. Of course, you
can imagine a lot of people are getting ready for an increased sale season,
right and you it just makes sense to be more cautious at that point in
time. I know there's like a lot of this talk about don't be afraid
to deploy on Fridays, you know, but really like the question is does
that make sense for you or not? You know, what kind of impact
is this going to have on your users if you have downtime on a Friday.
Otherwise it's just you know, it's inflated confidence and it's not putting your
users first. If you ask me, that's very interesting point. I may
sound like a broken record, but I say this on time. I think
that the single most thing that works is skin in the game. If it
hurts on you, and if you get the benefits, if it goes,
if it's done correctly, then most probably you're making like better decisions then.
And I think that this is a big challenge with larger companies is that the
people actually doing the work when the company is still large, they're very like
detached from the mission and probably at this point in your life. Now you
cannot even afford to be detached from the mission since now it's your like main
source of income or it is right, It's like, so when people say
that, don't deploy on Friday, I would say, like, I don't
know, Like what does does Monica say about like deploying day, because she's
the one who really get hurt if anything goes wrong. Sometimes we talk here
about should we let people deploy anytime? This is a good question, like
should should deploy be like anytime deploy? I think it should be any time
deploy if your team has an on call thing, and and if you deploy
something bad and goes home, you need topic of on call is so controversial.
Should engineers be on call? Should they not be on call? You
hear people who are saying, Okay, I did an on call job,
and now you know, I never want to do that again. I think
that's totally okay. You know, like if you don't want to be on
call, then you work somewhere that doesn't require people to be on call.
But at the same time, it's like, well, if you do want
to deploy any time of the day, then that's like a responsibility and I've
definitely seen situations where the engineers, you know, they want the keys to
the kingdom, but they don't necessarily want to be responsible for something going wrong.
Responsibility. I mean, it's like, okay, well maybe you can
blame this on QA or someone in operations, and that's kind of like,
I don't know, it's like the classic deflection. And you know, Frankly,
if I was in this position and I heard that kind of thing,
I would say, Okay, then we go back to a release schedule.
If you're not going to have enough empathy for the users to you know,
stop playing ping pong and come fix the problem, then yeah, maybe there
is that missing maturity. And I mean you just have to recognize that.
Yeah. I think it's partly just not being held accountable, and so much
of our industry and related industries, smart people or people who like to think
of themselves as smart, make things seem more complicated than they really are so
that they can get away with stuff and kind of hide their shenanigans under a
veneer of ah, it's too complicated, you couldn't understand it. I have
all these great reasons for why I get to do whatever I want narcissistic design.
I think the a there's a talk right about Oh yeah, this one
is one of my favorites. Yeah, it's the Closure Stewart something. Yes,
yes, it's great. Yeah, that talks about making yourself so essential
in the company you work in that they can never fire you. Yeah,
yes, this is really great. All right, So let's give one more
step back to the direct feel and talk. You talk about architecture, right,
software architecture, and when you start the more practical part of your talk,
you talk about essentially constraints. Right, So when when you write software
and and you want to to make sure that you have a good lifetime in
your software, it's not going to become a big ball of mud like that
anything is super costly. You need to create concerts. Could you go a
little bit further on that, explain a little bit that concept to us,
Yeah, for sure. So the idea is that instead of thinking about architecture
as something you know, super abstract that people who don't write code anymore are
responsible for and then the rest of us just live with their decisions, instead,
think about architecture as enabling constraints, so intentionally constraining the way that we're
working. I mean you can also think about it as best practices under another
name. But putting these constraints in place, and we basically trade in the
fact that we don't exercise all of our powers that we could have as developers,
and instead we pick ways to do less and also end up with code
that is safer to run, going to last a lot longer, going to
lead to fewer bugs, and so forth. So one like really common example
of enabling constraints is driving in a car. When you drive in a car,
the reason you feel safe to drive super fast down the street is probably
because there are some rules to the road, right, there are some lines,
I mean, maybe there's even a police officer that's going to pull you
over if you squit up, right, Maybe that's the ci So you know,
there are things that we use in the real world to constrain ourselves for
the sake of safety and speed, and software development is really no different than
that. And so it's yeah, that's really the main concept. How can
you give away some of the things that we used to do, you know,
whether this is just you know, making an enormous mess of the dependencies
in our code and instead putting structure in place and enforcing that structure. How
can you essentially do that in a way that's actually maintainable, especially on a
larger team, a team where not everybody sitting in the same room. Yeah,
it's such a powerful concept. I've been learning about this recently. It
kind of goes down to the kind of the psychological need for certainty. You
know, we if we don't have a certain level of certainty and stability,
then we have a constant feeling of anxiety. If we have certainty, if
we know what's going to happen, at least, you know, in certain
areas, we can feel comfortable and confident. And when you're feeling that level
of certainty, you can move really really quickly because you know that chaos isn't
coming at you certain ways. You know, if everybody drives on the right
side of the road, you can go a lot faster because you don't have
to worry about someone coming at you. And applying that to programming I've gotten
into. I was very much on the other side of that argument for most
of my career of just like valuing freedom to an extreme, and I would
kind of rationalize it of like, well, we want we can't imagine what
future possibilities we want to enable, so we don't want to paint ourselves into
a corner, which my favorite saying back then. But what I wasn't realizing
is that by adding all this flexibility, I was making it literally impossible to
test all of the different constraint by handling any kind of input, I was
making it impossible to have certainty that I'm using this thing correctly. So if
you accidentally use it wrong, you're not going to get any errors. You're
not going to get any warnings because the API that it was designing just like
assumed that you knew what you were doing and you always did everything perfectly,
Like no, if you constrain things and be like, immediately throw a warning
in somebody's face. Did you did something weird? Did you do that on
purpose? Or was that a mistake? Lets you move so much faster,
which is why I love you know. The mutuols guys kind of, I
guess folks were most of the people involved in creating like React at the beginning,
and the mutuals started off as being very anti error messages. It was
very it was very easy to shoot yourself on the foot and react. Thankfully,
it got a lot of wisdom from the Facebook people who had been around
the block a few times and were like, let's have very very strict warnings,
very very easy to know when you've made a mistake. And I love
how React does that at an API level, but I love how you're bringing
that and thinking about that at as at a much higher level, not just
at API level, but as like the architecture of an entire system, and
how an entire company of things can apply that concept to move faster overall.
One thing I find interesting is that I think a lot of developers early in
their career tend towards okay, we need to document everything. Like if we
don't have documentation for absolutely everything, every single product requirement or every single thing
in the system, I mean I definitely did that, then how can we
possibly know what's going on? And the interesting thing is like, when you
get bigger than that, you know you can. Of course, you can
hire technical writers, you can spend a lot of time doing documentation, and
documentation is important, but the amount of certainty that you get from automating as
much of that would be documentation as possible. It's so much more friendly,
you know, to onboard new people for example, and as you said,
to give them, you know, real time feedback. Right. So,
one example that I discuss in the talk is about forbid independency tests, and
this is something that can tell people you know, you're violating our architecture constraints,
and it can happen in like just a couple of minutes after they push
their code. This is like so much more resilient than relying that someone who's
super good at reading all of the like imports inside your pull request is totally
going to find that that one relative import, you know, is missing a
couple of dot dots to bring it to the right place. I don't know,
there's no reason not to put as much of your constraints into automation into
code as possible, because it takes that burden, you know, off of
people's shoulders. You'll also talk a little bit in the talk about favoring copying
and pasting over dependencies, which I think can be a little bit of a
I don't know, scary controversial statement. Can you tell us a little bit
more about that approach and why maybe that constraint is actually applause? Yeah,
this is definitely something where you have two camps of people like after I give
this talk, you have the cancer people who are like, thank you,
someone finally said it. And then you have the other camps of people who
are just like, I feel so dirty, you know, And it's like,
okay, well, you know. Software isn't there just to make you
feel good about yourself. It's to do things right. It's too value perform
some kind of a function hopefully make people's lives a little bit better, easier,
or something like that. So, in essence, the reason I talk
about potentially deciding to copy and paste code over introducing an implicit dependency is the
fact that sometimes when you create an abstraction and you bind together two pieces of
code through that abstraction, it often happens that this binding together ends up creating
code that is more brittle than it would have been otherwise. So, for
example, let's say you have two pages in your React app and they're both
using the same like super amazing date picker component, and this day picker component
is aware of tons of things happening inside of your app. But what happens
when on one page you want to introduce the hour picker and on the other
page you want to introduce I don't know, some kind of schedule picker,
I don't know. These things can start to diverge over time. And what's
interesting to me is that as soon as you put a component in the shared
folder, it will almost never ever leave. So people are afraid to remove
it, right because they're like, Okay, someone might depend on this,
and you know, I don't want to upset anybody, so they put it
there. And then over time this component starts to become very specialized. So
instead of working in all kinds of scenarios because it contains so much business logic,
it starts to work only in the those two specific places you're using it.
So you have these if statements, you know, like where in my
application you're passing in some kind of like your context. You know, if
I'm on the sign up I got to do that. If I'm on I
don't know the account screen, I need to do something different users, it's
like use the mess Yeah. Then you just keep adding them, right,
you just keep adding more if statements every time, because that's the model.
Friend is sign friend is time components, I call them. Yeah, And
what's funny is like, you know you'll make a change and depending on how
your app is set up, and how your team is set up, you
can make another team very unhappy with you very quickly, right, because I
mean so much of like software is it's you know, less about code and
more about people, and those kind of decisions tend to have effects on the
team. And you can really see how this puts stress on a lot of
teams, especially in front end applications that are oftentimes you know, semi monolithic.
Right. Yeah, I've been a big fan of the copy paste dependency
thing, but I've also seen it go south. For example, Like I
know you're not talking about like microdependencies like taking parts of loadash and embedding it
into your source code because of things like security updates and stuff like that,
but constraining that too app specific things. I think that makes a lot of
sense to think about going south. It's like problems are going to happen no
matter what, But where will it be easier to fix if something goes wrong?
Right? So this is one consideration, and that's one point to copy
and paste. I think I usually like to think about whenever I see shared
code, you need to ask the question like did business did my use is
asked for it to be shared right, is this only shared because it was
like similar code? Or does like did this need to be shared because of
the design? Right? If you're not talking to to a tech person,
So if this should not be shared because of the business needs or because of
our users' needs, I stop calling it shared code and I call it coupled
code. This is coupled Oh that's yeah, you know, like this is
this is this is a bad thing. Sis, it's a bad thing.
Even if they do the same thing today, most probably with time, they're
gonna they're gonna split, and it's going to generate a problem for us.
So there's nothing wrong with coupling code, just in the same way there's nothing
wrong with coupling humans. Like the humans have been coupling for a while.
You just have to know what you're getting into. Are you are you forming
a relationship that's permanent or are you just kind of pals hanging out out for
a couple of days. Are you tightly coupling something permanently, or are you
just kind of adjacent. You also don't want to think too far ahead,
right, You don't want to be marrying this person in your head when you're
just coupling up. You know for a while, right, so you also
have to sort of think about what are your needs in that moment and making
sure that you're not, you know, at checking prematurely or trying to share
code and when it's not really doesn't really make sense. Yeah, my favorite
software book is the from John Ulster House, The Philosophy of Software Design.
I also had sometimes in the picks here we're doing a book club here at
Compass now. He says that one of the biggest source of complexities in the
code base is dependencies. Dependencies in the most like simple way of thinking about
it, It's like, whenever I change a piece of my code, I
need to think about another piece of my code, consider it, or even
change it. Whenever this happens, we have a dependency between two places.
The more dependencies I have, the more complex the code is. And that's
it. Like in Generate's cognitive lobe, whenever I need to learn a lot
of things before change anything, or I have change amplification, which means like
to change one thing, I need to change in fourteen different places. Yes,
or even no one knows because we don't know all the dependencies. That's
why I love react hooks so much. And why I loved relay so much.
When you're the co locating all inter tightly coupled things. You know,
if you're married, you should probably live together. You know. If your
code is absolutely coupled together, it should probably be in the same file,
or be in the same bolder, be in the same rebo. It's funny,
but I love like the relay components that define here's the graph ql that
is needed for just this component, and that's it. Or and here is
the all of the code that goes together, and that's it. Nothing else
depends on this. It depends on all of it together or not at all.
It's not randomly strewn across the entire world just nightmares. Definitely. That's
also something I need to slightly change. The topic which I love about working
in pipescript. That's kind of connected to that. It's that and when you
have code that depends on other code, it is you know, something that
fails really really early and tells you, Okay, you didn't realize you were
using this somewhere else, and yeah, you don't even need to write to
the file in order to get that feedback. That you love me to change
that would have you know, broken somewhere in your application. And this has
been a huge lifesaver working on an analytics app that is like so ultra you
know, data heavy and being able to like share types between front end code
and back end code. I couldn't imagine doing it without it. Yeah,
just like that's such an undervalued concept of just having like I totally disrespected types
back in the day. I was, you know, I was kind of
from the Ruby camp, anti Java, no type. But just like the
power and the freedom and the speed you can get when basically an entire class
of future problems goes away instantly, when you know for sure high certainty.
Huh, as soon as you type a character that you just screwed something up,
got these two files married unbeknownst to you. Now they they're permanently attached,
Like okay, wait, back that up. They're just they like to
see other files they're not ready to, right. I mean, type systems
are also a great example of enabling constraints, right, because you don't just
get to reassign your variable to absolutely any other type it's gonna complain. I
mean, of course you have ways that you can suppress the type system,
but in general, you know, it's it's an awesome way to put limits
in your code that ultimately give you so much security and confidence going forward.
Yeah, but how do you deal with the situations where like this constraint usually
make us happy ninety five percent of the time. How do you deal with
those five percent of the time where typescript is just making your life miserable?
Is it something that with experience and just learn how to like, yep,
that's life or I mean, I definitely can't tell you that I am a
typescript expert, like I am learning typescript every day. I mean just yesterday
I was using reduce and I forgot to return and I spent so much time
wondering, why does it think that my thing is void? You know?
And sometimes it just takes a bit of rubber ducking to realize that you know
what's going on. So I'm not going to like, yeah, sit here
and pretend that I know. You know, I am like the source of
wisdom on typescript. But I think it has to depend a lot on what
is your situation. So here we knew like, Okay, I'm going to
be building an analytics application, I'm doing so much data crunching and if it
goes wrong. I mean, this is data that people are using to make
decisions that affect their income, so it's really important that this data is accurate.
But probably I don't know, maybe if I was building something that was
less like less impactful, or maybe you know, it was not so focused
around data, then I might not choose to use Typescript. Although these days,
I don't know. The autocompletion and everything is something that's I get confused
when I open a regular JavaScript file and like nothing happens when I you know,
I'm just like, oh, this is so irritating. I don't know.
Apart from configuring build tools, which is probably my least favorite thing about
software development, I think it's you're the only one everybody else loves it.
I hate that. It's like my number one hatred. Like Webpack. It's
like, because I went into management, I wasn't coding a lot, and
so Webpack released several new versions since I stopped being an individual contributor, and
I felt like every time I needed Webpack for whatever side project, I'm just
like, oh, my goodness, I need to go look up what it
What even is the latest Webpack version? And what what's different? And how
many you know, freaking files do I need to have my web pack?
Yeah, it's gotten so much simpler, still pretty powerful tools. It's complicated.
Yeah, building tools are one of those things that they almost need to
be a little bit complicated because of the domain. Domain is a little bit
complicated. And since you only touch like every two months, it seems that
you never learn, like I just you just do it enough to hate it.
Yeah, it's it's it's so crazy. Like if I if I did
maybe web pac configurations as a day job, like eight hours a day,
maybe I would maybe it would be like really good. But like we only
touch it like every I don't know every and never. Yeah, projects are
create react app. Yeah that's a that's a good one. So I have
an example here here Compassly we use a gRPC to communicate between the services,
right so, and we use it to use a push shrift before, so
all our products are typed in a push shrift. It's really interesting because you're
going to create a services, you create a push strift definition. It creates
everything for you, like clients, you just need to to fill in the
gaps of the service. It really makes things really well. It's super fast.
But the type system sometimes it's like, oh my god, like I
had a service, you know, when you turn adjacent and like watch your
return. You want to be the key, you know, you don't want
to make like an array. You want to be like each key is ID
and then I have an object. Those simple things that we do in JavaScript
all the time, you just can't do that with a thrift definition. And
that is the moment where I was like, Okay, so this is the
zen moment. The interface is not going to be exactly the way you want,
the way you think it's perfect. It's a little bit like move but
you're but you're like having a lot of benefits from because everybody is using it.
So that's what I think about typescript today. Like sometimes typescript is really
I think it you reach those edge cases that it makes things ten times more
complicated than before. But the fact that you're using everything and it's it's giving
like all those benefits, I think it's worth it. But sometimes, yeah,
it's one of these things where I think sometimes when it depends, sometimes
it's just a pain, right. But on the other hand, I think
sometimes when you have a constraint in place and people don't like it. It's
sometimes more of a matter of ego or control, you know, where you
just kind of want to have it the way you want it. I think
that's also what happened a lot with Prettier. Right there, are you know,
just a couple of people out there lurking that vote occasionally on these polls
in Twitter. You wonder who are they the ones that are like, I
don't want Prettier and I will never use it, you know, I just
hate it. And you're like, I don't know what happens to you,
like what went wrong? Most of the time, I think, you know,
it comes down to this is my abstraction. This is like my way
of formatting code. And I think you have to be careful that when you
design these constraints in your application that you do what you can to keep your
ego out of it. So using these kind of standards is super important because
you can also have people and I have seen this, who think, Okay,
I'm gonna build my framework on top of the framework. Everyone's gonna love
so productive. And the reality is developers hate other developers abstractions, right,
I mean, they're the worst. Your first use them, You're like this
sucks, and then you write your own so the next person has to use
it. Yeah, I think, I don't know, it's the endless cycle.
I think a lot a lot of these things are so useful though,
to expose kind of a lot of that drama that's kind of boiling under the
surface of like if you're searching for jobs and you find you're interviewing it a
place and somebody's really opinionated there about why they don't use ready or Okay,
guess I'm not working here. Yeah, definitely, these are some of those
questions, and so you can ask people. I don't know. I have
done like like literally hundreds of interviews by now, and sometimes it is really
amazing the things that people have such strong opinions on, where you're like,
I don't know, you expend a lot of emotional energy on something that is
probably inconsequential, and you just, you know, wonder how exhausting is it
to live like that? Attacking me from the from the late nineties or late
how old was I? I literally had a like a screaming match with somebody
about tabs versus spaces at one point, like I knew it was like Okay,
I need to dial it back like that was my lowest point has gone
full circle. Prettier Nobs now talking about the blog posts that you had that
was really hit. It was everywhere, shared everywhere about junior and senior developers.
Do you think this is a characteristic of junior professionals? Do you think
the senior professionals are better at that? Or do you think it's just like
across the board. I mean, I think it all comes down to how
you define junior and senior, because everybody has a different definition, right,
As I wrote in that post, like I received a senior job title when
I was I think I was twenty six, maybe I was twenty four.
I don't even remember. Of course, at that point, looking back on
it, I was a junior even though I had tech you know, three
and a half years of experience on paper, because that was still my mindset,
right, it was a very immature mindset from an engineering and team perspective.
So I think whether or not those kind of things are had, like
engineering, seniority is such a spectrum or like even a matrix. I would
say, you can be senior in some areas, a junior in others,
and sometimes I don't know, you also have junior developers who exert such wisdom
sometimes in a situation because they haven't, you know, been hardened by all
of those production horror stories yet, so they're not so worried about something that
ultimately is inconsequential. But I think it goes both ways. You can have
people who are militant, whether they are senior or about things that are relevant.
I think it's so much easier to end up in that spot where you
sort of have such strong opinions that you're not willing to budge when you're not
necessarily working on a big team. The first job that I was doing development
AD wasn't a developer job. I was actually working in a nonprofit and communications.
No one really knew anything about what I was building, but I was
tasked with sort of like creating these WordPress themes for these blogs. And it
was really easy to have really strong opinions about the way I was doing it
because I was the only one looking at the code right, and so I
could not only do it the way I wanted to do it, but I
you know, then found blog posts that supported my strong assertions about why I
was doing it that way. Right. Yeah, you kind of get in
yourn echo chamber of your own head. I don't know. I think,
especially early in your career, it's so helpful to get on a team and
have that code review, have that regular kind of cadence of having teammates looking
at your code. Right, because I did something about that helped you become
a little more pliable, I think, and accept other approaches. Yeah,
in lieu of that, like back in the mud Tools days, I was
definitely in an echo chamber and there was like it was, you know,
we were all young, we were hanging out on an irc. It was
very you know, tribal. We didn't realize that at the time, but
you know, Mud Tools versus jQuery tribalism. It was hilarious. But occasionally
there'd just be one person that would just kind of pierce the bubble that was
just kind of immune to the whole tribalism thing, and that would kind of
force us all to check ourselves. Like John David Dalton, the guy who
created low Dash. He really helped me to see how big of an echo
chamber I was in, because there was just like this this like holy war
that they sprung up from nothing. I don't even remember what the issue was
now. But I went and talked to him of like, let me just
talk to him and see what the deal is. It turns out he had
a legitimate point, like he'd made a comment on GitHub and it had been
deleted and like those all this hilarious teenage drama. I just talked to him
and he's just a cool guy. He was just like making a point,
like, no emotional identity related drama. He's just like purely technical. You
know, we did the thing and now we're pals, like we talk regularly,
you know, in lieu of working on a team, like some of
us don't have the luxury of working at big places with multiple teams. Like
the best advice that I have is just force yourself to confront and talk to
the people who have opposite opinions as you and see why they care about those
things. And maybe you won't change your mind, but at least you'll you'll
get to know those people on a human basis. Try to understand why things
are the way they are before trying to make a revolution. Right, Yes,
I think Jordan Yeah talks about that a lot. I like the I
like the you start your your react fiel and talk with that write Monica with
like why do we rewrite software? Mm hmmm. A lot of it is
that it's like I just joined and Okay, first of all, let's change
the framework. MM. Yeah, definitely. I I totally had this experience
where it wasn't me at the time because actually it was my Well I did
that too. So I have two experiences. The first one, I joined
the company and there were no tests, and I was like, but I
thought that you had to write tests. Like. I was very confused because
I came from academia and I had a lot of expectations about how it would
work to be at a startup and there were no tests and people were not
really open to tests, you know, and I was just like, like,
is this reality? I'm confused. Like So I had that situation as
well, where I was just like, okay, well then I'm going to
be the one that writes the tests, and I'm going to be test you
know, the test lady. And if someone submits something without tests, you
know. And then it became like a like a tiny war of like merging
things without pull request and I was like, no, you can't do it
without poor request. But no one had to listen to me, I was
just like this random girl who just joined and they're probably just like, who
do you think you are? And of course like arguing people with people who
are at least ten years older than me. I also didn't help. I
love it like tests, you know, because all my experience writing production code.
But I had also the other situation where we had like people joining the
company from an ACQUI hier and the first thing was like, why aren't you
using material UI? Why would you ever have your own design system? And
the amount of discussions was just incredible. But it was like, you know
what, like if you're not open to the fact that we just we just
don't use materially, why, Like I'm done explaining it. The fact is
we just don't use it, and you have to either live with that or
you have to not and then do something different, you know. And sometimes
that's just the reality because it's not feasible to change the things that are already
there, even if someone brings in it a good idea, you know what,
maybe it's not a priority, or you have to be open minded to
realize, you know, look that one experience that you had is not valid.
And now I'm building a project that's using material you I and I'm like,
Okay, it's useful, but I wouldn't have even wanted to use it
in that situation. So yeah, I think it's a little bit about getting
it looking at things from a higher level and picking your battles what really matters
in the long term and what doesn't. Ah, Yes, can I get
that on a shirt? Yeah, choosing choosing the battles is in and it's
the same thing. It's interesting because the first situation that you talked about is
like there's no tests or there's no reviews. Right, it's obviously a good
thing, like we all know we need to do some things that are good.
But the attitude that sometimes we have towards solving the problem does not solve
the problem. Sometimes makes a problem even worse. So this is probably like
a really good sign of senior Like when I see a dev that is like
choosing the bettle, so like I'm going to fix this one particular thing.
And the way they approach it is that like everybody is on board. You
know, you start you don't just start dropping tests everywhere. If you know
one test, you start like I don't know, talking about it. First
of all, you know and then like show one example and make and show
how how this would So this is this is interesting. Sometimes you may even
have the correct idea on your mind, but your approach to solving it is
making it worse. M One thing that's been interesting for me is doing this
but from the perspective of a manager, because on the one hand, you
don't want to tell people what to do right, No one likes to be
told what to do. If my boss were to just tell me what to
do all day, I would be irritated. On the other hand, do
you want like that the right decisions are being made and when something is really
important, you know, you might have to put your foot down, But
at the end of the day, people are going to want to implement things
when it's their own idea, and usually the ability of a lot of people
to come together, put their brains together about something is going to yield a
way better result than just leaving it to the senior engineer to solve all of
the problems. I think one thing that I have learned from leaders who are
like way more senior than me, Like we are not even on the same
scale, you know, is this mindset of coming in with loads of questions
and finding out how you can kind of coach people to asking those inconvenient quests
questions, you know, like, for example, if you wanted to do
a migration two typescript, how can you ask people what's going to go wrong?
And really you know, putting them in that position of thinking about the
impact. Is this going to take us three months or is it going to
take us twelve months? How much slower is this going to make our delivery
while everybody learns types for the first time as JavaScript developers. I think this
is like one of the key things that I'm still learning how to do on
a team, which is, you know, basically leading from behind. How
can you actually empower other people to make those decisions and come to conclusions with
the right questions. Yeah, that's huge, Like just you know, thinking
of that that again, So like the super seniors in your experience are coming
in with the questions that force other people to think. So instead of coming
in with the answer like Okay, I'm the senior, here here's the answer,
they're coming in with, Okay, here are the questions you guys,
all of us need to consider before we make a decision. That's very interesting.
Yeah, Yeah, that's also how you nurture those other people on your
team. Right, It's not only like a benefit for the team as a
whole and for the solution that you land on, but you're then essentially nurturing
these other folks to begin to learn how to ask those questions themselves. Right.
So it's like you give back in so many ways. And that's so
critical. Like as we're at this position in technology and that competition for engineering
people that know how to do this stuff is so fierce that it's absolutely critical
to know how to take people wherever they're at and bring them with you,
upgrade their skills, and then leverage them instead of just like you know,
just throwing a pile of you know, off the shelf people at a problem.
Yes, definitely. Yeah, it is interesting because I've been working on
this project and it's me and to very bright but junior devs. I love
them. Shout out to Vienna and Allen. The way we are we're we
were making the choices, the architectural coding, everything charges in this in this
project was that we would go to the whiteboard and put what the questions we're
trying to answer here, come up together with two or three solutions. Most
of the time the solutions came from my mind because of experience, but of
course we would and then pros and cons of each trade offs, and no,
there's no right answer, and then it's just like which trade offs are
we choosing here? And the interesting thing is that even though I probably had
an answer for most questions in my mind for all the ten times, at
least half of the times these situations brew new solutions from the interactions. And
it's funny because I think that the three of us, we grew a lot
in this in this last four months, in this project, both by this
exercise and the thing like I cannot I cannot say I'm more senior just by
saying just by saying, Okay, let's do this. This is not the
way it works. It's like I'm only more senior because I've seen more things
and I can map more solutions to things. But in the end, like
we're all like choosing the solutions together, we're all thinking through the solutions together.
And if a solution that I come up with is not better than a
solution that they come up with, that should not be the solution that we
should use. So this is interesting it's an interesting exercise. It's it's also
very humbly to put yourself in a situation where you can be wrong even though
you have the senior near your title and the other person does not. Like
if this bothers you, it's really complicated. But if it doesn't, you're
in the sweet spot of like learning. Me and my suit spot of life
is whenever I'm learning a lot and people around me are learning a lot too,
like we're all growing together. This is to me, like it's it's
everything. So yeah. The one thing that I've found kind of that that
ties all these things together, that really accelerates learning and growth, is to
focus on what makes you uncomfortable, Like there's a reason why it's uncomfortable.
It's like maybe I, you know, I'm tying my ego to this a
little bit too much, or maybe i feel like I'm not I'm inadequate here,
and I'm like, maybe I'm doing some kind of wacky psychology thing.
A question that I use to sort of gauge myself in those situations is how
much space am I taking up? That's a really interesting thing to ask yourself
when you're in any of these situations, no matter what whether you're junior or
senior, is like, am I taking up an appropriate amount of space in
this conversation, in this code, in whatever it needs to be right?
I found that really useful. Yeah, I need to check myself, like
how much have I been talking? And boy? Yeah, that's something that
can be really really challenging when you are in like formally a position of authority
and you have to be like so conscious about, for example, you know,
letting other people go first and asking people who haven't volunteered their opinion yet
to share and making it, you know, extra safe environment for them to
say what they think. Yeah, it's not even enough just to like be
quiet, but also to like draw other people in and you know that raises
their confidence, just like you guys were talking about nice. All right,
so I think we could go to picks. Now, what do you all
say? Yeah, let's do it. So, Thomas, do you want
to start? Yeah? So, going off of what Monica was talking about
just like drawing people out. This book that I've been reading lately is Get
the Truth, a former CIA officer teaches how to persuade anyone to tell them
the truth. It's such a such an interesting thing to think about how can
you get people to tell you the truth when they are incentivized against it,
and always getting to the truth whatever it is is usually for the best,
and getting past whatever issues are blocking us from dealing with confronting the truth and
moving past it. It's such a fascinating thing. It goes in with like
all the psychology stuff that I've been obsessed with lately and applying it to the
real world with fun stories and such nice good one Leslie. So mine's totally
off topic, but I was on a vacation this last week in Mexico City,
and I'm going to pick a specific area of Mexico City if you ever
get a chance to go. It's called Zochi Milco. Essentially. You know,
Mexico City was like built on top of ruins and it used to be
water, so there's still kind of a canal system in Mexico City certain areas
of the city, and Zochi Milko is this zone where you basically take like
Mexican gondolas out on canals and there are other boats around you with full kitchens
essentially, so a boat will come up next to yours. You can tie
the boats together and they'll like cook you mole and hand it to you while
you're literally on the boat, and mariachi bands will come up and play for
you on their boat. Anyways, it's incredible, highly recommend And then one
related pick, which is that I saw on Twitter the CSS Working Group put
out really well. I don't know if they put it out. I think
it's something they've been working on for a while, but it's essentially an incomplete
list of the mistakes made in the design of CSS, and it's a bulleted
list. It's a really fascinating look at some of these conversations we're having about
constraints and once you release something, you know how hard is it to change
those things? But I think it's really I'm not sure you'll have to check
out this list. It's pretty long, but anyway, I love the honesty
and transparency behind the decision to kind of put that out there. That's nice.
It's funny. The picks are getting very diversified. I think it's the
first time they have a geographical pick. This is really I thought i'd go
bold. All right, so I have two picks for today that are also
not tech related today. But first of all, is the love every company
So I have an eight month old daughter and they have a just love Every
company. They have a subscription thinking that every two months you get a box
with Montessory toys and other things that are that are good for that moment in
life of the baby. And it's the best and cutest toys ever. And
me and my daughter will have a lot of fun every day in the morning
play with the things that they do. And they have like also of books
with nice ideas on how to make sure that the kid is developing properly and
giving her challenges and stuff like that. So yeah, and my next pick,
so, whenever we talk about health and nutrition and everything, there's so
many things that are happening feds here and there. So if you are so,
I don't claim to know the truth, so it's not this pick is
not about the truth. But if you want to fest do intermittent fasts and
things like that, there's this app zero app it's called zero zero, just
zero the name of the app, and it's really cool and it's helping a
lot. So these are my two picks. What about you, Monica,
do you have any picks for today? Yes? I was thinking about and
so I'm going to also go traditional with a book. These days, I'm
you know, learning mostly about developer related things, but rather building a product,
talking to customers and so on. So my pick is a book called
The Mom Test. It's by Rob Fitzpatrick and the subtitle of the book is
how to talk to customers and learn if your product is a good idea when
everybody is lying to you, and so basically it talks about, all,
right, what if you were to do a customer interview with your mom.
Problem is, your mom loves you, so no matter what idea you're going
to tell her, she's going to say, that's amazing, honey. You
know. But this book is basically like customer development strategies that you can use
to do a productive customer interview, even with someone who is as close to
you as your mom. So it's really funny. I think it's definitely got
the most personality of the customer development books I've been reading recently. So if
you ever think about, you know, building your own product or just generally
trying to get feedback on something where you you know, don't want to get
lied to, even unintentionally by people who love you very much, then yeah,
check out The Mom Test that sounds awesome. That's so funny. It's
another look. It's two books about the same subject. If you think about
the mom Pass and the CIA's we are all people at the end of the
day, right, that's amazing. All right people, there was a great
episode. So this is it, see you next week. Bye bye,
thanks so much, Thank you very much, money, Kait. It was great.