Kiran — first of all congratulations on your new role! While the world is certainly a challenging place right now I wish you success with your new team.

My first thought is that the article (7 Things) was written from a perspective of both what I attempt to do for new people as well as the ideal environment I would want to be in if I were to step into a new role. However, each team and circumstance is different.

You are the new person. Even the most amazing team in existence will struggle to give equal weight to everything you give to the team until you are fully settled into your groove in that group. The best teams will look at you and your skills, opinions, and ideas as a bonus. You bring a fresh perspective. Your new eyes may see things in a way that the entrenched people never thought of before. That is a very powerful perspective.

Unfortunately, the time for this “settling in” period varies from team to team and company to company.

However — you bring up a really awesome point. You are very much correct in that at some point you will accept existing tech debt as the norm. I actually have had an idea for an article around tech debt for some time and this question allows me to explore a few facets of this topic. You see, I want to write a believable article on the premise that “tech debt” doesn’t really exist and is more of a concept than an actual piling up of old code.

At the risk of going on a long-winded rant here about this topic, in short — no code is ever perfect. I do not believe it is ever possible to write the perfect piece of code that everyone who sees it agrees that it is perfect and there is no way to improve upon it in any other way, or, that there is no way to improve readability in some way through refactoring if for no other reason than to convert the tabs to spaces (or vice versa).

Therefore — we as Engineers always release code that isn’t perfect. Instead we release code that is simply “good enough”. Then we move on. Time, business, and other constraints always interfere from getting it just right. And even if you have the time and space to get it “just right” — when you look at it a year later with another 365 days of experience under your belt I would be shocked if you didn’t immediately see some ways of improving things.

Therefore — I would encourage you to think through what you see as tech debt. Could it be made better? Sure. And that statement is true whether entrenched people on the team want to agree or not. Just remember that you are coming in and looking at production code that is live and functioning. Remember that no developer ever sets out to write bad code. They either get it to “just right” for their ability at that point in time or they ran out of time and pushed out something that is “good enough”.

I feel your pain here. As an Engineering Manager I have a LOT of code that I am responsible for that I would love to get refactored or rebuilt in a different language or codebase. But if I have a new person on the team coming in and telling me that all this old code is crap and is massive tech debt then while I might agree with part of that message - know that that approach would rub me the wrong way. It would also rub a lot of people on the team the wrong way as well.

You see we know three things here that are very important. One — we wrote it so we know just how good or bad it is and we know how much cruft is building every day that we don’t touch it. Two — this code is live and working for our customers, so if it isn’t broke don’t touch it. Three — we have a whole new set of projects and products to make and while going back and reworking some pieces would make our lives easier down the road, chances are the organization isn’t going to give us the time to do this.

So let me close by telling you what message I would give you if you were one week into your time with my team and we were doing a 1-on-1 and this topic came up:

I want fresh ideas. I want new eyes looking at things. But I don’t want you stepping on toes of the people here and getting off on the wrong foot. Start conversations. Ask why things are the way that they are. Ask what you have time and room to explore and refactor. In short — ask instead of tell when it comes to tech debt. If we have that room in our roadmap and current timelines to tackle some of this then great! But let’s do it together. There might be some even bigger tech debt that you haven’t seen yet that we can help point out that would give even more bang for the buck in addressing.

At least — that is my long-winded take on this topic. Remember — you are there and I am not so your situation may be very different than what I am envisioning! Good luck! Thank you very much for the comment and for reading the article!