I think we should first of all design for functionality, and to be able to deliver this functionality on a regular base, we should also focus on readability and maintainability. Code that is too clean can be a fault in design, it can also be the misuse of a design pattern, or a lot of things for that matter. And a lot depends on interpretation. If you'd ask me a while ago to define you what I think design patterns are, I would have said something like; Their proven solutions for reoccurring problems. This is translatable to, if you face this problem, use this pattern because it is the best way to solve it. If you'd ask me the same question now I'd say; Their proven solutions that could help you solve reoccurring problems. Do you see the subtle difference? What I want to say with this, and all the things we use as guidelines, best practices, how to's and what not, these should trigger your own thought process, not just tell you how to do it. Coming back to the rooms, you are living in the code base with several people, and you have to figure out what works best for all those people, not just implement what outsiders say, because they don't have to live there.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.