软件工程师通常认为好的软件是采用正确的模式、遵守规范、制定规则、遵循最佳实践和正确处理流程的产物。
但程序员知道这些都是狗屎。
相对于建设一座大桥，编写代码更像是创作音乐，编写书籍，拍摄电影，或者是绘画。事实上，编写代码更难。这需要我们做更多，使我们的产品不仅仅是好看或者好听那么简单。大家知道，好的音乐、绘画、文学作品不是关于如何循规蹈矩，更多的是关于如何打破常规，探索新想法。你以为音乐排行榜或者最佳销售榜上那些最流行的作品是因为遵守了什么标准或者规范而上榜的吗？如果是那样，那些榜单将会变得很不一样，而且也不那么流行，因为社会在向前发展，总会出现新事物，或者以不一样的观念审视旧事物，而且永远不会停止。
最好的程序员能够简单自然的完成他们想做的事情，工作稳定，而且有足够的直觉让自己不那么讨厌。通常那些被忽视的东西，要比显而易见的东西要重要的多。比如：相对于一个可配置的软件，我们更希望得到一个可以自己完成配置，或者干脆不需要配置的软件。我们大概没有意识到身边存在许许多多正在使用的运行良好的软件，因为它们只是在默默的在运行，我们不需要关心或者担心他们。当软件出现问题的时候，我们才会关心那些“软件工程师”是不是遵循了规范和流程，软件崩溃让我们很满脑，因为软件是一样关注人，关注解决问题的东西，而不仅是工具或者技术（直到有一天，你尝试了各种各样的软件最后发现一款合适的软件的时候才能深刻的理解这一点)，也不是其他什么。当软件好用的让我们吃惊时，我们仍然不会记得什么规范什么流程，除非我们做过类似的事情。所以看起来只有软件工程师关心规范或者流程之类的东西。
我发现那些倾向于工程师的心态, 倾向于聚焦技术、代码、流程是否被正确执行、以及测量那些武断的规范或风格的执行是否到位 的人往往忽略了真正的问题是否被解决了？使用者的真正需要是什么？好的软件能够在用户体验、实际问题以及技术之间取得平衡。最好的结果通常来源于对三者都做微小的修改，但是如只聚焦于工程本身，那就显得过于短视。
当被要求遵守规范的时候、当纠结于繁复的流程的时候创造力被扼杀了，这是个问题。大部分主流的指导和流程是对管理友好的，管理者得到了他们想要的东西。但是软件工业发展非常快, 真正的创新不会产生自“最佳实践”。当工程师还在纠结于流程的时候，程序员则在不断创新，不断寻找更先进方法，这时候他们也许不会遵守流程，不会按部就班，但是他们往往能成功。
举个例子：也许大约200行 Node.js 代码也许能比10000行 java EE 代码更好跟容易的解决问题？也许稍微修改一下用户需求能大幅降低实现的复杂度？
当用户体验、软件功能、技术实现出现冲突的时候，只有程序员能看透其中的奥秘。而软件工程师倾向于忽略这些问题，因为在搞清楚到底出了什么问题之前他们已经决定该如何解决了。他们会控制变更，好像问题会自己修复一样。
当我14岁的时候我成为了一名程序员（自学的），后来我成为了设计师、架构师，然后我意识到我整天只是在画流程图，编写文档，这是在浪费时间，而且感觉糟透了。我现在48岁我又开始写代码了, 而且很喜欢，这是因为相比之前，我能让软件变得更快更好，让它能真正满足用户的需求, 而不是整天在宏观层面胡扯。
有些人认为雇佣工程师能够带来比卑微的‘程序员’更多的稳定性，但我更愿意雇佣程序员或者叫软件开发者，因为工程是反自然的，比如钢筋混凝土，我们如果正确的安装它，但是计算机、人、软件并不是这样运作的，想想一下你需要给一个飞行中的飞机更换零件。
对于我而言，编程和软件开发不仅仅是需要实践的天赋或艺术，虽然它的确需要一些规矩，而更多的是关于创造一些真正的新的充满希望的，让人快乐的或者能够带来真正价值的东西。
