What do you do if you come across code you haven’t worked on?
I’ve been in many situations where ownership of a system is in question. Fixing a bug, documenting a system, or deciding the future direction of a product.
My career advice to engineers wishing to grow is if you don’t know who the owner is, you step in and take over. You will always find uncontested territory in code. The engineering team is better off if you enter that area and understand the quirks and nuances.
I’ve worked on multi-team projects cracks in ownership appear. I take the initiative to meet the other team on the other side. Reading code is painful and I incur a heavy time cost but we don’t waste time debating who should work on what. We would enter a lose-lose situation. Engineering gains no productivity if both teams are arguing over who should examine the code for a week. I’d rather spend that week reading the code.
If code truly belongs on another team’s end, I am okay with that. Think of the other teams – if you document an unknown system, you now have context. You can later transfer knowledge to another team. Code in that region gains +1 to the bus factor because of you.
Product and engineering boundaries don’t match team descriptions perfectly. Engineering groups often share the same codebase and from my experience, you can’t always split ownership at the file level. Classes and functions are intertwined with multiple engineers contributing to every line. When engineers leave or move to another team, gaps of ownership appear.
If you want to become a senior engineer or if you want to continue your career growth, be the one who steps over the imagined boundaries. Extend through the unknown codebase to avoid wasting time and help the organization.
Leave a Reply