用户不是傻瓜——你才是。

很多次我听到开发者说“某某人是个白痴”，我的回答通常是“他可能是个白痴，但你允许他这么做。”

大多数程序员都不擅长编程

(你刚才说“有争议”)

我坐在家里的办公室里思考一些编程问题，最后我看着书架上的“完整的频谱ROM拆卸”，心想:

“现在有多少程序员能写出Spectrum ROM中使用的代码?”

Spectrum，对于那些不熟悉它的人来说，有一个基本的编程语言，可以在16K的Z80代码(一个< 5Mhz的8位处理器，没有FPU或整数乘)中完成简单的2D图形(线，曲线)，文件IO排序和浮点计算，包括传递函数。今天的大多数毕业生都很难编写一个这么小的“Hello World”程序。

我认为问题在于，能够做到这一点的程序员的绝对数量几乎没有变化，但作为一个百分比，它正在迅速接近于零。这意味着，随着越来越多不合格的程序员进入这个领域，所编写的代码的质量正在下降。

Where I'm currently working, there are seven programmers including myself. Of these, I'm the only one who keeps up-to-date by reading blogs, books, this site, etc and doing programming 'for fun' at home (my wife is constantly amazed by this). There's one other programmer who is keen to write well structured code (interestingly, he did a lot of work using Delphi) and to refactor poor code. The rest are, well, not great. Thnking about it, you could describe them as 'brute force' programmers - will force inappropriate solutions until they work after a fashion (e.g. using C# arrays with repeated array.Resize to dynamically add items instead of using a List).

现在，我不知道我目前所在的地方是否具有代表性，尽管从我以前的职位来看，我认为它是典型的。事后来看，我发现一些常见的模式对任何项目都没有帮助(比如缺少代码的同行评审)。

所以，7个程序员中就有5个是垃圾。

斯基兹

在编程中使用的进程越多，代码就会变得越糟糕

I have noticed something in my 8 or so years of programming, and it seems ridiculous. It's that the only way to get quality is to employ quality developers, and remove as much process and formality from them as you can. Unit testing, coding standards, code/peer reviews, etc only reduce quality, not increase it. It sounds crazy, because the opposite should be true (more unit testing should lead to better code, great coding standards should lead to more readable code, code reviews should improve the quality of code) but it's not.

我认为这可以归结为我们称之为“软件工程”的事实，而实际上它是设计而不是工程。

以下数字可以证实这一说法:

From the Editor IEEE Software, November/December 2001 Quantifying Soft Factors by Steve McConnell ... Limited Importance of Process Maturity ... In comparing medium-size projects (100,000 lines of code), the one with the worst process will require 1.43 times as much effort as the one with the best process, all other things being equal. In other words, the maximum influence of process maturity on a project’s productivity is 1.43. ... ... What Clark doesn’t emphasize is that for a program of 100,000 lines of code, several human-oriented factors influence productivity more than process does. ... ... The seniority-oriented factors alone (AEXP, LTEX, PEXP) exert an influence of 3.02. The seven personnel-oriented factors collectively (ACAP, AEXP, LTEX, PCAP, PCON, PEXP, and SITE §) exert a staggering influence range of 25.8! This simple fact accounts for much of the reason that non-process-oriented organizations such as Microsoft, Amazon.com, and other entrepreneurial powerhouses can experience industry-leading productivity while seemingly shortchanging process. ... The Bottom Line ... It turns out that trading process sophistication for staff continuity, business domain experience, private offices, and other human-oriented factors is a sound economic tradeoff. Of course, the best organizations achieve high motivation and process sophistication at the same time, and that is the key challenge for any leading software organization.

请阅读文章，了解这些首字母缩写词的解释。

XHTML是邪恶的。编写HTML

无论如何，您都必须将MIME类型设置为text/html，所以为什么要欺骗自己相信您实际上是在编写XML呢?无论谁要下载你的页面，他都会相信这是HTML，所以把它做成HTML。

有了这些，不要关闭你的<li>，这是没有必要的。不要关闭html标签，文件已经结束了。它是有效的HTML，可以被完美地解析。

它将创建更可读、更少的样板代码，并且不会丢失任何东西。HTML解析器工作得很好!

当你完成后，再转向HTML5。这样更好。

最好的程序员在调试器中跟踪所有代码并测试所有路径。

嗯…OP说有争议!

计算机科学或其他IT领域的学位确实会让你成为一个更全面的程序员

我不在乎你有多少年的工作经验，读过多少博客，参与过多少开源项目。一个资格证书(我建议超过3年)会让你接触到一种不同的思维方式，给你一个很好的基础。

仅仅因为你写了一些比计算机科学学士更好的代码，并不意味着你比他更好。你所拥有的，他可以在瞬间学会反之则不然。

拥有资格证书表明了你的承诺，你会超越经验，成为一名更好的开发人员。擅长自己的工作并且有资格的开发人员可能会非常令人生畏。

如果这个答案被否决，我也不会感到惊讶。

而且，一旦你有了资格，你就会慢慢停止和其他有资格的人比较(我的经验)。你意识到到最后一切都不重要了，只要你们能很好地合作。

始终仁慈地对待其他开发人员，无论其资格如何。