我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如，我误解了整数的大小不是标准的，而是取决于语言和目标。说起来有点尴尬，但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试，或者任何关于编程、编程语言或计算机科学的东西。
当前回答
适合系统编程的语言必须支持可变变量。
其他回答
人们知道他们想要什么。
在很长一段时间里，我以为我会和人们交谈，他们会描述一个问题或工作流程，我将其放入代码并自动化。结果每次发生这种情况，他们以为自己想要的并不是他们真正想要的。
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，以安抚人们对这个答案感到不安，给我代表。
不熟悉SQL和关系数据库的过程开发人员/程序员不需要任何正式的培训，也不需要了解如何使用SQL，快速阅读SQL For Dummies之类的东西就足以使用像Oracle和SQL Server这样的关系数据库。
在处理存储在关系数据库(如Oracle和SQL Server)中的数据的应用程序中，许多错误往往是由于缺乏对关系数据库语言的理解或如何使用造成的;SQL。
I used to work for a software vendor who had the mentality that all a developer needed was the SQL For Dummies book or something similiar and they would be fully equipped to handle any relational database issue. Now that the clients of this vendor have databases measuring in hundreds of gigabytes this lack of SQL knowledge is coming back around in a negative way. It's not just bad performing lookups and or updates and inserts that are a problem but the actual design of the database itself that is the real obstacle.
如果当时开发主管能够像对待他们构建应用程序所用的语言那样对待SQL和关系数据库，那么所有这些都是可以避免的，而且成本也会低得多。
不要认为SQL不重要，因为它最终会回来困扰你。你可能可以在一段时间内摆脱它，甚至几年，但你最终会达到一个断点，在没有完全重新设计数据库的情况下，你无法继续前进，那是成本最高的时候。
XML名称空间(或者更糟，格式良好)在某种程度上比没有它们要困难得多。
一个非常常见的错误，甚至在W3C!
营销人员关心你做什么。
总是没有足够的时间在最后期限前完成。
