我认为编写足够好的软件是一项简单的任务

假设我把代码写得很好，尽可能没有错误，这就是我能做的最好的事情。事实证明，有时候经理们更喜欢那些努力成为他们最喜欢的人，而不是把工作做好的人。

至少6年来，我一直坚信，每个问题都只有一个解。

完全不知道不同复杂性的多种算法、空间/时间的权衡、面向对象、功能和命令式、抽象级别和无法确定的问题。当那种幸福的天真被打破时，它打开了一个充满可能性的世界，关上了坐下来建造东西的大门。我花了很长时间才弄清楚怎么选一个然后用它来运行。

我认为我应该尽可能地进行抽象。我的脑袋被这个撞了，因为太多交织在一起的小功能。

现在我试着让事情尽可能的简单和分离。重构使事物抽象比预测需要如何抽象要容易得多。

因此，我从开发规则它们的框架转移到完成工作的功能片段。从来没有回头，除了当我想起那段时间，我天真地认为我会是那个开发下一个大东西的人。

不熟悉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不重要，因为它最终会回来困扰你。你可能可以在一段时间内摆脱它，甚至几年，但你最终会达到一个断点，在没有完全重新设计数据库的情况下，你无法继续前进，那是成本最高的时候。

在学校里，你被教导编程是“读取输入，处理数据，写输出”。实际上，很少有处理步骤——大多数编码只是“读取输入，输出”。

一般来说，它要么是“从用户读取，写入数据库”，要么是“从数据库读取，显示在屏幕上”。这两种情况涵盖了大约95%的工作。