I have no problem for a single person owning a specific component of the codebase assuming he adhere with a set of policy regarding code style, best practices,

I have no problem for a single person owning a specific component of the codebase assuming he adhere with a set of policy regarding code style, best practices, etc. The problem here is that in most companies, other than the big guys (MS, Google) that have smart developers along with good policies, the single owner usually take hostage and write bad code that nobody wants to touch. You can debate this night and day if you will. Google is famous for having a very strict rule: pass your specific programming language policy exam then you can write code and commit to Google main repository using that language. I wish more companies have this type of policy. No argument against those forming/storming/norming/performing, non-issue, just a nice footnote. Again, TDD useful or not? Here's the thing: many people prefer to write features and not unit-test. It's psychological. Features = you're a hero. Unit-test = grunt work. Many people would try their best to look for excuses to write less unit-tests. You'll often hear the "as needed", "as efficient as possible", "the least amount of work" when it comes to unit-test. But when it comes to features, oh boy, you'll hear the big words "patterns", "architecture designs", "design decisions" and all the bullshit. For the record, I don't care if you do TDD or test-last as long as your implementation is testable. Of course the problem here is that most of the time, their code isn't testable. Lots of hard dependencies against 3rd-party web-services, hard dependencies with GUI widgets, hard dependencies against the server, unable to mock the crap out of the DB, etc. Suddenly you'll hear tons of excuses why we can't write unit-test. "Oh, we have to refactor and it'll cost X days". Management doesn't want to hear that. This is why some people made a strong stance of TDD or die. Because most developers just simply behaving like cats; they do whatever they want. Hence the phrase "Herding Cats", "Herding Developers". In a team where the people know and have experienced this kind of pain, they probably won't do TDD but will do test-last. But since we have no friggin standards at all, how do you know what team you'll be in unless you've been with them for a while or have done some sort of 1 day bootcamp? So the choice here in many places out there is either you'll have unit-test or no test at all. The in-between places are very very rare. Sure, I agree that calling non-TDD is unprofessional is harsh. Bad uncle Bob, bad. But then again, perhaps his target audience is those developers lazy-ass developers who think they're a rockstar (many developers think that way about themselves: Dev is king). If you tell lazy-ass developers that "well, test-last is fine as long as your code testable", they have a different filter in their ear: "Oh let's just write the implementation first and figure out testing last". Suddenly you hit the deadline and you'll hear the excuse again "I have no time to write test, here's my work" (and realize that it is not testable). What other choice other than draw a line and call "To not TDD is unprofessional". Once writing unit-tests become a habit, you can always inform them the latter (test-last is fine as long as...) Start with the highest level of discipline and relax them as you go. Spending extra time to enhance your skill is not something new. Other people said something along the line of you should contribute to open source software and whatnot. It's not a bad advise and you shouldn't follow them ad-hoc. You could spend 10 hours for all I care but if your skill stuck and you can't get better then we will find someone else better. The last one is probably not a good suggestion (regarding jumping your superior). Sure, you can make an argument that certain "opinions" are not well-suited in general just like everything else out there. But that doesn't make him a very very bad guy.