2

My team is pretty small right now. It's myself and two other guys. One lead, who's been here for five years. A senior who we brought on 2 weeks ago. And me, a regular app dev. The lead put his two weeks in last week and has been trying to brain dump as much as he can onto us.

I've been building a list of prioritization to compensate for when he leaves based on what he was saying was the most important. This list has gotten pretty massive after reviewing most of the processes in place.

I was hired mainly to quell new requests coming in and not to maintain our systems, so that's what I did. I didn't examine our prod code base too closely. I wish I had. It's in a sorry state. I'm pretty sure I have about 2 years of tech debt for a crew of two guys constantly working on it.

I've been trying to prioritize based on what gets the most bug fixes and change requests. These apps will see the biggest changes and will undergo the most maintenance.

Since I'm just a regular app dev it feels weird trying to come up with this and try to prioritize this and come up with a plan. It feels like someone else should have. If it needs done then I guess it needs done. I need to be able to collaborate and work with my co worker and be able to plan for what projects are coming next.

If anyone has any suggestions to tackle tech debt please make them. Or if there's any help for managing priorities in a different manner that may prove helpful I'm open. Honestly, I don't want to tackle this completely blind, it feels like a lot.

Comments
  • 1
    Clone it into a lower environment and test it. I find that people who pass on knowledge by explaining the process rarely remember how their code really works. It's better to find those loopholes before he's gone. Going through the code, testing, and "experiencing" the process yourself instead of just accepting what he says will help you understand the whole thing better. If not, you can ask for clarifications.

    When that happens, this "regular app dev" feeling will go away because you will feel more involved with the codebase and believe me, you will find something you'd want to change or improve. There's always something. The priorities can come up after that.
  • 1
    @rutee07 So in tandem with doing all this priotization. I've actually been doing something like what you're saying but on the main project that sees a ton of maintenance. You're super correct, he doesn't remember where 90% of his codebase is coming from or how it works, I've tried keeping him engaged but he just disregards it at this point.

    I'm currently working in our dev environment and have a few things to fix before upgrading to prod. The last developer at work also suggest partitioning the work I plan to do on this monolith into small chunks and pushing out stuff like a layering update piece by piece. I feel like that has some really good merit and could get me off on a good foot.

    There's still some stuff I don't fully understand about the big project but I'll be able to figure it out come next week when he's gone. Thanks for your insight man.
Add Comment