What helped me in a rather huge Java/Spring codebase with little documentation and little knowledge was running the code locally and using async-profiler to generate flamegraphs for requests to our rest-endpoints - then setting breakpoints in the ide and spending a few hours just following the requests to the code. It's not a good idea to rely on this for a complete understanding but I've remember attempting to read the code class by class before and was unable to get a mental model of it - after doing the flamegraph/stepping in the debugger dance a few days I've started to feel right at home - it also helped me quite a lot to pinpoint further issues.
How to join a team and learn a codebase (2020)
21–30 of 58 posts
Re: How to join a team and learn a codebase (2020)
#22I would recommend that when someone is new in a large project with an older code base, to pay attention and learn from others. A mistake I often see is too many “suggestions for improvement” too early. This behavior, when excessive as it often is, is perceived to be invalidating tough choices that were made before your time and chances are that the people who made the choices had good reasons for it and are more expe…
This is a pretty one-sided take. I think it’s quite possible to lose perspective when working on a large codebase. It’s also possible to have small bits of technical debt accumulate without anyone feeling the total weight of it all. Old code can use whatever fad was most popular when it was written or it can carry the cruft of old dependencies or api changes. Just because something is old it doesn’t mean that it’s go…
Of course. But as a newcomer, you cannot know which one it is, and as the OP said this behaviour has a lot of chances to be perceived as invalidating. I've been on both sides of this situation, and in both cases I felt that it was almost disrespectful, it's sending the message that you don't think the team is competent enough to have considered them and carefully picked trade-offs.
When I was on the receiving side (there was a newcomer to the team doing a lot of "suggestions for improvement"), I made a lot of effort to explain the context that led to a different decision, but it was very draining and rarely the good time for it (it distracts from the conversation), it was really hurting collaboration. Eventually we had a one-to-one in which I explained exactly that, and we found that it would be much better to raise these as "can you tell me why is this one like this" (rather than "improvement suggestion" that can be invalidating), and do it in one-to-one so that it's not distracting. Collaboration was much better after that
For sure, it's great to have a new pair of eyes and you certainly don't want to tell somebody to keep their challenges and suggestion for improvement for themselves. But it doesn't mean that there's no good way or bad way to do it
Re: How to join a team and learn a codebase (2020)
#23I’ve always said the easiest way to learn a code base is to write tests for it.
There’s always a flaky test someone just doesn’t want to fix, or a feature that doesn’t have any tests, or a couple components that don’t have an integration test, etc...
Re: How to join a team and learn a codebase (2020)
#24All 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 a…
it is true but as we all know checklists can help to make sure stuff isn't missed, even for very experienced people, and it is an unmitigatedly good thing for newer developers.
i gave a go at making a cheatsheet of the steps: https://twitter.com/Coding_Career/status/1350445944395821056...
think it's a good guide to follow even if I instinctively do most of it already.
Re: How to join a team and learn a codebase (2020)
#25i really liked this post and made it into a cheatsheet guide: https://twitter.com/Coding_Career/status/1350445944395821056...
thanks to OP for sharing it, its not the kind of thing that gets written down enough but funny enough it is really important to join a team well and nobody teaches how to do it.
Re: How to join a team and learn a codebase (2020)
#26I would recommend that when someone is new in a large project with an older code base, to pay attention and learn from others. A mistake I often see is too many “suggestions for improvement” too early. This behavior, when excessive as it often is, is perceived to be invalidating tough choices that were made before your time and chances are that the people who made the choices had good reasons for it and are more expe…
A good senior would explain the "good reasons". A bad senior would be annoyed that the choices are questioned. As a leader I tell my "apprentices" to always question me what the reason is for doing something. Being in a leadership position is not just about your pupils progress, it's just as much about your own learning. You learn a lot when you have to explain stuff. It can be very humbling when you try to explain in-front of your team, being questioned, and then discover that you where wrong.
Re: How to join a team and learn a codebase (2020)
#27I you really want to understand something, you have to change it. Or at least try hard.
Re: How to join a team and learn a codebase (2020)
#28Go and talk with the people who wrote it. Often times there are a just a handful of people that wrote a lot of the core functionality, they often aren't the most social. Talk to them when you are in the planning phase of implementing something.
Lots of great advice here that I agree with. IMHO though I see a lot of engineers miss on the team and social aspects of coding. Just as important as your tech stack is your team. Have an idea for improving something? That's great, but remember to listen first and learn to love what is great about the way it is. For you it could be X% better for the original authors it is a miracle that they made it work at all and it is important enough to need a bigger team.
Re: How to join a team and learn a codebase (2020)
#29Earlier quoted context omitted.
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…
Indeed, crazy dev setup is definitely like a code smell. I remember at one place, it took me 3 weeks to get to the point where I could merge my first PR. Another place I was at, they handed me a laptop that was already set up to run the code, and all I had to do was set up my own editor. Guess which place I was more productive.
I find that very nice: last arrived on a project (on a similar role) will setup a working environment for the next one to start with. It fresh enough that you remember it, and you could even find interesting to clean up a little.
Re: How to join a team and learn a codebase (2020)
#30Earlier quoted context omitted.
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 jus…
What I've done in the past and worked is as follows
- learn from others what they are doing and why. It may look inefficient but there may be good reasons.
- document everything / make sure your understanding is correct and others can follow your documentation and use the old flow.
- start automating and improving while keeping existing things that worked still there.
Doing things this way I was able to improve processes for very bureaucratic companies and have had people appreciate and put in their time to help once they started using.