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.

“这个项目将在两周内完成”

and

“这需要2个小时才能实现”

Windows中的线程很便宜。

事实证明，这只是部分正确。线程有一定的开销，需要自己的地址空间，在那里它可以生存和快乐。因此，如果我发现自己在一个应用程序中处理数十个线程，我会问自己如何将所有内容简化并整合到更少的线程中。

Java很慢。这么多perl粉丝在slashdot上反刍(sp??)这很可悲。

认为自己对编程中的某种语言/主题了如指掌。根本不可能。

在开始开发之前，您可以完全理解问题。