The reason you're depending on this verbose logging is that you need to be able to make sense of the flow of the code. Therefore, the flow must logically be very complex and/or cluttered without this logging, otherwise you wouldn't be advocating for having it.

The TL's advice stems from not cluttering the code flow to begin with, instead opting for code that is self-documenting, readable, clean and loosely coupled in a way thay it consists of esily digestible chunks and does not require some complex big picture in order to understand what is going on.

In other words, the TL would be working in a codebase that precludes the problem you're trying to solve with your verbose logging.
You only really need to log what happens at the boundary between the unmanaged (end users, external systems) and your codebase. Within your codebase, you shouldn't be relying on runtime logging to make sense of your code, because that means you've written code that does not make sense and has not been vetted yet.

Your codebase may have gotten to a stage where the TL's advice, while correct, may no longer be applicable if you're no longer able to unclutter your code in a reasonable timeframe.

I can't know for sure, but the TL might be brushing off your requests for further discussion because he's aware that the amount of rework needed is impossible or would not be signed off on by management, rendering any further discussion on the topic moot (for the current project).

But if we are talking about a new project that is still to be written, I would very much listen to the TL's advice on how to approach the design of your codebase.

The reason you're depending on this verbose logging is that you need to be able to make sense of the flow of the code. Therefore, the flow must logically be very complex and/or cluttered without this logging, otherwise you wouldn't be advocating for having it.

The TL's advice stems from not cluttering the code flow to begin with, instead opting for code that is self-documenting, readable, clean and loosely coupled in a way thay it consists of esily digestible chunks and does not require some complex big picture in order to understand what is going on.

I cannot reasonably give you a concrete answer on what you need to fix in your codebase as I (a) don't know your code, (b) don't know your requirements, and (c) this could span the entirety of clean coding practices, which is a massive topic in and of itself.

In other words, the TL would be working in a codebase that precludes the problem you're trying to solve with your verbose logging.
You only really need to log what happens at the boundary between the unmanaged (end users, external systems) and your codebase. Within your codebase, you shouldn't be relying on runtime logging to make sense of your code, because that means you've written code that does not make sense and has not been vetted yet.

Your codebase may have gotten to a stage where the TL's advice, while correct, may no longer be applicable if you're no longer able to unclutter your code in a reasonable timeframe.

I can't know for sure, but the TL might be brushing off your requests for further discussion because he's aware that the amount of rework needed is impossible or would not be signed off on by management, rendering any further discussion on the topic moot (for the current project).

But if we are talking about a new project that is still to be written, I would very much listen to the TL's advice on how to approach the design of your codebase.

The reason you're depending on this verbose logging is that you need to be able to make sense of the flow of the code. Therefore, the flow must logically be very complex and/or cluttered without this logging, otherwise you wouldn't be advocating for having it.

The TL's advice stems from not cluttering the code flow to begin with, instead opting for code that is self-documenting, readable, clean and loosely coupled in a way thay it consists of esily digestible chunks and does not require some complex big picture in order to understand what is going on.

In other words, the TL would be working in a codebase that precludes the problem you're trying to solve with your verbose logging.

Your codebase may have gotten to a stage where the TL's advice, while correct, may no longer be applicable if you're no longer able to unclutter your code in a reasonable timeframe.

But if we are talking about a new project that is still to be written, I would very much listen to the TL's advice on how to approach the design of your codebase.

The reason you're depending on this verbose logging is that you need to be able to make sense of the flow of the code. Therefore, the flow must logically be very complex and/or cluttered without this logging, otherwise you wouldn't be advocating for having it.

The TL's advice stems from not cluttering the code flow to begin with, instead opting for code that is self-documenting, readable, clean and loosely coupled in a way thay it consists of esily digestible chunks and does not require some complex big picture in order to understand what is going on.

In other words, the TL would be working in a codebase that precludes the problem you're trying to solve with your verbose logging.
You only really need to log what happens at the boundary between the unmanaged (end users, external systems) and your codebase. Within your codebase, you shouldn't be relying on runtime logging to make sense of your code, because that means you've written code that does not make sense and has not been vetted yet.

Your codebase may have gotten to a stage where the TL's advice, while correct, may no longer be applicable if you're no longer able to unclutter your code in a reasonable timeframe.

I can't know for sure, but the TL might be brushing off your requests for further discussion because he's aware that the amount of rework needed is impossible or would not be signed off on by management, rendering any further discussion on the topic moot (for the current project).

But if we are talking about a new project that is still to be written, I would very much listen to the TL's advice on how to approach the design of your codebase.