我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如，我误解了整数的大小不是标准的，而是取决于语言和目标。说起来有点尴尬，但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试，或者任何关于编程、编程语言或计算机科学的东西。
当前回答
我最大的先入之见是，我将被允许以我想要的方式编程。当然，后来我离开了大学，进入了一家拥有荒谬框架、规则和程序的公司，这不仅意味着我不能以自己想要的方式编程，而且意味着我编程得很糟糕。
其他回答
在正式发布之前，没有缺陷是可能的。
这绝对不是真的，即使P2缺陷有时也会被打开。
我可以说服传统的过程程序员，为什么OOP经常提供更好的解决方案。
也就是说，一种描述世界的语言需要有描述复杂对象及其关系的能力。
争论通常包括关于抽象类的废话，我的回答是“不是所有的OOP程序员都刚从Uni毕业，还沉迷于抽象”。或者是经典的，“在面向对象编程中，没有什么是我用严格的过程式编程做不到的”，对此我通常会回答，“不是你能做到，而是如果你有一个更广泛的工具集，你是否会做到”。
我已经学会接受他们和我看世界的角度不同这一事实。
当我第一次听说“鸭子打字”时，我以为它实际上是“管道打字”，类似于人们经常说的鸭子胶带。“Duck typing”听起来是错误的，而“pipe typing”则有一种奇怪的意义(拼凑的类型)。
Java将对象的副本传递给函数，而不是引用。
换句话说，我认为如果你将一个对象传递给一个方法，然后以某种方式改变对象，它不会改变调用范围内的对象。我总是将对象传递给方法，操作它们，然后返回它们!
My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis. Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week. "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.
