5 tips to quickly understand a new code base - FunFunFunction #7

Key Takeaways

I have to I have to make a video coffee Swedish [Music] JavaScript you need water this is probably not the right way to do it but it's the way I do it oh [Music] when you work as a programmer it's only a very small part of your day that is spent on actually writing code the vast majority of your time is spent trying to understand code that was already written either it's somebody else's code or it's some code that you wrote yourself a year ago it is especially tricky to get into a completely new code base it might be uh a new job or a code base that your team takes over from another team at work I've done this a few times during my career and I've developed a sort of process for it and I figured it would be interesting to a couple of people to hear about it that is what we are going to talk about today in case you are new you are watching fun fun function it's a weekly show where we try to become more excited and confident about programming by exploring old wisdom wild ideas and having fun at the end of this episode I will customarily ask you to subscribe without further Ado my fstep process to understand finding a new code basee is find a mentor get an overview do a small Quest have a don't get stuck Rule and use code review so step one find a mentor find a programmer that is already familiar with the codebase and ask them if they are willing to be peppered with your silly questions over the coming weeks it's also a bonus if you can arrange so that the Project Lead is aware of this relationship so that they can ease off a bit on your Mentor during this period I should say that in some cases it's going to be a challenge to find a meure the code base that you're trying to get into might be an open-source project or um your workplace culture might just be crap and people might not be very interested in helping others out even so I think that you should make an effort to try to find a menure uh if that is at all remotely possible because I don't think it's really realistic to become familiar with a code base without talking to an actual person that works in it without Aid you're basically just doing some kind of weird archaeology and that is going to take you 10 times longer than if you're doing it yourself find a mentor that is step one step two get an overview ask your mentor to give you a high level lever ask your mentor to give you a highlevel overview of the system it's uh philosophy its architecture its style or lack of it ask your Mentor what third party tools and Frameworks and libraries are being used and uh make a list of them it will really help you to study the documentation and tutorials of these uh tools and Frameworks and libraries in isolation before exposing yourself to them when they are in tangle together in a big system that you're unfamiliar with it's also helpful if you can ask your mentor to give you a sort of History lesson on why and how this system or application came to be and uh its predecessor if there was one and that is step two get an overview step three do a small Quest simply ask your mentor to assign you a small task that they would think is approp for a beginner in the code base it's usually a small bug or a tiny tiny feature do a small Quest that is step three step four have a don't get stuck rule you should sit down and try to fix the quest on your own but as soon as you get stuck for more than 15 20 minutes or so you should ask your Mentor for help you should always try to solve the problem on your own for a bit but only for a bit in my experience if you get stuck you can figure most things out in 15 minutes but if you don't if you you haven't been unstuck uh in 15 minutes it's most likely going to take you hours to get unstuck and that is just wasting time the don't get stuck rule is really really important but it is surprisingly hard to follow because when you get stuck you feel like you should be able to fix the problem on your own try to remember that it is a bad thing a really really bad thing to be a lone wolf great software is built by great teams not great developers I recommend using an actual timer to keep yourself from going into Lone Wolf mode I personally use break time for Mac have a don't get stuck rule that is step four final step five code review use code review when you have completed your quest and have a fix submit your code for review by your Mentor they will point out changes that you can make to reuse existing parts of the codebase instead of writing your own and uh how to make your change fit more holistically into the project while we're at it I'd like to make a shout out to code review in general because it is amazing if your team does not already code review on every change today adding that to your process is a single s Le best quality improvement that you can make I'm completely serious about that it improves code quality it improves knowledge sharing it improves consistency and most importantly it makes your team feel a shared ownership of the code make use of code review that is step five recap find a mentor get an overview do a small Quest have a don't get stuck Rule and use code review and then you just repeat you go back to step three and pick another small Quest and so on this will get you familiar with a new code base really quickly and that's it for this episode of fun fun function make sure that you don't miss out on the next episode on Monday click the button to subscribe until next Monday please stay tuned