Maximum PC

This is true of procedural and functional programming as well. If a function doesn't perform as expected, it is violating a 'contract' with the user.

I like your point about algorithmic code needing more unit tests. Often the problem bad programmers have with writing a unit test is their algorithms are surrounded by three layers of other stuff. The focus in most companies is so oriented towards a top-down design, often used for budgeting, that the programmers fail to think about any of the bottom-up design aspects, hence they never break down their modules to the 'atomic level' of a unit where code is easily tested. Typically, they also never have internal libraries (90% of the teams that I have worked with). They just copy and paste the same crap code over and over ad infintum.

[offtopic]BTW, I'm officially gonna recommend TopCoder to any newbie wanting to learn a language.[/offtopic]

What you described above was my time at JPMorgan Chase.

I always struggled comprehending developers. When I came out of college, I knew all these algorithmic stuff but not patterns...in the real world (at least at Chase), they told me that the Pattern gods would hate me if I didn't include at least one pattern in my code.

I never really learned patterns, I don't really implement them in my code base but my obsession to decouple everything stems from creating simple objects. Less is more, I say. It's easier to test and mock decoupled objects. I prefer to test behavior and making sure that my objects do as they're supposed too.

One of the Rails philosophies is DRY code (Don't Repeat Yourself). I wrote an internal library at work, and it's tested. All of my active directory libraries? tested. My object extension methods? tested. I have more faith in my libraries because I've tested these systems. If I make a change, it's tested. Bugs are tested as well.

I test the behavior of objects since it makes logical sense. There are aspects of my library that are algorithmic (i.e., I use a BST algorithm to search for individuals in my AD library), so I try to test those granularly.

I haven't taken a course that really covered design patterns in depth either. I basically learned a handful of them on my own, during my free time, while working at Boeing. I found one of the biggest benefit of the patterns to be they allowed me to get away with documenting a design less verbosely. We didn't really do any real UML diagramming, so the patterns helped in that regard as well. I'm always amazed by the people who advocate design patterns, yet fail to create their own library, they obviously missed the whole "reusable part" of the book!

One of the architects I worked with was pattern obsessed. Everything had to have a pattern in it, forgoing the fact that the stuff they built before I arrived were complex implementations of a simple problem. I like patterns because it does allow for less verbiage in documentation but a reusable library carries more value than patterns. I do think that behavioral patterns have the most amount of value. I use the Null object pattern religiously - especially since I use a lot of POCO (Plain Old CLR Object) in my code.