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.

不要使用高级的特定于实现的特性，因为你可能“有时”想要切换实现。我这样做了一次又一次，几乎无一例外地，这种转换从未发生过。

我记得我10岁的时候，有人让我相信，将来会有一种计算机能够在3秒内运行一个无限循环。

在初中学习算法的时候，我认为NPC只是一个非多项式问题，这意味着这个问题的复杂性并不比多项式简单。直到我在大学里学了计算理论，我才意识到我错了

我所受的教育将为我在野外工作做好准备。

一个程序最终可以解决所有的问题。