30 Oct 2023
In June of this year I gave a talk at Droidcon SF titled “Navigating the Unknown: Tips for Efficiently Learning a New Codebase”. This is the (long overdue) blog post
version of that talk. I’m going to walk through my approach for diving into a new codebase and then cover some next steps that I’ve found help me after I have
developed a good grasp of the codebase I am working in. Just a small note before jumping in: by “codebase” I’m generally referring to any logical area that a
single team might own in a large tech company. If you work on a smaller project, this could mean the codebase in it’s entirety, but it doesn’t have to.
Some brief background
For the last ~2.5 years, I’ve been an Android engineer at Cash App on three different teams. Before that I was in university, where I had the opportunity to take part in six internships. Throughout
all of these experiences I had to get up to speed fast to be able to make the impact that I wanted. As I grew, I realized that my perspective towards how I learned
new codebases changed and I started to see the importance of understanding how the ticket I was working on fit within the broader picture. These are some of the approaches
that I know now that I wish I incorporated earlier on in my career.
My approach
Ask for a code walkthrough
Your teammates who already understand the codebase are your best resource. Asking them to walk you through the codebase overall or through particularly tricky parts is
incredibly valuable. The earlier you can do this when joining a new team, the better. I used to try to learn a new codebase entirely on my own and I found that I would tend to
just pick a direction to investigate and dive in to as many files as I could find. It felt like I was making progress, but often the part that I really needed to
understand was just off the path I had taken. Your teammates can act as guides to point you in the right direction and increase the pace of your learning.
Create an architecture diagram
Creating an architecture diagram is something that I found really helped me understand how all the disparate pieces of the codebase fit together. Even if there is one
already created for your codebase, going through the exercise of trying to make one on your own is a good way to fully grasp how everything connects. I’ve found that
many times when starting work on a new feature, having done this exercise in the past really helped me understand how my work could best be built into the codebase.
Use a debugger
Most people just use a debugger for debugging an issue they are experiencing, however I also like to use a debugger to help understand the fine details of particularly
complex code. There have been many times when using a debugger lead to me to the realization that my assumptions about how a specific piece of logic worked were flawed. Often
times things are more complex than I originally thought and using a debugger forces you to face that reality head on.
What next?
After developing an understanding of a codebase, I realized steps must be taken to ensure that my time spent learning makes an impact on my team, company and career.
Write a doc
Writing a doc is one of the best things to do after you have a solid understanding of a new codebase. This document can serve as a tool for learning for not just yourself, but
also your current teammates and any new hires who will onboard onto your codebase in the future. My main tip is to focus on writing the doc that you wish you had when you were
onboarding. It can include things like the architecture diagram mentioned earlier and more specific descriptions of how complex parts of your codebase work.
Refactor?
As the person who likely has the most recent understanding of the codebase overall, you are in a good position to propose refactors to simplify things for engineers who will
need to understand and make changes in the future. Before making any large sweeping changes, however, it’s always good to ensure you understand the
reasons why things are the way they are. There may be historical context that is impossible to uncover from the codebase itself!
Find opportunities
Lastly, understanding your codebase broadly puts you in a good position to be able to find opportunities to solve problems that might be widespread or only noticeable when taking
a step back to look at the entire system. Finding these opportunities can take different forms depending on the culture and structure of your organization, but don’t be shy to
make proposals that expand your scope beyond your usual day to day work. As you move into more senior engineering levels, expanding beyond your project’s (or even your team’s)
scope becomes more desirable and I believe this increase in scope is incredibly hard to acheive if you have not already developed a deep and broad understanding of your codebase.
The three phases
I see three main phases in learning a new codebase: learn, document and share. Spending the time to learn and understand the codebase you work in will always pay off.
Documenting those learnings will help ensure that you will keep those learnings with you for a long time. Sharing your learnings is where the magic happens. It increases not
only your own understanding, but also that of your teammates and maybe even your whole organization.
04 Jan 2023
I started this blog a long time ago now, but have only just started writing for it relatively recently (albeit not too frequently). While this was spurred on
by a bit of embarassment of just having an empty page here, there were a few other reasons for why I wanted to write more blog posts.
I hope by sharing some of them I might inspire others to write more blog posts as well!
Practice, practice, practice
Firstly, one of the main reasons that I wanted to write more blog posts was simply to practice and improve my writing. Writing is one of the most important
skills to build, in my opinion. It is only more important in a distributed or remote work environment where writing is the main form of communication used
to keep people on the same page. This blog provides a great opportunity to encourage me to write more and edit my thoughts to improve my written communication.
Sharing my experiences
I also want to use this space to help others who might be experiencing similar things to what I have gone through in the past. I hope to build out this space
as a place where I can provide guidance and tips to others. I know that I’ve benefitted a ton from reading other people’s blogs and learning from them,
so I want to be sure to take the chance to give back. Everyone has unique experiences and perspectives, so we all have something worth sharing!
Clarify my thinking
I’ve heard many people mention how helpful writing is in sorting out your thoughts and really seeing if you understand something. This is definitely something that I
have experienced many times as well. When I’m trying to figure out a big decision or want to make sure I really understand a new topic I’m learning, I often like to write
something about it. This blog is a perfect place to do that since it gives me that little extra push to make sure the content is good enough to share.
What am I going to post about?
I don’t really have any specific content plans in mind for this blog. Mostly based off the above three points, I’m just planning to write about topics that fit best
within those guidelines, so mostly things related to my past experiences or things I want to clarify my thinking on and learn more about! So while my current posts
have been mostly tech career growth focused, I could see myself posting about many things from book reviews, travel summaries, technical Android posts or things I may
not have even thought of yet.
Writing this out definitely helped me better figure out what I want to do in this space and all in all, I think there’s benefits from these blog posts even if no one else reads them.
I do hope however, this may inspire some of you to start writing more on your own as well!
30 Aug 2022
Like many others I’ve been working remotely since the beginning of the pandemic. During this time I did two remote internships, one at Google and one at Cash App, before returning to Cash App full-time. I was initially nervous how this was all going to go, especially beginning my career without any in-person mentorship. As the time has gone on, I’ve
grown to really enjoy the flexibility of this remote/hybrid work world and I wanted to share some of the tips that helped me in the first year of my full-time career, including some remote specific tips.
1. Invest in your workspace
Just as you would if you had a fixed desk space in an office, make sure to invest in your remote work environment. Improving your work environment is a long-term investment that will pay dividends in your productivity and health. The most important aspects to me are having a good chair and a well-lit working area. With just these two things it will be much more comfortable to
spend time in your workspace and help you avoid the posture and eye strain problems that may hurt you and your focus. I know this isn’t a unique tip, but I still can’t emphasize it enough!
2. Don’t be afraid to ask
Many times I’ve hesitated setting up a meeting with someone with under a days notice when I’m blocked on something. I never want to disturb my teammates and their work. That said, more often than not
I’ve found that people are willing to hop on a call right away instead of even waiting for a future scheduled meeting! More than once while debugging over Slack, my teammate has simply asked “Do you want to pair on this right now?” and I’ve been shocked! I didn’t know that was an option! You’d be surprised how willing people are to help you out if you just simply ask!
3. Speak broadly
Especially at big companies, speaking up in public places like large Slack channels can seem very daunting as a new grad. I was definitely nervous whenever I had to ask a question more broadly, afraid
that I’ll be asking a ‘stupid’ question. Well, there’s no such thing as a stupid question, that’s what they always say and it’s true. Not only does posting in public places make you more visible and
known within the organization, asking questions there can help everyone learn together. This also applies if you see someone ask a question that you know the answer to … answer it!
4. Take notes
In a remote setting it can sometimes be difficult for your manager or teammmates to follow all the work you are involved in. Make sure to document as much as possible as these things can really come in
handy in performance reviews and even future promotions! Make sure you document important discussions you have, interesting investigations you’ve dug into, and write detailed commit and PR descriptions.
You never know when these things will come in handy in the future!
5. The three R’s: Read, Review, wRite
Especially early in your career, reading PRs and design docs written by your teammates can teach you a ton about the codebase you are working on and the general practices
of your company. Code wise, I’d even recommend trying to review every PR that gets made on your team (provided your team isn’t too large of course). I know I’ve come across PRs that I didn’t fully
understand, but taking those chances to ask clarifying questions is helpful for both your understanding and your teams knowledge sharing. Technical design wise, reading lots of docs written by my team
was the best thing I think I’ve done in my first year of full-time. This allowed me to understand what goes into the technical design process and allowed me to feel more comfortable taking on writing
technical designs myself.
6. Keep it casual
When working remotely, it’s super easy for all of your interactions with your teammates to be based around work and your current projects, as you miss out on the casual conversations with your team over
lunch and during after work activities. These can be added back through coffee chat style 1:1 calls or as a whole team doing game nights or happy hour calls to just chat about non-work things. Although
it can be tempting to just keep focusing on your work, if any of these types of invites reach your inbox make sure to click YES!
7. Flex it out
Lastly, I want to stress that anyone in a remote work situation should not ignore the added flexibility that it can provide to your life. Working while travelling to different locations, having more
flexible work hours to run errands during non-peak times or just saving some extra time in your mornings are all things that I encourage everyone to take advantage of! There’s nothing better than
having full control over how you start your day.
06 Jul 2022
Of the six internships that I completed during my undergrad, five were focused on Android
development. When I was starting university and thinking about what I would like to work
on during my internships, I had planned to try out different tech stacks to get a feel for
what I enjoyed working with the most, as that was the advice I had often heard from upper year
students and people working in the industry. Once I discovered my strong interest in Android
development however, contrary to popular advice, I changed paths to direct my
focus there and it’s a decision that I haven’t regretted since. In this blog post I want to
share some of the unique benefits I’ve found that finding a niche in software engineering
early on gave me in my career.
Depth Can Help Breadth
After getting more deep Android experience I realized that developing depth in one area can
offer a good opportunity to expand the breadth
of your knowledge to adjacent skills. While there are a large range of technical skills that
span over tech stacks (Git, command line, SQL, etc.), the main
breadth benefit I experienced was in non-technical skills, so-called soft skills, such as communication.
One of the things that I wanted to especially focus on improving during my internships (and
still continuing to improve!) was my technical communication. I wanted
to be better able to communicate technical challenges I was facing and offer ideas I had more
clearly to my teammates. Focusing on Android development helped
me a lot in this area as I was able to build up my knowledge and courage to become more
comfortable asking questions and speaking up in meetings. I
found that when I was just starting out in an area, I found it much harder to figure out what
questions I even have, much less figure out how to clearly communicate them to others. Having
more depth of experience in Android development has allowed me to ask deeper questions
and learn the reasons behind some technical decisions that I don’t think I would have been able
to understand (or even have the courage to ask about) had I been less familiar with the
technology I was working with.
Taking on Bigger Projects
Another benefit I found from focusing on Android development was that I was able to take on
bigger and less well-defined projects due to having a better understanding of some of the
complexities that go into developing for Android. From this I was able to gain experience
working on projects with larger impact and learn more about the engineering design process
earlier on in my career. One example of this was having the opportunity to work on integrating
in-app review prompts into Cash App during my internship. This was a highly impactful and
visible feature that exposed me to many things I hadn’t worked with before like external SDK
integrations and the testing and reliability complexities that can create.
The larger scope that these projects came with resulted in many benefits from diving deeper
into the technical details of internal frameworks to meeting new people outside of my team and
expanding my network. Without a strong foundation in Android development, I believe I would have
had a much harder time being able to keep up in these larger projects and deliver the same level
of impact that I was able to achieve in the length of an internship.
Thoughts For The Future
While everyone follows different paths in their careers, that can all lead to wonderful places,
this is the one that worked out for me. I’m really enjoying the current work I’m doing in the Android
space and could see myself continuing it for the foreseeable future. Of course, there is a part of me
that leans towards trying out something new, when the timing is right. Thankfully, there is ample time
try it all, whatever that may be.
14 Oct 2020
This past summer I was an intern on the Android Open Source Project (AOSP) team at Google. This was my first real jump into open source development, previously having just
hosted some of my personal projects on GitHub with no expectation that they would be cloned or used by others. This of course is very different compared to the scale of
engagement that AOSP receives from the Android community. I wanted to write this blogpost to talk about what this open source internship experience taught me about
the benefits of open source software development for me (and other developers), for the software itself and for the development community as a whole.
How Open Source Benefited Me (And Could You as Well!)
As is the case with starting any new role, my internship provided a good opportunity to build my network. The unique benefit that working on open source projects afforded me was
that, in addition to just being able to network within my team and other close teams at Google, I was able to expand my network with some of the external contributors to the
project as well. This expanded network also allowed for a wider range of experiences that I could learn from. While I learned a ton from the members of my team, I also
learned from the external contributors. They taught me things ranging from better testing practices to ways to ensure my code was compatible with older versions of Android that needed to be supported. Open source work is also a very strong
portfolio point, giving contributors the chance to point to public code they have written to showcase their skillset to potential future employers or clients. Being a student just building my brand, this was a big benefit for me.
How Open Source Benefits the Software
Open source software gains many benefits itself from being accessible to the general development community. Firstly, since many developers, with many different past
experiences, can contribute to the code, the quality of the software can be maintained at a higher level. All the different viewpoints the developers bring allows for
things to be noticed that others might have missed or not considered. This also plays a factor in catching issues during code reviews. During my internship there were a few
times where external contributors provided good feedback on my changes during the code review process, which ultimately led to higher quality and more robust code.
Open source development also benefits the community that it is a part of. One way it does this is by allowing the community to have transparency into what
large companies, such as Google, prioritize working on. AOSP provides Android developers the chance to see what work is being done on various Android libraries and the
OS itself much earlier than some of the features may be released. Open source also allows developers the chance to influence the direction that the tools they rely on are
taking. By being able to see the code changes being made, and being able to participate in the code review process, developers can voice their opinions on what features should
be focused on. This can lead to better designed tooling, since the developers who will be the end users can provide feedback earlier on in the development process, instead of
just filing feature requests after launch.
Summary
My experience this past summer working on AOSP at Google has taught me a lot. While I was always interested in open source development, particularly how it fits in to the
Android community, I hadn’t had much experience working with it myself. Now, after getting my first taste of it, I hope to be able to contribute more to the open source ecosystem and encourage everyone else to do the same!