这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
计算机科学或其他IT领域的学位确实会让你成为一个更全面的程序员
我不在乎你有多少年的工作经验，读过多少博客，参与过多少开源项目。一个资格证书(我建议超过3年)会让你接触到一种不同的思维方式，给你一个很好的基础。
仅仅因为你写了一些比计算机科学学士更好的代码，并不意味着你比他更好。你所拥有的，他可以在瞬间学会反之则不然。
拥有资格证书表明了你的承诺，你会超越经验，成为一名更好的开发人员。擅长自己的工作并且有资格的开发人员可能会非常令人生畏。
如果这个答案被否决，我也不会感到惊讶。
而且，一旦你有了资格，你就会慢慢停止和其他有资格的人比较(我的经验)。你意识到到最后一切都不重要了，只要你们能很好地合作。
始终仁慈地对待其他开发人员，无论其资格如何。
其他回答
设计模式是石器时代编程语言设计的一个症状
他们有自己的目的。很多优秀的软件都是用它们开发出来的。但事实上，我们需要编写这些心理抽象的“配方”，关于你的代码如何工作/应该如何工作，这说明缺乏足够有表现力的编程语言来为我们处理这种抽象。
补救措施，我认为，在于允许你将越来越多的设计嵌入到代码中的语言，通过定义可能不存在或可能没有普遍适用性，但在你的代码不断处理的情况下真的真的有意义的语言结构。Scheme的人已经知道这一点很多年了，Scheme宏可能会让大多数猴子尿裤子。
递归最糟糕的地方就是递归。
成员变量不应该声明为private(在java中)
如果你声明了一些私有的东西，你就阻止了任何未来的开发人员从你的类派生和扩展功能。从本质上讲，通过编写“private”，您暗示您现在比任何未来的开发人员都更了解如何使用您的类。当你写“private”的时候，你应该写“protected”。
类永远不应该声明为final(在java中)
类似地，如果您将一个类声明为final(这将阻止它被扩展—阻止它被用作继承的基类)，那么您就意味着您比任何未来的程序员都更了解使用类的正确方法。这从来不是个好主意。你不是什么都知道。有人可能会提出一个完全合适的方法来扩展你没有想到的类。
Java bean是一个糟糕的想法。
java bean约定——将所有成员声明为private，然后为每个成员编写get()和set()方法——迫使程序员在不需要代码的地方编写样板、容易出错、冗长的代码。只要将public成员变量设为public!如果您需要更改实现，请相信您以后有能力更改它(提示:99%的情况下，您永远不会更改)。
库克的格言随意收集……
The hardest language to learn is your second. The hardest OS to learn is your second one - especially if your first was an IBM mainframe. Once you've learned several seemingly different languages, you finally realize that all programming languages are the same - just minor differences in syntax. Although one can be quite productive and marketable without having learned any assembly, no one will ever have a visceral understanding of computing without it. Debuggers are the final refuge for programmers who don't really know what they're doing in the first place. No OS will ever be stable if it doesn't make use of hardware memory management. Low level systems programming is much, much easier than applications programming. The programmer who has a favorite language is just playing. Write the User's Guide FIRST! Policy and procedure are intended for those who lack the initiative to perform otherwise. (The Contractor's Creed): Tell'em what they need. Give'em what they want. Make sure the check clears. If you don't find programming fun, get out of it or accept that although you may make a living at it, you'll never be more than average. Just as the old farts have to learn the .NET method names, you'll have to learn the library calls. But there's nothing new there. The life of a programmer is one of constantly adapting to different environments, and the more tools you have hung on your belt, the more versatile and marketable you'll be. You may piddle around a bit with little code chunks near the beginning to try out some ideas, but, in general, one doesn't start coding in earnest until you KNOW how the whole program or app is going to be layed out, and you KNOW that the whole thing is going to work EXACTLY as advertised. For most projects with at least some degree of complexity, I generally end up spending 60 to 70 percent of the time up front just percolating ideas. Understand that programming has little to do with language and everything to do with algorithm. All of those nifty geegaws with memorable acronyms that folks have come up with over the years are just different ways of skinning the implementation cat. When you strip away all the OOPiness, RADology, Development Methodology 37, and Best Practice 42, you still have to deal with the basic building blocks of: assignments conditionals iterations control flow I/O
一旦你能真正地把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型 一个恒星核心，或者一个约会日历。
初级程序员处理小块代码。随着经验的积累， 他们处理越来越大的代码块。 随着经验的增加，他们开始处理小块代码。
两个人的想法比一个人的好
我坚信结对编程是提高代码质量和编程效率的首要因素。不幸的是，对于那些认为“更多人手=>更多代码=> $$$!”
