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.