We kick off with a preview of what to expect in season two of Word Wrap. Then, discuss how we've approached exploring a new code base, important considerations, and tips for tools and techniques.
Support Word Wrap
Interested in sponsoring the show? Get in touch on our sponsorship form.
You can also become a patron with a small monthly contribution which will help us pay for necessary services to keep a podcast running. Thanks for your support!Support Word Wrap on Patreon
Welcome back to Word Wrap with Claire
and Steph! You can find the transcript for today's show on wordwrap.dev.
Hi there, and welcome to season two we're dubbing this of Word Wrap. Today. we're going to talk about coming into a new code base, but we also wanted to give you an idea of kind of what we're going to talk about in this quote, unquote season.
Such as like does valid and semantic HTML even matter, making the web fun again, electron apps, um, maybe some design systems talks. How do you actually leave good feedback on a PR? How does one go about live stream coding themselves? A reminder in a in-depth discussion about how the web is still very young and how the young web is still very young.
And then also like online community building. And, uh, we might just do a cheesy one as well. Uh, just talking about motivational affirmations, which is, you know, I think everyone kind of needs that, especially in these times. We're hoping to pepper in some guests throughout the whole season, too. So if you want to be a guest, um, hit us up on the different channels that show up on our website and let us know.
So coming into a new code base, let's talk about that. So I recently joined Microsoft. That's a new development between the last episode and this episode. Um, and I actually work alongside Steph now, which is kind of cool. She's really great to work with. And, uh, I'm going to make her blush. I can see her blush right now.
And, uh, yeah, it's been, it's been fun, uh, so far. But the complexities of working in a new code base are there no matter where you're coming from. And the code base that I came into is actually very mature, I guess if you, you should say. Um, it's been around since 2008 ish and you know, that, that shows, I mean, the web has changed a lot since 2008.
Um, even since 2015, where, where a lot of the code that I have actually touched, um, has been created. And there are some complexities in both changing that and also just figuring out what it does. I've been in this job for months. And I still feel like I have no idea what I'm doing, which is interesting coming from me since I've been in the industry for like six or seven years now. And I've worked with all the tools that I'm currently using to make things on this website. But you know, you also have to factor in other folks' opinions, um, how they might've learned things and how that came to be with the different asks and stuff like that, that they had at the time.
And so I have actually had a big crash course in exactly how jQuery actually works, which I. I thought of myself as a jQuery expert, or at least I knew what was doing, but I didn't really get to know what it was doing for me for free while I was using jQuery. You know, coming from a job where I was using a lot of modern web APIs.
I wasn't really using a lot of libraries and coming back to, you know, more of a jQuery, uh, focused scripting environment. And, and literally my first priority was let's rip out jQuery as much as possible, mostly just because like, it kind of goes against, you know, the, the tree shakeable web that we have now, or that we try to have.
And I, that didn't go so well. Like it went decently well. I did, I didn't make production break except for once I believe. And. You know, it it's, um, it's a, it's a learning process. We're all learning. Even if you know, you're seven years into this. So I kind of wanted to talk a little bit about like my struggles going into the new code base, kind of figuring out what's what, and who's who, and who knows what, and then maybe Steph can pepper in some opinions as well.
Uh, going into that. So let's first talk about differing opinions.
So. Whenever you write code you're kind of injecting your own way of thinking into the code that you're writing.
Whether it be naming variables, which is something everyone struggles with, or, you know, even just the way that you build functions, um, like how big the functions are, how small the functions are, um, or maybe where you put them in files or how you separate up the files.
Um, and it's all different. And personally, I have a really hard time with understanding other folks' mentalities when I just look at the code. And like, it's like, what in the world is going on here? Which I think is the very colloquial. You know, a new developer comes into a project and someone's like, oh my gosh, this is trash, we have to rewrite it. Like that, that kind of happens all the time. And I'm not, I'm trying not to do that because that's not what this is. That's not what the code base is. That's not what any legacy code base is, or even just any code base that I come into. It's new for me. That's not what that is. And personally, I'm trying to break that, that mentality.
Because in general, like the website that I'm currently working on has thousands, tens of thousands of pages, which is giant. And so like any change that I make has a much more resounding impact. And so, you know, taking that into account and, um, being like. If it's all working well right now, then something's gotta be going right. And so using that, like as a guide to figure out kind of what you want to change and why you want to change it. I'm a person that likes to run fast. I guess, if that makes sense. And like, I don't really understand where I'm going sometimes in the thrill of figuring out where I'm going. And I really had to slow down and like, really think about the reasons why I'd want to do something, um, in this job, which has been great. Um, that's, it's just a mature kind of way of going about, you know, coding and making a product. So.
I think what you touched on there was something we talked about a lot, a few different ways first season was just kind of extending empathy. And I think that's kind of what it boils down to is like when you come in, like you're, you're personally feeling overwhelmed to an extent, even if it's technology you're familiar with, because of exactly what you were talking about. Like other people have already made so many decisions on how it all comes together. And then for each of us, um, on what we're working on, like the underlying technology was new or mostly new to both of us. We'd both worked on server-side languages, but it was PHP, not C-sharp in the templating language Razor.
So that's what our ah literal switch was. And so, uh, you know, languages share a lot of commonalities, but at the same time that doesn't, as you all know, dictate, you know, precisely here's how to then create the code. We, again, as Claire mentioned, you still insert your opinion. And so being cognizant of those, um, not just opinions, but you know, there's other layers there. Um, worrying about at times security features of how those different elements come together, worrying about how that interfaces across the system.
So talking to backends, talking to APIs, um, all these certain things.
Understanding that over the lifetime of the site there's been literally hundreds of stakeholders come and go, you know, that have, uh, obviously influenced the decisions that were made.
And so all that comes together and, and definitely makes things feel more overwhelming. But I think as Claire noted, being able to take a minute, recognize that all those things have already happened, um, to help you understand and approach. What your actual task is at a given time. And if it does kind of spider out, um, we are fortunate to be on a team where like, we can have the discussion of maybe this could be improved. Can we do this? Or can we at least backlog it and give it a second look. So that's like a route when you do feel overwhelmed or you do feel that it's incorrect is hopefully your team is, uh, you know, you're in a supportive place where you can, you can do that. You can say, you know, is there an opportunity here?
And sometimes as we found, like, I guess I'm kind of tipping us into like, well, how do you go about making change in the code base then? You know, as we found, like, sometimes you can identify like, you know, thinking about that impact, not just, okay, we've talked about being cognizant of why that decision was made, but what's the impact of making an improvement and, you know, is that helping the user?
Is it accessibility related? Is it performance related or is it simply, you know, it would be a lot easier to maintain and it would be more comfortable for our development team if we could do X, Y, Z, these improvements.
And it's been awesome to be able to be in an environment that respects those perspectives and allows us to try to make those adjustments. And I understand of course, that not everybody has, you know, a situation where that's possible. But I think kind of what tips you up into as you grow as a developer is being able to recognize kind of all those facets and working on how to maneuver then into those improvements and learning how to um, assess and move way that works for your team. But yeah, I think I tipped our topic just a little bit there, Claire, but...
No, I, I think there was something that I wanted to touch on that you had mentioned, which was like different technologies. And, you know, with those opinions that I'd mentioned earlier, there's also different like ways of doing things per language.
And like, like in my previous role, I was in a Ruby environment and there's this term like called Rubyist like way of doing things and. So even just the conventions of, of, of doing things are like super, they could be super different depending on the language, even though like the language is kind of share similarities.
And so I guess another piece of advice is just allowing yourself to learn that stuff and understanding that that's going to take time. Like you can read any kind of instruction manual you want, but you're not going to figure it out overnight. And a lot of times in, you know, in coding uh, jobs and stuff it's like, you know, how long does it take until you push your first commit or something like that? And like that first commit is generally like putting your name in some file. Like it's nothing big. And, you know, even personally, like I have felt, you know, the desire to like make an impact as soon as possible.
And like, that's not necessarily expected of you and especially in this role, like it has been very, very apparent that I have the time to kind of figure out what best way to make impact, um, which is great. So like kind of just feeling those things out, I think will help you a lot and kind of settle into your new role, whatever role that might be.
What I like to do when I come into a new role is I try to figure out where my skills are kind of like niche. Where, where I can make a big impact and where it might be lacking on the team or something like that.
Interestingly enough, on my team currently, everyone seems very generalized in a lot of different things, which is kind of nice.
And so it's that ability to understand kind of like where you can make the most impact. Uh, for me has been a little bit harder of a, of a discussion, but at the same time, that's a personal feeling. I already know that I've made a lot of impact on the team within the first three months. And that's been told to me time and time again. Which is great.
So I think coming into a new code base in general is like just that really scary feeling where you're like, I don't know what I'm doing. I have to relearn everything. And, and we don't always get the luxury of, you know, moving from a code base in this particular language to another code base in the exact same language, you know, it's generally not like that.
So I think that's just something to keep in mind. Everyone has a ramp up period. And, um, you're not gonna know everything. And I mean, Steph, like she said earlier, like she's been in this code base that I just recently came into for almost a year. And it's still like, you know, she's still finding things, which I think that's pretty natural.
Yeah. So I I'm coming up to my year at this point of which we're recording, um, which will be more than a year, by the time this episodes released. But anyway, um, and Claire and I both had an experience of our past jobs. We were a little more siloed too, which also gives us a little bit different lens on, you know, our own adjustments into a large code base where there's more support.
And as Claire mentioned, we have more people to rely on because, um, that are also doing similar job functions to us. Just just a little point of note on, you know, how we're approaching things. So for myself, um, I. One thing that was extremely helpful to me on a very practical level of exploring the code base was, uh, using tools available to me.
So I use VS Code as my editor choice and using plugins, like GitLens. So I could literally jump to, you know, it gives you a little notice of who edited it and how long ago, which is very useful information, you know? And you can actually jump over very quickly to the actual PR or, you know, commit where that was changed.
And that helps you to create that broader picture that may not always be evident and you can see actual discussion that happened, you know? So if, if you have the benefit of having that history of, uh, version control for roughly as old as the code base is, right? So that's helped me a lot.
My, my approach to learning new things is I just will, at this point in my career, you know, knowing the fundamentals of, of things is very helpful. But then beyond that, you know, I found that the code is usually readable, but I might not know how to, of course write it from scratch. So being able to take existing examples of which we have, uh, in our code base quite a few, you know, existing examples and just modifying, copying, pasting, uh, you know, and modifying them, um, to explore what are they doing?
And again, kind of having the benefit of a typed language where you get that intellisense that helps you identify the, what a function is doing or how many times it's used. And so I definitely recommend if you don't have a IDE or you don't have a plugin set that helps you identify those things, um, to check out what might be available for your language of choice. Because again, uh, when you are looking to make a change and aren't a hundred percent sure of the impact, uh, those can help you better identify that. And of course, beyond that, just simply talking to your coworkers who have that, uh, benefit of the history of, of the legacy of the thing you're working on.
Yeah, for sure. I think that, I think one thing you mentioned was, um, like, you know, the IDE stuff, and I think it's important to like, kind of have your own setup. Um, whether it spans different like jobs or whatever. Um, like my VS Code set up is synched through my GitHub. And so like, it's the same on my personal computer as it is on my, on my work computer, which is really nice.
This isn't an advertisement for VS Code. There's plenty of other ways of doing things. Um, plenty of friends have dot file GitHub repositories, for example, um, And I think it's just important to like, get your working environment is important, whether it's the desk that you sit at or, you know, the coding environment that you're in, um, in the, the, um, development environment that you choose to use, um. Whether it be the wretched VIM or, you know, whatever variant of that. Um, uh, but either way, like kind of find out what's yours. Cause it'll help that comfort factor, especially when you're in a new code base. And if you know how to use those tools, then it'll help you figure out kinda what's going on, you know, as, as time goes on.
And I always, I always ask for a language or, you know, uh, specific things that are to the nature of your job. You might find a new thing you like to, um, that helps even better. I hope that our smatterings of, um, different, uh, codebase experiences kind of helped both introduce you to like, kind of how we've introduced ourselves to code bases.
But I also think it was a pretty good fitting for the start of season two, uh, of what we're dubbing season two, of Word Wrap, because it's more about, I think this season is going to be more about just not necessarily advice, but like experiences too, which I'm really excited about. So we're going to be trying to do a little bit more of a timed release, so we'll see how that goes.
And yeah. Thanks for joining us. Uh, Steph, do you have anything to add before we, before we end it today?
If you are interested in sponsoring the upcoming season of Word Wrap show, you can visit WordWrap.dev, and we will have the most sophisticated, modern cutting edge form you've ever seen to go ahead and get in touch and we'll work out some sponsorship opportunities to promote you both on the a show and on our website.
Till next time!
Thanks for listening. Be sure to subscribe and keep in touch on Twitter by following us @WordWrapShow. If you're able to cover show costs, join us at Patreon.com/WordWrap. We'll see you next episode!View All Episodes