如果你只能想到一种方法，那就别去做。

无论是一个界面布局，一个任务流，还是一段代码，都可以停止。做一些事情来收集更多的想法，比如询问其他人他们会怎么做，在你至少有三个完全不同的想法和至少一次信心危机之前，不要回去实施。

一般来说，当我认为某件事只能以一种方式完成，或者认为只有一种方法有任何优点时，那是因为我没有充分考虑应该彻底影响设计的因素。如果我这样做了，其中一些显然会发生冲突，导致混乱，从而做出实际的决定，而不是死记硬背的违约。

成为一个优秀的程序员并不意味着你就是一个优秀的界面设计师

遵循世界上所有的界面指南只会开始有所帮助。如果这是人类可能做到的…人们似乎有一种特殊的嗜好，就是把东西变得“可爱”和“聪明”。

依赖管理软件弊大于利

我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。

像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。

问题解决了，对吧?

错了。

下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。

我不受欢迎的观点是:

如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。

同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。

您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”

当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。

我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。

使用库和框架是很好的。但成本总是存在的，掩盖成本的工具本身就是有问题的。

此外，有时(注意:当然不总是)通过编写一些小的类来实现您所需要的东西比引入对大型通用库的依赖更好。

显然我的想法是哈斯克尔有变量。这既是一个“无关紧要”的问题(根据至少8个SO用户的说法)(尽管似乎没有人能就哪个无关紧要的答案是正确的达成一致)，也是一个糟糕的问题(根据至少5个反对者和4个投票关闭它的人的说法)。哦，我(以及计算科学和数学家)错了，尽管没有人能给我一个详细的解释。

XML和HTML是web的“汇编语言”。为什么还要黑它?

很明显，现在很少有开发人员学习汇编语言/编写代码，因为它很原始，并且使您远离必须在高层解决的问题。所以我们发明了高级语言来封装这些级别的实体，通过我们可以在更高级别上联系到的语言元素来提高我们的工作效率。就像我们可以用计算机做更多的事情，而不仅仅是它的组成部分主板或CPU。

对于Web，在我看来，开发人员仍然在阅读/编写和破解HTML、CSS、XMl、模式等。

我认为这些语言相当于Web或其基础的“汇编语言”。 我们该结束了吗?当然，当出现问题时，我们有时需要破解它。 但可以肯定的是，这是个例外。 我断言，我们正在用等价的web级汇编语言取代机器级的低级汇编语言。

编程挣钱通常是对男人时间最糟糕的利用之一。

首先，你是在和埃尔博尼亚人竞争，他们每天只挣25美分。你需要说服你的雇主，你能提供埃尔博尼亚人永远无法提供的东西，而且你的东西值得一份体面的薪水。随着埃尔博尼亚人获得越来越多的海外业务，真正的优势逐渐消失，管理层也明白这一点。

另一方面，你是在花时间解决别人的问题。这些时间你可以用来发展自己的兴趣，或者解决你真正感兴趣的问题。如果你认为解决别人的问题就能拯救世界，那你为什么不让埃尔博尼亚人为你解决问题呢?

最后，软件领域的伟大创新(visicalc、Napster、Pascal等)不是由小隔间农场创造的。它们是由一两个没有预支工资的人创建的。你不能强行重建它。当一个有能力的程序员有一个非常好的想法时，这就是奇迹。

有足够的软件。有足够多的软件开发人员。你不需要被雇佣。节省你的才华，你的时间，你的头发，你的婚姻。让别人把灵魂出卖给键盘吧。如果你想编程，没问题。但不是为了钱。

Tcl/Tk是有史以来最好的GUI语言/工具包组合

它可能缺少特定的小部件，外观也不如新产品好看，但它的模型很优雅，而且易于使用，因此通过交互式输入命令可以比使用可视化界面构建器更快地构建工作gui。它的表达能力是无与伦比的:其他解决方案(Gtk、Java、. net、MFC……)通常需要10到100个LOC才能得到与Tcl/Tk一行程序相同的结果。所有这些都不会牺牲可读性和稳定性。

pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]