Look at some low hanging fruit in the bug tracking system.
See if there is a knowledge base - if there isn’t perhaps create one as you learn and ask others if you have the right idea. Could be useful for the next newbie in the door.
How to join a team and learn a codebase (2020)
11–20 of 58 posts
Re: How to join a team and learn a codebase (2020)
#123 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…
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.
Re: How to join a team and learn a codebase (2020)
#13Earlier 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…
> they all were entrenched in their own ways and setups.
I consider this a bad behavior. If people espouse the benefits of CI/CD and cattle over pets. Then I firmly believe that thinking needs to make it's way to the dev environment.
And what you did isn't worthless, the next person get's to go quicker and spend effort on features that make money.
Re: How to join a team and learn a codebase (2020)
#14I 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 experienced than you are. Learn from your seniors - it may be hard when you’ve just read about this new “paradigm X which solves all problems” and you believe you are smarter than others - but please try.
Re: How to join a team and learn a codebase (2020)
#15I 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 good
Re: How to join a team and learn a codebase (2020)
#16This is pretty good advice and I'm glad I recently did some of the steps at a new company.
On the setup step I found it very helpful that my team has used scripts to rule them all, so setup was a breeze! I didn't know about that before.
Short explanation: https://github.blog/2015-06-30-scripts-to-rule-them-all
Re: How to join a team and learn a codebase (2020)
#17I 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…
Being retarded enough to shit all over a codebase that you just met means you are a garbage employee who should never have been hired because you're a fucking boat-shaker. So go dickchoke yourself if you think this is reasonable, I have fired people for less than arrogant shit like this.
Btw this is a lightning rod post, anyone who sees this please downvote and report!
Re: How to join a team and learn a codebase (2020)
#18I 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…
Yeah, I find this a huge problem especially with junior devs (by which I mean those within the first five or so years of their career. When you have people calling themselves senior devs after six months the job title has become meaningless). Until you've been around long enough to understand how large code bases (in general, not the one you're working on!) evolve over time and why common trade offs are made you're not going to be able to grok the weaknesses of an existing code base quickly.
Start off by being humble and asking why certain things have been implemented in the way they have, there is usually a reason. Sometimes it's even a good one!
Re: How to join a team and learn a codebase (2020)
#19For someone who is new in the team I would recommend :
1. Try to see what existing functionalities are there and how exactly the code is being executed line by line by putting debug points on the codebase.
2. Try to change the local codebase and see how the changes are affecting the application.
3. Whenever stuck - try your best to find out the errors and search for the solution for the errors present on the console. If facing more difficulty, better take help from seniors.
4. Think of the simplest approach you can use to develop a piece or make a change without affecting much of the codebase.
5. See other projects which uses same technology but with small codebases having same kind of implementation and try to learn the best practices followed also do visit documentation regularly because sometimes all you need is already explained in the simplest way.
Re: How to join a team and learn a codebase (2020)
#20Earlier 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…
Your team sounds a little broken. If a new starter came in and did that for our project, I’d be really pleased.
Once you have that stuff setup, and you’re doing “day to day” coding, it’s hard to find time to go back and sort that stuff out. It’s something a new starter can take on that ultimately gives good long term outcomes.