How to join a team and learn a codebase (2020)
samueltaylor.org
How to join a team and learn a codebase (2020)
1–10 of 58 posts
Re: How to join a team and learn a codebase (2020)
#2All of this is true. To me this article mostly reads like 'water is wet'. What one often sees, though, is that younger developers often have the idea that they need to read through portions of the code as a step of getting into it. I am not really sure that it is a helpful step for all but the smallest code bases. It is often more helpful to start with a user story and then try to find out what portions of the code apply to that.
Re: How to join a team and learn a codebase (2020)
#3> The rule of thumb I use is to understand something just enough to express what it does without necessarily knowing exactly how it does that. This process is called "chunking," and it relies on the fact that once you have a basic understanding of a unit of code, "you don't need to remember all the little underlying details" (Oakley).
Isn't this how a lot of non-math majors learn math at uni? You learn how to use it, but you don't learn the proofs behind it? When I dove into a first codebase, I took the above said approach because that's how I learned (most) math.
A younger me would've find the Tools section valuable.
Re: How to join a team and learn a codebase (2020)
#4I think I found the pony: do lots of little experiments to test your understanding of the code. The value of software is not in the bytes of the library/executable or even the source code. It is in having people working for your company who have a mental model of it in their head.
Re: How to join a team and learn a codebase (2020)
#53 things that helped me become productive on new codebase faster
1. Start with a goal to fix a tiny issue. It will help you not go too deep, too early and yet give you an overview of the codebase.
2. Document the steps to setup dev environment in your own words and highlight the issues that you run into
3. Take time to learn the new Library or the tooling you encounter. Learn with the goal of familiarise yourself with the keywords/concepts of that library or the tools. It's okay even if you don't understand exactly how they work. When you really need to understand to solve a problem or a piece of code, you can use the keywords to quickly go to exact documentation references to learn more. A thumb of rule for me is to not invest more than a day to learn these new concept continuously(I can always come back to it if I see the need for that)
Re: How to join a team and learn a codebase (2020)
#6> The rule of thumb I use is to understand something just enough to express what it does without necessarily knowing exactly how it does that. This process is called "chunking," and it relies on the fact that once you have a basic understanding of a unit of code, "you don't need to remember all the little underlying details" (Oakley). Isn't this how a lot of non-math majors learn math at uni? You learn how to use it,…
> You learn how to use it, but you don't learn the proofs behind it?
Which makes sense, at least firstly, considering that understanding a proof is a lot easier when its conclusion is already familiar.
Re: How to join a team and learn a codebase (2020)
#7> The rule of thumb I use is to understand something just enough to express what it does without necessarily knowing exactly how it does that. This process is called "chunking," and it relies on the fact that once you have a basic understanding of a unit of code, "you don't need to remember all the little underlying details" (Oakley). Isn't this how a lot of non-math majors learn math at uni? You learn how to use it,…
Oakley emphasises that understanding is an important part of chunking. Chunking is not the same as root learning without understanding. More that when you familiar enough with a concept you don’t have to think of all the details of it, but can treat it as a unit.
Re: How to join a team and learn a codebase (2020)
#8The text on this blog needs more line height. I find myself tracing lines in order to read.
Re: How to join a team and learn a codebase (2020)
#93 things that helped me become productive on new codebase faster 1. Start with a goal to fix a tiny issue. It will help you not go too deep, too early and yet give you an overview of the codebase. 2. Document the steps to setup dev environment in your own words and highlight the issues that you run into 3. Take time to learn the new Library or the tooling you encounter. Learn with the goal of familiarise yourself wit…
2. Document the steps to setup dev environment in your own words and highlight the issues that you run into
This is the most significant thing for me getting up to speed on a new or old project. I absolutely hate reading some whacky custom dependency, jboss, hell like project setups. They just kill morale. And I feel really bad when I see new starters wade into the tall grass on this stuff. I can almost see the moment they go to lunch and start thinking about quitting tech.
My personal reaction to being given really bad 'quick start' doco so many times, is to try and leave every project I work on in a state where "mvn clean install" will do everything needed to get things running.
You may join a team, but your team is also getting a new member. They should be working HARD to make you productive asap, and crazy dev setup is like a code smell.
Re: How to join a team and learn a codebase (2020)
#103 things that helped me become productive on new codebase faster 1. Start with a goal to fix a tiny issue. It will help you not go too deep, too early and yet give you an overview of the codebase. 2. Document the steps to setup dev environment in your own words and highlight the issues that you run into 3. Take time to learn the new Library or the tooling you encounter. Learn with the goal of familiarise yourself wit…
2. Document the steps to setup dev environment in your own words and highlight the issues that you run into This is the most significant thing for me getting up to speed on a new or old project. I absolutely hate reading some whacky custom dependency, jboss, hell like project setups. They just kill morale. And I feel really bad when I see new starters wade into the tall grass on this stuff. I can almost see the momen…
I recently joined a new team and codebase.
There was no 'getting started', no docs. I was left on my own. So I muddled through. And documented everything in Makefiles. Not readme, but working code. Now `make clean` `make install` etc, all run, deploy, install, clean etc the project.
A great way to learn. But unfortunately worthless to others in the team, as they all were entrenched in their own ways and setups. I just added a sixth' way of 'working with the codebase'. I'm no to sure if it is the team, me, or Make, but I certainly won't spend such time a next new codebase arrives.
(I do add makefiles on each of my private and opensource projects though, and will keep doing that)