Todd,
That's strange you weren't able to find developers in San Diego using .NET. I have heard of C# being used by a lot of companies in San Diego. In fact, at a recent recruiting event I went to: 'Hacker X', it seemed like almost every company recruiting there was recruiting for C# developers.
I would recommend trying to get into open source, or library development. In either case, you may not be able to enforce all of Uncle Bob's teachings, but the code bases will probably be a lot cleaner. The reason open source has to be cleaner is because it is exposed to the world and potentially many developers who don't get paid might contribute. So, you will either be embarrassed by a bad code base, or you will get a lot of tickets to clean up the code, or the project will fail because no one will want to join the project due to it being a mess. You might be wondering why the software industry doesn't have better standards for code. I wondered this for a long time and I think I figured it out and one of the main reasons is quite counterintuitive.
The first thing is that software code is very ethereal and abstract. An almost limitless number of solutions will generate the same result for an end user. Now, you might think that it is the case that you can compare different solutions and compare them in terms of how well they are 'crafted'. You can for some things that are obviously terrible, but the problem of evaluating the craftsmanship of different solutions is too much for many managers in industry to undertake. Most for-profit software organizations saddle their managers with a variety of responsibilities that make doing things like code reviews a much lower priority.
The next problem is the fact that even amongst well-known figures within the software development community (e..g Uncle Bob), there are quite a few disagreements. For instance, one of the big points of contention is TDD. Some, like Uncle Bob are big advocates of TDD, while others such as Rich Hickey (creator of the language Clojure) are not. Managers might fall into one camp or the other, but it's easier for them to not enforce TDD. Bottom line is that it's easier to have no principles/styles and just give a nod of approval to any solution that appears to 'work' than to enforce a particular set of principles on the developers. Of course, then, you end up with code bases where some developers might do TDD, and others don't, and that's fine to the manager as long as a solution 'works'. With no underlying style/principle of development, code bases end up with a hodge-podge of styles/principles, which in my opinion is much worse than a code base that might have a single style that I just happen to disagree with in some areas. Some of this mentality was actually praised among individuals in the Perl hacker community, as an example.
So, many managers in industry have given up trying to enforce good coding practices (or never bothered to in the first place). They just try to get developers to crank out a solution that 'works' (for now), and then react to bad stuff that happens later (bugs, outages, delays in delivering features etc.). The managers are smart enough to know that much of the codebase is bad and many developers would hold up their nose and not want to touch the code...except they get paid to do that. So basically what happens is developers who would normally not touch the festering code bases at a lot of companies, end up working on those codebases because they are getting a paycheck to do so. If a developer quits, the manager knows he can just post a job rec, recruit someone else and pay them to navigate their way through the festering mess to add the next feature. This is the dirty (open) secret of the software industry.
This brings me back to why open source code bases are often much higher quality compared to what you find in proprietary closed-source code bases. One of the advantages of open source is you can get unpaid developers to contribute. But someone who is passionate about a project is less likely to contribute if the code base is a festering mess. They aren't being paid, so they can just quit out. Also, because such a large number of developers from all over might want to contribute, you can't rely nearly as much on tribal knowledge. At a company where there is a relatively small team, Joe can just message Bob a snippet of code that's a workaround for a known bug, or a 'quick and dirty' script to do something that is not checked into the code repo. This just won't fly as much on an open source project with potentially hundreds of contributors. With many contributors who might run into the same problem, bugs/issues either need to be fixed, or documented. Also, almost no open source project is going to skip out on code review. Merge requests are almost certainly going to be reviewed by the project leads, and probably others.
Steven