Alternate title: new codebase who dis?
Delivered at:
Find me on Twitter @SamuelDataT.
0:00
Alright, yeah, thank you all so much for being here. Great to be here. Let's get started. When I started studying computer science in college, it's kind of I realized that the software industry is kind of like this pizza. Stay with me, I know, that's a weird statement. When I was in college, I'm basically looking at this pizza, I can see this little triangle. And I see that there's some pepperonis on it. And these pepperonis are kind of like, the things that I knew about at the time. So I'm thinking, when I go into the software industry, I'm going to be all about working on figuring out how to balance abl trees and do quadratic versus linear programming and hash tables, and all this stuff that I was learning in my classes. And all of that stuff was super interesting, I think, really valuable. But what I realized was, once I got into the industry, there was actually a little bit more like this, the software industry is is this pizza, that we really have a lot of other things in it that are not just crazy, algorithmic, really interesting algorithm problems. But there's a lot of there's a lot of other stuff in there, too. And so this part of the pizza that has just cheese on it, it's still really great, still really important. But it's things like knowing how to set up Jenkins builds, knowing how to configure Iam properly, figuring out your build tools, like understanding how Maven works, all those kinds of things are all super important. And without them, you would not have the pizza basically. So that's what I want to talk about today is one of these particular areas, that is not a pepperoni, we're going to be talking about how to join a new team, and specifically how to learn a new code base. I think that it is really difficult to teach this. And I really wish that when I had been in school, someone had at least tried. So that's what I'm going to try to do for you in the next little bit of time, we'll see how it goes. I think there'll be plenty of tips in here for you, no matter whether you are a new developer, if you are relatively experienced, I hope to have a few tips in here. That'll be helpful too. I know there's a lot of other really interesting talks. So before I jump in, let y'all have a chance to there's other cool tracks happening. Also, if you don't want to learn about finding a new codebase, now's the time for you to leave, because that's what we're gonna be talking about today. This is the way we're going to do that. Right now, you can probably tell that you're in the introductory period. After that, we're going to talk about what I think you should do day one when you join the team. And then we're going to talk about the mindset that you should have when you are reading and writing code before moving on to talking about the process by which I recommend and I try to use always when reading and writing code. And then finally, talk about some tools that can make this all a little bit easier. So on day one, there are three things that I personally believe you should do. The first of those is to set up your development environment. And when you're doing this, you should make sure you are really paying close attention as you do that. There's a lot of hints in this process that can help you understand what sort of world you're getting into on this new team. And as you develop in this new world. So that you should try to understand what services you're running as you get your development environment going. For instance, if you're suddenly running Redis, you might think to yourself, ah, we have some sort of caching layer, I wonder what that's about. This can also give you some hints as to what dependencies exist between services. So for instance, if you have one project that needs to be running before you get another project running, that gives you a hint that that second project probably needs the first project to run and there's some interrelation there. You should also when you're doing this, take specific notes on what you're doing. And you can do this on a piece of paper, I find it really helpful to just open up some sort of note app on my computer and literally copy and paste in commands that I'm running. I think anyone, I tend to sort of come from the Python world, and anyone who has ever tried to set up their dev development environment has always found it really helpful to know exactly how you screwed up your system Python installation later. So it's good to make sure that you know exactly what you're doing. The last thing I would say regarding setting your development environment up is ideally the project that you're working on will have some sort of test suite. And if you can get that test suite running and make sure that all the tests are green, that probably means that you've got things set up correctly. So that's just a win on its own. But once you've got that all those green tests going, the next thing that you should try to do is break those tests, literally open up a random file in the project and just delete some lines and see what tests break. This will start to give you an understanding of what pieces of code relate to what other ones.
4:36
The next thing you should do on day one is ask some senior members of the team to give you some sort of overview of the architecture that you're gonna be working on. The first thing that you can do here is try to find some sort of document or diagram it doesn't always exist. But ideally, there's some sort of wiki page that you can go to and see a drawing of kind of the way that things are laid out. And when you do that, make sure you check it out. When the page was last edited, because sometimes and in in some places, in some situations, the architecture of a system can change pretty rapidly. And if you're looking at something that is old, it might not relate to the current world. And that would be really sad for you to figure out the wrong things. You should ask them a lot of questions just ask, like your team. In a healthy team that is functioning well, people will be excited to answer your questions, because they know that answering the questions is going to help you become a more effective teammate, which even just for selfish reasons, when I have new people joining teams that I'm on, I want to give them as much information as I possibly can. So that way, they can start doing some of this work, and I don't have to do the work. That's the whole goal. So don't ever feel bad about asking questions. A few questions you should think about asking, what repositories do we own? What things are we working in frequently? Are there any repositories we share with other teams? How is this all structured? another great question to ask is, how does a feature get from running on my laptop to actually being visible in production, this will give you some really good insight about sort of the the like deployment pipeline, which can be really helpful to know about, depending on what size of company you're in, you may need to know a lot about that, or you may not need to know very much about at all. And you also will want to ask what kind of vendors what API's are we relying on so that you can get a sense for what those things are at really helpful early, when you can provide to the rest of your team is to at the end of this process, create a new architecture diagram, or at least update the existing one, if it does already exist. This is a nice way to sort of get build some early goodwill with your team. And you can roll up to everybody and say, Hey, I made this architecture document, I believe it's accurate based on what I've heard, here's what I have. And this can be something that's really helpful not just for the other people on your team, but as well for new members who will probably join your team in the future. The third thing that you should do on day one is figure out what the business does. Because if you don't, you are completely doomed, you will never be successful. If you don't understand the business, at least to some degree. It's good to know what the mission of the company is, what sort of products it offers, and the goals that it has different companies will do this in different ways. They will use different goal setting frameworks. But it's really nice to know what are we trying to do as a company. Once you know that, you need to know how your team is going to contribute to that. So is it you know, we work on this part of the product, which helps us achieve this specific goal. And the way that we can achieve that specific goal is to you know, improve conversion rates over here, something like that. Great questions to ask include, how can we impact the goals of the company who will get mad if our code breaks, just horrifically, this is a really useful one because it not only tells you who relies a lot on your on your software, but it can also give you a sense for how careful you should be. Obviously, it's never a great idea to break production. But it's definitely good to know if I've production for for one minute, am I going to lose the company one cent, or $1 million. There's a significant difference between those two things. And understanding those trade offs. And there's the the context in which you're working is very important.
8:18
Okay,
8:19
that's day one. The next thing that I want to talk about is the mindset that you should use when you are working in a new codebase, particularly in a new team. This can all be summarized, as learned by doing. There's a book that I read recently that I really enjoyed called ultra learning by Scott young. This book is sort of about how to teach yourself things, Scott young as this sort of autodidactic figure who has spent a lot of time thinking and writing about productivity and learning. And he's done a bunch of crazy things, including going through all four years of an MIT computer science curriculum in one year. And so then he wrote this book about people who do those kinds of crazy learning projects. And it's really interesting to hear about some of the principles for learning effectively. One of the ones that resonated super strongly with me, is the idea of directness. Scott young says, The easiest way to learn directly is to simply spend a lot of time doing the thing you want to become good at. In this case, we want to spend a lot of time working on this team. We are joining the team to produce valuable software. And so what you should do is just start doing it, start working on the software, start building the stuff. That's the best way to get better. When you are making an impact. That's the best way that you're going to be able to gain any kind of deep understanding. What you want to make sure you're doing as you develop and read and understand is understand the code that you are trying to work on well enough that you can make the change that you need to make to have the effects that you want to have to make an impact on your team and on your product. What you don't want to do is read every single line. I think this is a trap that can be sometimes easy to fall into is thinking I needed To understand every part of this program, I need to understand every part of the architecture before I start messing with things. And that was something that I sort of felt like at the beginning of my career, and now understand that, you will gain that understanding over time. And actually sort of counter intuitively, the fastest way to gain that understanding is going to be by doing the work itself, when you're reading stuff, without any sort of directed goal of trying to say, um, you know, I need to make our scoreboard service predict, you know, be able to produce 2020 high schools instead of 10. That gives you sort of a goal to work toward and makes your brain think about things harder, and make sure that you're understanding things better.
10:43
When we talk about reading code, I worry that sometimes we we've overloaded the word read too much reading book is incredibly different from reading code. And I don't know that that's necessarily, really, the differences between those I don't think are elucidated strongly enough. For an example, imagine if the Lord of the Rings series was written as a software artifact, you would get things like, Okay, well, there's not three books that are, you know, this long, you would have maybe 1000 books that are all four pages long. And you'd have a case where some of these, you know, little tiny books are bound together. And some of them have like, there's this one book that has all the magic in it, except for any magic that's related to grass is actually over in this one for some weird historical reasons. And actually, all the sword fighting also happens in that one, except for actually sort of fighting with magic is back in the magic one. And you can see how this would get very complicated very fast. In reading a book and writing a book, you're trying to sort of create a coherent narrative for people to follow. And ideally, when you are writing code, you are also trying to create a coherent narrative. But the structures we have for doing that are dramatically different. When when we're writing code, we don't just have one very long file. Ideally, if you do have just one very long file, that's not a great time, ideally, you're able to break these things up into smaller units that can then be understood more easily. And that's something that I think is an interesting concept, that your knowledge will grow in sort of a recursive way. So you start at the top. And on day one, you know, you're getting this architectural overview, you're understanding what the various services do. And then you're going to get a ticket. Ideally, ideally, your team has sort of queued up something or teed something up for you, that would be a good fit for a new person to help them learn some pieces of the system, and you get this new ticket. And so now you need to figure out, Okay, I'm gonna have to modify this service in order to be able to get this thing done. And then you're going to dive into that service and say, Okay, here's the sort of modules that are in that service, or here's a little you know, what, however, the service ends up being organized, visit with these different things are and sort of, more or less what they do. And they can try to understand, okay, I think I'm probably going to need to modify this particular module, what are the classes that are in here? What are they all doing, and you can sort of progress down this path, until at a certain point, you get to an individual line of code. I think, if you're writing code, reading a single line of code is very, it's probably very easy for you unless there's some like weird syntax that you're not familiar with reading the line is relatively self explanatory, you can see a line and say, This line is incrementing by one, or you can say this line is creating a new database access object. That's not particularly complicated. It's all the steps above it that are hard. And what I would like to say is that what you can do in this sort of recursive pattern, is when you get down to understanding the level of individual codes, the next thing you should be doing is creating chunks. And what I mean by chunks is this concept of neuroscience, where chunking sort of refers to the brain's ability to bind detailed information to a concept that is easy to remember. So for instance, I don't have to know that a particular function call gets a handle to the database, and then builds a query that it wants to run includes certain parts of the query based on the parameters passed to the function, runs the query handles errors, comes back with my result, modifies it in some way. There's, there's all these very detailed steps that are happening inside this function call. But ideally, at the end of the day, I can see the function and say, Okay, I know what all the detailed steps of this are, I know that this function is getting high scores. And that's a much easier concept to remember and think about, and reason about, and stick inside of a human brain than trying to remember 12 detailed steps 12 individual lines of code all at once. In other words, all we're trying to do here is make sure we can see the forest for the trees, we don't need to focus on every individual tree, every individual branch on that tree, every individual pine needle, we need to see is that's a tree, or we need to know is this function gets high scores. The last tip I have in terms of mindset is to think about this in two different ways. And there are a couple different ways to think about this that I at least find useful. The first one is To think about it, sort of in terms of code pads, and so you might think, Okay, the first step is that somebody makes an HTTP request to slash puppy. And then that calls my get puppy method that I have, you know, my routing setup to go to, and then get puppy uses my puppy manager object to get a random puppy and then inside get random puppy, we're actually running this query through our database accessor. This is one way that I find really helpful to think about these things. And it is also really helpful again, to draw these little diagrams as you're going along can be really useful.
15:34
The other way to think about this is the sort of the way that data flows through the system. And different systems will make more or less sense to think about in one or two, one of these ways or the other. And so when you're in a situation where you're not sure, try to do both, and see which one helps you the best is what I would recommend. When talking about data flows, I mean, maybe we think about the scores living in some database, and then that flows into a score data access object that happens to know information about scores. What's interesting to think about is what objects know what things at what point in the program, and how does that data flow through the system. So maybe scores are known about by the score data access object. And then the score controller might use score data access objects. And then finally, that information by might end up getting passed through to a some sort of front end client, a scoreboard, j. s, for example, this is a bit of a contrived example. But hopefully, the idea is clear. So that's more or less the mindset. Actually, before I talk about process, there's one more thing on mindset that I've forgot to make a slide for. Sorry, just have to listen to my dulcet tones. And one last mindset thing is, you might not be wrong. And I think sometimes when we join teams, or at least, I know that I have struggled sometimes when I join a team to assume that the team I'm joining has gotten everything perfectly right. And they've thought through everything super well. had any suggestions that I might have? are, are foolish in some way. And I think that is a bad instinct to have for a number of reasons. Firstly, because no one is perfect. So the team might actually have just made a bad mistake. And you being able to bring up Hey, is there a reason we're doing this in this way I've been used to seeing it this other way, can be really helpful. And we can help spur really good discussion, and can also help lead to new insights. For instance, if you have like some particular way you really think is the best way to implement a singleton. And you bring it up with your team. And they're like, Oh, actually, we've been doing Singleton's this other way, then at least one of you gets to learn something by the end of it. Either you learn that your way is not optimal. Or they learned that your rate is optimal. And But either way, there's learning happening. And that's a good benefit. So don't think that you're always wrong about things, definitely bring up your concerns and your thoughts and try to learn stuff. It's very helpful.
17:57
Okay, let's talk about process. And the short version of this is that I think the scientific method is one of the most impressive sort of achievements of the human species is being able to understand how to gain knowledge about the world in a scientific way, I think is incredible, that we have figured out how to do that. And so I think we would be remiss not to use that same process when we are reading and writing code. So when we are we get a ticket in this is roughly the process that I think we should follow, the first step is going to be to find out what code is relevant. So if I'm trying to work on something about a scoreboard service, I probably don't need to worry about user authentication that just isn't particularly relevant. So we need to do is identify what that relevant code is. The next thing we need to do is form a hypothesis about what we need to change. In order to do this, we're going to have to understand the code that we're looking at and working on well enough to actually form this hypothesis. Next step is going to be to test your hypothesis. So make your change and see if it was correct. At this point, if there's any people who are really into test driven design, in the YouTube comments, I'm sure you're blasting off about how like, test driven design is the coolest thing ever. And it's really useful. I completely get it, there's a school of thought that says, even before you make your change, you should write a little test that makes sure what you think is going to happen, it's going to happen. And I completely agree that that is a really useful tool to be able to quickly understand whether your hypothesis was correct. And even even before you make your changes, it's nice to have that specifically written out. And still at times, it can be difficult to do this. And so it's also completely acceptable, in my opinion, to just make your change and then manually verify whether it worked. Now, just because you verify that it works doesn't mean that you're done. The last step is to improve the quality of whatever it is that you've just written. So if you didn't write a test at first, writing tests now is super important. If you avoid writing tests for your code, the code That you write immediately becomes legacy code, and very difficult to maintain. What's going to happen if you don't write the assess is later something's going to change, and you're not going to things are broken, where they, when you should have already known that from automated testing, or you're gonna need to refactor is going to be a huge pain, right? test, please. And then other things like improving the legibility and maintainability of your code, I think are really important to do at this stage, make sure that because code is read far more often than it is written, make sure that you're optimizing for the reading case, I know that it's it's sometimes convenient to write code, and leave variable names as I or, like, have really short abbreviations for function names. I know that's very nice for the writing case. And that's often sort of optimizing for the writing case, but code is generally written once, and then it's going to be read, you know, multiple times, potentially 10s, hundreds, thousands of times by, you know, many individuals potentially. So you want to make sure you're optimizing for the reading case, and making sure that it's very easy to read and understand the code that you're writing. And that's what you should be doing in this last step. Okay, let's talk about tooling. And there's a few different sets of tools that I think are useful. But as far as why I think these tools are useful. Let me say that writing code is one of the I would say sort of developing software is generally the most difficult part of the job as a software engineer, at least in my experience, is one of the most mentally taxing parts. And what that means is any when we can get in terms of decreasing the mental load, we have to be under when we are doing this is a huge win. because it not only means that we, you know, the job is just easier, which is a nice thing. But if you think about our level of our level of skill and our level of ability to execute on something, if we're maxed out at our at some sort of level of skill, of course, we can grow. But our sort of Max skill is by practice over time. But at a certain point, if we are maxed out against we are only capable of doing so much. And then one easy way, or one way that you can sort of be able to achieve more is by using tools that help you offload some of that cognition elsewhere. And so that's the way that I try to think about tools is they are basically, you know, it's kind of like the old Steve Jobs code, it's a bicycle of the mind, it's going to help your mind to go faster and be more efficient. And these tools are really great. They're not a replacement for thinking, but they can make the process far easier. You certainly could get by with just using like grep, and a text editor, and you could probably figure out everything. But it's going to be a lot harder and a lot less efficient than using some of these tools.
22:51
Um,
22:52
I kind of think about tools in a number of broad categories. The first category being this the step when we're trying to find what code is relevant, there's a few things that we should do there. The first is to just run the code. So like, if you have some sort of, like web application, just get it running, and understand what exists, go click on the page that you're supposed to add a button to try to understand, where am I going to be adding this? Do I need to create the whole new page? Do I just need a button somewhere, understanding the context that you're working in is going to really help you when you're writing this code. And another tip that I would say, didn't occur to me until far later than I care to admit, is that using the debugger is not just helpful for when you found a bug and you're trying to understand what's going on. It's also super helpful to do for completely working code, because you can run your program with the debugger enabled. And just start clicking through and seeing what lines of code get executed to do various things in the system, which is invaluable. Like you cannot, you cannot gain that understanding in hardly any other way. In hardly any other more efficient way than just using the debugger and seeing what lines of code get run. Other than just running the code. I think searching in the project can also be a really helpful way to find relevant code. There's a number of tools that I mean when I say searching the project is going to vary from company to company significantly. Some common tools that people use for this kind of stuff are JIRA, Asana, Pivotal Tracker, GitHub, and get lab both have issues features. There's a lot of other tools that people use to track all this stuff. And it would be foolish not to at least try to find information in these things. Generally. A lot of times we are standing on the shoulders of giants in this field and we are able to leverage some sort of amount of past work in our current work. And what's useful to be able to do is understand what has already been done before you're in the situation so that way you know what you can reuse. And this will help you again get further along than you would be able to if you were just starting from scratch. I cannot tell you how often I have heard Other engineers and developers say things like, oh, the only reason I was able to get this done so fast is because I saw someone else in the company had done a project that was similar to this. And I was able to copy the config that they had for their spark job. And that enabled me to get my spark job running a lot more easily and not have to run into all these weird errors and things like that. So searching the project is super helpful. And one way that that looks, is to just literally open up JIRA, I went to the spark JIRA, because it's a, an open source project. And it's all available. So I'm allowed to show you it. But if you just search for like, Hey, I'm working on a ticket in spark about date times, like, let me just search date time in here and see what comes up. And then you can sort of change the way that things are ordered, understand what's happening in any given ticket and sort of give a glance over some of these things. And understand what work has come before you can be super helpful. also helpful to find out, sometimes you'll get a ticket, and it will like be something somebody has already done. And you can sometimes find that by doing this. This is what the GitHub issues UI looks like. This can be really helpful for you understanding what problems people are having, what what people are working in sort of what areas and large companies that can be particularly valuable to know, sometimes, you don't even know who to ask about something. And if you can figure out who has been working in this area, they can often sort of help you along and guide you along the path. And the other broad category of tools that I would describe when we're talking about finding relevant code, our code search tools. So I use one called the silver searcher maybe every day, it's super useful. there's a there's a another tool that's very similar to it called rip graph that I haven't used, but I've heard is really good. And just to give you an idea of what that looks like, if I'm working on a ticket that's about phonemes, for instance, I might go into my project and just type ag phoneme in the, in the console, and see everywhere in the code that the word phoneme is used. And now I might know Oh, hey, look, we have something in source slash app.pi. And I can go in here and understand this is where we're talking about phonemes. And it's a really good way to just figure out like, Where is this thing even being used or talked about in the code base, and can help you find help you find those relevant services, modules, classes, etc.
27:19
So these are really great tools. If you're working on code that you have checked out locally, because they work on you know, the code that's running, you know, the code that's present on your hard drive. But they're not as great when you have a large number of projects that, you know, might be spread throughout the company, you don't necessarily have all of it checked out onto your, onto your laptop. And you might need to know, hey, like I'm going to modify this thing in our service. But I want to make sure it doesn't break everybody else's. This is where these, these other tools can come in handy. Things like open grok, or source graph are really helpful, because they can let you search the entire code base of a certain organization, namely your organization. GitHub and get lab both also have a feature where you can search code within your specific organization. You can also search issues within your specific organization, that kind of thing. This is what open grok looks like I found this screenshot on the internet. One way you can see this happening here is that this person has searched for util with anything before and anything after it as a definition. And so this will look specifically for places where a class that has utility and the name of it is defined. And so you know, this person can now say, hey, file utility finds a file util. form, utility finds forum, util, etc. This is a really useful way to understand what code is relevant again. When we talk about understanding code, that's sort of the next step in the process, I would highly recommend using an ID. Again, you can totally get away with just using, you know, a text editor, and grep. Even if you want to use sort of superpower yourself with those search tools. That's also really helpful because you can do things like, hey, suddenly, I'm using, you know, this, this code is calling file util dot something, what does that meant to do? And you can search, you know, pull up silver searcher and search for utils, dot whatever, and find it. And that's really helpful. I think that's awesome. No no qualms with that. But in my experience, using an ID has been super helpful. I'm a big fan of JetBrains. I'm completely unaffiliated with them. But for instance, one thing that they have that's really nice is the ability to Command click on things. This is a little recording I took just so I could show you what that looks like. I sort of hear when you Command click on something. And let me scroll back here just a second. So when you command if I'm reading this get puns method, for instance. And I'm wondering, hey, this word, the phonemes function, what does that do? I can hold down command on my keyboard, which I think you know, if you have a Windows computer, you'd hold down Ctrl and click on it and it will take you right to the definition Have that file or sorry, have that function, which is very helpful. And then once you get to that function, you can actually do the same thing again, hold on command, click on the name, and it will show you usages of that. And so you can see, okay, we're defining this is used here, but it's also used in this other place. This is beyond useful. If you're using some sort of common methods. If you're finding trying to find out like, how do people instantiate this object, you can just go to the object and see where people are using it, which is going to be also you, you could read the documentation, or you could read the code and the code is gonna be a lot faster. As you're doing this reminder, create chunks, as we're going through this, we need to make sure that we are able to see the forest for the trees, we do not need to care about individual trees, we do not need to care about individual lines of code, what we need to be doing is understanding word to phonemes well enough that I can in my head, say, Okay, this method takes a word and turns it into a list of phone needs. And that's enough for me to then use that function effectively. If you're trying to keep around all of the lines of code that you've read in your head, you are not going to have any success, it's gonna be very difficult to do this. As you're doing this, one way to help guide you're thinking and sort of offload some of the work is to take notes, draw little diagrams. Again, this can be as simple as just getting a piece of paper out and drawing little little stuff with a pen, that's completely legit. You don't have to, you know, break out lucid chart and start doing UML diagrams or anything like that, you can just use a pencil and paper, it's completely fine. And I am consistently shocked at the amount of productive work that you can do when you get enough people around a whiteboard in a shared space. And that is one of the great tragedies of the pandemic is that the lack of ability to talk through problems on a whiteboard, by words can be super helpful for this kind of thing as well. I personally really enjoy using a digital note taking app for this, even if I've drawn a little diagram, sometimes I'll take a picture of it and save it into into my Notes app. So that way I can have it later if I'm working on the same thing. Another thing would be really useful as you're doing this, just in that same Notes app, just write out what you're what you're working on. This is a pro tip for those people who feel like they get interrupted by meetings a lot. If you are,
32:20
if you are like getting interrupted, having those notes is really helpful. Because you can go back and look and say, This is what I was working on at that time. Finally, again, make sure you're asking for help if you run if you run into trouble. And obviously try it for yourself first spend 15 minutes trying to work through whatever problem you have. But if you don't know what it is after that you should ask because you're you're wasting your time at that point. And a tool it's really helpful for this is something called get blame. This is a screenshot of a git blame for a particular file of a particular project that I have used and liked. And what you can see here is on over on the right, we have a like, you know, source code, basically. And then on the left side, we have the information that has like who's been working on that particular line, which is helpful, because you can then know, hey, if I'm wonder about get var type, I need to go talk to romaine x, I don't know how to pronounce that name, sorry, romaine x, if you're in the audience, let me know. And finally, when you're working with libraries, these are very common, obviously. And they often have documentation, that's pretty good. And I definitely recommend reading those if they're good, but sometimes they're not. And you have to use Stack Overflow. And that's completely legitimate. The, one of the more recent things that I have discovered is super helpful is being able to use GitHub search effectively. Because so many people use GitHub, and they allow you to search through all public code, you can learn quite a bit about how to use libraries just through that. So what that could look like, if, for instance, if I'm trying to set up a BigQuery job, I'm going to be using this query job configuration object. And let's say I'm reading through the starter page on like the GCP docs. And it gives me a good starting point, I you know, understand where I'm going with this. But I need to know, are there certain, you know, parameters that are commonly used on a career job configuration, that kind of thing is really helpful to know sometimes, and GitHub searches amazing for this, a huge fan of it, I highly recommend it, just go to GitHub, type in the thing and see what comes up really useful. Two pro tips on this, the first one, change the sort order. This is completely anecdotal. But I have found that sometimes adjusting to do most recently indexed is really, for some reason, getting the better results. I don't know why completely anecdotal. And then also choosing what language is is reliable, because you'll find language specific examples that help you sort of get a better hit rate in terms of what you're actually looking for. So this is that same search, but if I'm looking for recently indexed Java files that are using query job configuration, I can search this and see okay, these people have some sort A free tier billing service that uses query job configuration. And now what I can do is click specifically on this line that says 250. And see, here's the, you know, query job configuration builder that they're setting up, and I could see what options they're using. And that gives me a better understanding of how to set up that builder for myself, which is beyond useful. That was a lot. I'm gonna take a deep breath, I'm gonna drink some water, because I want to Everyone calm yourself, and then we'll we'll talk a little bit more.
35:41
Okay, there's a few takeaways. If you take away anything from this, here's the short and sweet. Make sure that when you're on a new team, you are working on software, make sure you are focusing on delivering valuable software I'm reading without a goal is not going to help you understand software any faster. And the best way to learn is by doing a really helpful thing to do is to focus early on providing value to your team, that could be creating an updated architecture diagram. And that could be just, you know, getting something working soon. That's that's a really nice thing to be able to do for your team. This is nice, not only because like that's what your job is, and that's what you're paid to do. But also, you're able to build goodwill, when you are showing your team, hey, I want to be a valuable member of this team, I want to support everybody. And like I'm here for you kind of thing. And people will be much more likely to reciprocate that feeling. If you are leading on that, that's a good way to do it. Finally, make sure you are decreasing cognitive load as much as you possibly can. There's a lot of really good tools to do this anything from, you know, paper and pencil all the way through to some some really, you know, somewhat high tech, searching software can be really helpful. Because this job is hard, no matter what you say, no matter what people say it's a hard job. And it's a lot of thinking. And so decreasing your cognitive load is a huge win. In that case. Thank you so much for talking. I really appreciate it. These slides are available at ISC GD slash SD f 20. That's SDF for Southern dev fest. My name is Samuel Taylor, I've loved getting to chat with you. Feel free to talk to me on Twitter, if you have questions. I, I hope this is relevant broadly. But if you have any specific questions about like data stuff, that's that's what I do. I'm a machine learning engineer. And so if you want to talk about machine learning, or AI or whatever, like, hit me up on Twitter, send me an email, I'd love to hear from you. One requests, if I can make any requests from you, this is the first time I've ever given this talk. And I want to make sure that it's as helpful as it possibly can be. And if you'd be willing to send me an email that just says one thing you liked, and one thing you didn't like about this talk, I would be immensely grateful for that. Thank you.
38:11
Okay, thank you for the amazing talk. loved all of the information. We're gonna take a couple of minutes to answer some questions, if that's okay with you.
38:20
I'd love that. Yeah, that sounds great. Sorry. And I'm gonna be looking over here because this is my like my cameras over here. But my notes over here, so I'll be able to see the questions over here.
38:28
All good. All good. So the first question we have comes from Vanessa fountain, how do you approach a situation where you bring up a new way to do something and the other team members do not want to move forward with a newer solution, due to not having familiarity with new tech?
38:42
Oh, Vanessa, if only I knew the answer to this question.
38:45
Um,
38:46
so there are a few things that I would recommend here. I think it's a, it's it's a really difficult spot that you're putting when you're in this situation. Because some, I think there is a lot of validity to using sort of stable, well established technology and not sort of chasing after the shiny new thing. But I also think there's there can be a lot of value in using some new tool that enables you to do something that you didn't realize you could one thing that I have seen people do in this kind of a situation, I try to build some sort of small prototype that demonstrates why this new technology might be valuable. And then that gives you a more concrete thing to talk about. Sometimes these conversations are way too abstract, and people struggle with that, or at least I struggle with it. And when we have a concrete example of like, okay, here's what, you know, this new framework allows us to do, we can see Oh, that's actually super nice. Or we can say Actually, this isn't as big of a witness. I thought it was gonna be
39:47
that'll work or let me scroll up and down here on the comments section to make sure that we don't have anything else. I don't believe we do. We do have plenty of positive feedback though that was great Samuel photoreceptor says that Samuel Taylor first time didn't seem like it great. Alex, door lag Great job, Samuel. So Samuel, I want to thank you so much for your time here to get this information how to us all of these tips have been amazing. Would you do me a favor and posts that very last up curious. Let me post that up there. I'll throw this up there.