You might find The Professional Employer interesting. Mentally update the technology references as required :)

Read, for example: david.heinemeierhansson.com/2014/… For info, the author of that article wrote Ruby on Rails, and was previously very pro-TDD. There are many, experienced developers who have concerns about the overuse of TDD concepts, and resulting code bloat. It's not a battle of "right" vs "wrong". You either need to figure out a way to meet your boss in the middle, or look for another job, and be clear in the interview that this is important to you.

Generally you don't have to 'try' to use software design patterns, often they just describe the work your doing anyway. Trying to force everything into a fixed pedantic pattern isn't always the best approach. Its more important to make things easy to understand, sometimes formal patterns help that, sometimes they might add unnecessary complexity.

I think your options are either (a) go find a job where your coding practices are embraced, or (b) commit yourself fully to doing the work in the style that the manager asks for in the best way you can, to see if in fact his way isn't so bad.

I am confused. A decorator specifically provides a new interface to an existing interface / implementation, without changing the exiting one. And as such, the decorator is "high level".

Did this manager interview you and select you? There seems to be a considerable gap between the ways you and the manager think to tackle deliverables. If the manager picked you, you are in better position than it might seem.

This is a software engineering answer rather than a workplace answer but: it sounds like you are overengineering. Design patterns are tools that you use when you actually need them to produce the desired behaviour. This is also usually passive and the design pattern is just a handy descriptive label - you write the code that does the thing you need and, hey, look, it's a factory. If it's not happening organically, it's probably unnecessary. Using a design pattern should make your code simpler, not more complex.

Its all about finding the middle way between overengineering and tehchical debt. The question is who is more qualified to do this.

Also be careful to write clean code - if your coworkers cannot understand it, it means it would not pass peer review and you have work to do!

It really sounds to me like you're blindly applying software patterns and practices everywhere and not thinking about the complications that they are adding. This can be worse than not applying patterns or practices at all. Also, I'm pretty sure a lot of the folks giving you advice are engineers. Personally, I've been a developer for over 20 years.

@rexcfnghk - Design Patterns solve SPECIFIC problems, not EVERY problem, and if you are being talked to about it frequently enough that you posted to workplace than you are definitely using them way too much. I maintain that position despite your edit.

I feel compelled to point something out. Your job is not to program, it is to solve problems. I find that a lot of developers exhibit a severe disconnect here. You're programming solutions a certain way because it's the right way. And programmatically, it may very well be. But the business perspective is that your solution should be implemented as quickly as possible, and be as easy to read/maintain by others as possible. You're so focused on being a good programmer, that you're failing to embrace your larger role as a problem solver.

TL;DR but this: "His response is that he finds it confusing having multiple implementations of an interface and he thinks creating a new interface with another name (with the same members) is the way to go." if true indicates your manager is highly confused about interfaces and what they are for.

To be honest, I am quite disappointed to see so many responses with a strong stereotype "Why you engineers can't think like managers" because your job is not to write code, fix code, maintain code, or in any other way deal with code. Your job is to add to revenue or reduce costs. Period. Any other action you take at work (such as those involving code) are epiphenomena: understandable only in the context of the thing that is your actual job. If you cannot justify your opinion about your job in terms of what your actual job is, then your opinion is wrong. If you feel you can justify it,

...(cont) in those terms (and you seem to based on the last paragraph), but your boss disagrees, then you and your boss have a difference of opinion and need to treat it like any other difference of opinion (i.e. he wins and you CYA with a document trail for a hopeful later I-told-you-so). If all of this seems rather harsh, forgive me for having been a manager over people with a very incorrect worldview on these matters.

I reject the concept of untestable code. If you need to change a piece of code that isn't covered by unit tests I recommend that you first write unit tests. Occasionally that means you have to refactor the code a little bit to make it testable.