How to join a team and learn a codebase (2020)

Re:How to join a team and learn a codebase (2020) by dan-robertson on Saturday January 16, 2021 @06:48AM (#25801662)

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 good

[ Parent | on HN ]

Re:How to join a team and learn a codebase (2020) by williamdclt on Saturday January 16, 2021 @08:39AM (#25802094)

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

[ Parent | on HN ]

Re:How to join a team and learn a codebase (2020) by theptip on Saturday January 16, 2021 @02:35PM (#25804763)

I typically advise new hires to keep a “dirt doc” of things they think could be improved, and have them come back to it after they are more up to speed (say a month or two in).

The insights that you get from coming at the problem with fresh eyes are invaluable and you really don’t want to waste those. But many things on that list will evaporate once you have a bit more understanding of the project.

(I still like to make “check in a fix / improvement to the dev environment documentation” the first task for a new starter though, as there’s usually a typo or update required somewhere).

[ Parent | on HN ]