chuckm

Looks like there are a few positions: http://www.google.com/about/jobs/search/#q=%22architect%22&#...

Straight off the bat the most glaring problem with that statement is that Linq is not part of C#

Parts of it are. Query expression keywords[1] are defined in the C# 3.0 Language Specification (see 7.15 Query expressions)[2].

[1] http://msdn.microsoft.com/en-us/library/bb310804.aspx

[2] http://www.microsoft.com/downloads/details.aspx?FamilyID=dfb...

"TDD is clearly not a cure all"

Who said it was?

A lot their "training" seem designed to weed out those who lack specific innate traits

I don't think it's entirely about innate traits. There's a lot of training that occurs before going to some these schools. For example, in the Army you're not eligible to 'try out' for Special Forces until you're an E4 grade (not sure about officers), which may take 1.5 - 3 years to achieve, assuming you enlisted as an E1. Even then a lot of guys spend 2-4 months in special training programs before going and some don't pass until their second or third attempt.

Unfortunately the writer makes it seem like all Asp.net developers use just the visual designer and the pre-made tools.

How did you reach this conclusion? I don't see any mention of the visual designer or pre-made tools in this article.

I agree with this article; the abstraction sucks and the framework gets in your way more than it should.

It seems like you're still using some form of automation to find bugs, regardless of whether these would be classified as unit tests, correct?

I’ve never seen Kent Beck as a crazy rules person. I think his comment from stackoverflow demonstrates this:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

http://stackoverflow.com/questions/153234/how-deep-are-your-...

I disagree. I think comments are often overused but I'm not convinced that code and tests are expressive enough to always convey why functionality exists.

For example, sometimes limitations in third party dependencies force you into adding additional code that might look out of place or redundant. In cases like this it can be hard to capture why this code was introduced without using a comment.