This is a list I’m going to be maintaining on different ideas and thougths around ramping up on new software projects.
Grasp of existing problems
One component of ramping up on a new project is understanding existing problems. You’ll never find a project without problems. These problems come in all shapes and sizes. They might be code quality issues, they might be slow running tests, they might be style issues on the front-end, they might be architectural issues, whatever they are, you are sure to find problems in any project that’s been around longer than a day.
I find a lot of newer developers are exhausted by this fact or feel it is a bad thing to find problems. I believe it’s the opposite. It’s a sign you’re starting to get a good grasp of the project. What’s important, is to not let the problems overwhelm you and to surface those problems to the rest of the team.
As you ramp up, you’ll typically find yourself in one of these three stages. The final stage is where you want to be at.
Finding and verifying problems
Ramping up on a new project, you’ll find yourself getting aggravated by things in the code or things in the project you’re working on.
As you find problems, you’ll be:
- Verifying it’s a problem - Lots of times, it’s just a misunderstanding, or it’s just something you weren’t aware of
- Document the problem - Jot notes about the problem down somewhere
- Surface the problem to the team - When you’re new to the team, it’s essential that you discuss problems with the larger team. Raising awareness is key even if nothing can be done about those problems.
It’s important to note, at the beginning you will rarely know how to solve these problems. That’s okay.
Finding solutions to those problems
At some point, you’ll have a firm enough grasp on the project to start seeing solutions to the problems you’ve been identifying.
This is very exciting! For the first time, you’re seeing a path to fixing the problems that have been bugging you over the past weeks or months.
As you discover solutions, you should:
- Verify the solution with a more senior team member - If it’s a valid solution, awesome! If not, you probably will learn some key features of the project you’re working on. Both are very valuable.
- Document the solution - Jot down some notes about the potential solution.
- Share the solution with the team - Discuss your potential solution with the broader team.
Important things to remember:
- There are always multiple ‘solutions’ to the same problem - You might solve the problem with documentation. Someone else might suggest changing the code to prevent having to write documentation. Both are valid solutions worth considering.
- Don’t expect your solution to get queued up in the backlog - There are multiple solutions to a single problem. There are multiple problems. We will never fix all the problems. Team members who have been on this project longer likely understand the business context a bit better and will prioritize things in a way that may not make sense to you at this stage. The important thing to do here is to try and understand where your solution might fall on a prioritized list and why it was placed in that priority.
Prioritizing solutions based on business goals and business value
As you continue identifying problems and solutions, eventually, you’ll be able to prioritize them based on your understanding roughly of business goals and how much business value implementing that solution will add.
This is where you start to become an invaluable partner for the business. If you were to visualize your list of solutions in a graph it might look like this:
You’ll always want to be recommending the business support work on the solution that you’ve identified as the highest value for the least effort. When you can rank solutions like this and articulate that value back to the business you’re fully ramped up.