Well I make my own rules...
It's actual a fine balance. I totally get that devs want to develop their own code (got the T-shirt) and often that is necessary. But many devs are reluctant to use other ppls code base. And rightly so in many cases. Most in-house standards and patterns are not documented properly. Nor is the new dev trained and inducted into the existing code base. This is the company's fault.
If you have a person that is responsible for overall software architecture and he has a clear view of where development efforts are heading/supposed to be headed, then it is recommended (to be expected) to follow that path. If, for example, the new system you are developing will need code that the architect knows will be reused at a later date on another project, then it will be prudent to design/develop/test it in such a way to enable another team to use it. This is actually crucial to improve overall company and team efficiency. See it as an investment the company is making into its intellectual property.
Technical debt does not imply code that is badly written (buggy). Technical debt is also code and software components that is not extensible/maintainable/testable/supportable. I view code developed with a once-off mindset as technical debt because it is mostly at a dead end. And we all know what happens to code and systems at a technical dead end.
Where there are established in-house patterns and a properly designed re-usable code base, that is definitely the way to go and to be encouraged. I would rather an employee use proven code than develop something similar from scratch. Not only is it better from a time point of view to reuse, but also from a quality point of view. Assuming that the existing stuff is properly done obviously. E.g. follows SOLID/ whatever else standards.
Lets say we need to develop a CRUD type application. Instead of doing everything from scratch, rather use the in-house existing generics based code base. Not only talking about persistence. I am talking about persistence/domain objects/services layer/viewmodel. The whole stack. If the code base has been proven out in the wild then it makes sense to use it. Rather have the dev focus on the domain than on the nitty gritty for loops etc.
Also for example talking to a serial port. The .NET framework class is only a part of what you actually need to do it correctly. Reuse the existing in-house framework around the SerialPort than to do all the (difficult) threading stuff yourself.
