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.

学习正则表达式可以节省时间

那当断点有效时，谁还需要JUnit测试?(在调试模式下测试应用程序时)。后来我意识到为什么....

我一直认为，要成为一名优秀的程序员，必须了解系统的所有内部工作原理。我很羞愧，因为在开始编码之前，我不知道关于这门语言的一切，比如它的库、模式、代码片段。 我不再那么天真了。

c++是最酷的语言!

字节和字符实际上是一回事——“ASCII”只是将字节值映射到屏幕上的符号的一种方式。

阅读关于Unicode的文章真的让我大开眼界(尽管我仍然没有完全理解它)。