31–40 of 58 posts
For me, the best way to join a codebase without a doubt is to actually just use the product first. What good is looking at the code if you have no idea what the product is even supposed to do?
This doesn't have to be in-depth knowledge, but just go through the setup of your product, do a few happy path use cases, feel what it's like to actually use the thing you're about to develop.
Go 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 t…
Earlier quoted context omitted.
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.
Part of it is probably that I fixed something that wasn't broken for them personally.
I understand than when a new person joins and starts telling you that you should now start using this "new", "Makefile" thing, you'd probably be annoyed and get back to work instead.
3 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…
This is also a project management issue. Too many times, PMs or tech leads are not at all technical and have little to no comprehension of the complex environments they oversee nor “technical empathy” for the engineers. It matters not to them what can empower a developer or make them more productive, and too often devs are told “you’re a developer, you should be able to figure it out” or “just use the tools we gave you”. Some of this does come from heightened and constantly changing security requirements that everyone is expected to blindly implement, but there is also an inherent laziness where leadership doesn’t consider what those kinds of changes mean for everyone involved.
Many, many projects needlessly waste ridiculous amounts of time and money on these issues.
Earlier quoted context omitted.
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.
I wonder why no one has not mentioned tests. For me, the tests are more valuable for system or service understanding than, for example, documentation. But the best scenario when you combine tests and documentation. I have joined the new team recently. They have a lot of e2e BDD tests implemented using the Cucumber framework. It helps me to get a complete view of the system in the shortest possible time.
3 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…
Usually a team with a good lead will have a bug that’s not too hard, and will help the newcomer learn the codebase.
It’s easier to learn something when there’s a purpose than in the abstract. And a quick win is motivating.
For more senior developers, assigning a simple feature addition is another option. Eg, having a front end developer add a filter option to some search panel in an application. It may require some UI work, which has the added benefit of getting one involved with people on the UX side — helping to onboard in a team sense. It also may involve some server communication components. Either way, like Muir said — tug on one tiny leaf and you’ll find it is connected to all of nature. (Or something like that.) Similarly, investigate a bug or new feature and you’ll find it brings you through a large portion of the app’s infrastructure.
- get a demo of the system. Not from a developer but from a user/sales.
- Understand the team objectives and goals on the high level.
- Ask your team lead what small project you can do to get your feet wet in the system without an overwhelm.
- get that first thing all the way out to prod so you learn what that's really like and what it takes.
3 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…
I just joined a new team as a lead and #2 is killing me, to the point where I have felt like giving up. The documentation my team was given was a hastily thrown-together hack that was full of missing and incorrect steps. It should not take more than a few days to set up a local development environment, but I’ve had to fight for admin rights, ask a million questions, and have other leads work with me for days on end (…
In a small enough place, I usually will just fix whatever is slowest and most annoying about it myself.
At bigger places... good luck. Sometimes you can get away with hacking together some scripts that do things for your personal setup, but if there isn't buy in to fix the problem you're often out of luck.