我是一名初出茅庐的年轻开发者，希望从事专业的开发工作，因为这是我所热爱的，以下是我曾经持有的一些观点，这些观点都是我在短暂的经验中学到的，但都是错误的

当你根本不把用户界面和逻辑分开时，你最终会遇到的可怕的混乱是可以接受的，这也是每个人写软件的方式

不存在太多复杂或抽象的东西

一类责任——我从未真正有过这个概念，它对我来说是非常正式的

测试是我在卧室里编写代码时不需要做的事情

我不需要源代码控制，因为它对我所做的项目来说是多余的

开发人员什么都做，我们应该知道如何设计图标和做出漂亮的布局

Dispose并不总是需要结束符

任何类型的错误发生时都应该抛出异常

异常是针对错误情况的，很多时候只返回一个指示失败的值就可以了。我最近才明白这一点，我一直在说这一点，并且在很长一段时间内仍然抛出异常

我可以编写一个完全没有错误的应用程序

评论越多越好。我总是试图让我的代码尽可能具有可读性——主要是因为我几乎肯定是那个会修复我漏过的bug的人。所以在过去的几年里，我经常会收到一段又一段的评论。

最终，我明白了，有一个点，更多的评论——无论结构多么整齐——没有增加价值，实际上成为一个麻烦的维护。这些天，我采取了目录+脚注的方法，每个人都为此感到高兴。

该条件检查如下:

if (condition1 && condition2 && condition3)

以不确定的顺序执行…

我认为我应该尽可能地进行抽象。我的脑袋被这个撞了，因为太多交织在一起的小功能。

现在我试着让事情尽可能的简单和分离。重构使事物抽象比预测需要如何抽象要容易得多。

因此，我从开发规则它们的框架转移到完成工作的功能片段。从来没有回头，除了当我想起那段时间，我天真地认为我会是那个开发下一个大东西的人。

让非程序员明白我在说什么。

人们知道他们想要什么。

在很长一段时间里，我以为我会和人们交谈，他们会描述一个问题或工作流程，我将其放入代码并自动化。结果每次发生这种情况，他们以为自己想要的并不是他们真正想要的。

Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.

我想这个答案类似于Robin关于非程序员理解/关心我所谈论的内容的回答。这是关于将业务作为一个敏捷的、迭代的、交互的过程来学习。它是关于学习编程猴子和软件开发人员之间的区别。这是关于意识到两者之间的区别，并且在该领域真正优秀，不仅仅是语法和输入速度。

编辑:这个答案现在是社区-wiki，以安抚人们对这个答案感到不安，给我代表。