最近我收到了一封读者来信让我陷入了沉思，信是这么写的:
Hi philip walton,您是否介意我问您是怎么成为一个卓越（great）的前端工程师的？对此您有什么建议吗?
我不得不承认，我很惊讶被问这样的问题，因为我从来都不觉得自己是一个卓越的前端工程师。甚至我入行的头几年，我不认为我能做好这一行。我只确定自己比自己想象中还才疏学浅，而且大家面试我的时候都不知道从何问起。
话虽这么说，我到现在做的还算不错，而且成为了团队里有价值的一员。但我最终离开（去寻求新的挑战————即我还不能够胜任的工作）的时候。我经常会被要求招聘我的继任者。现在回头看这些面试，我不禁感叹到我刚开始的时候在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘，即便我个人的这种经历也有可能成功。
我在web领域工作这么长时间，我就越意识到区分它们是人才和顶尖人才的并不是它们的知识--而是它们的思维方式。很显然，知识在很多情况下是非常重要的而且关键的————但是在一个快速发展的领域，你前进和获取知识的方式（至少在相当长的一段时间内）会比你的知识显得更加重要。更重要的是：你是如何运用这些知识解决你遇到的问题的。
这里有许许多多的文章谈论你工作中需要的语言，框架，工具等等。我希望给一些不一样的建议。在这篇文章里，我想谈一谈一个前端工程师的心态，希望可以帮助大家找到通往卓越的道路。
别光解决问题，想想究竟发生了什么？
很多人埋头写css和javascript直到程序工作起来了，然后就去做别的事情了。我通过code review发现这种事经常发生。
我总会想着问大家:“为什么你在这里添加float:left?”或者“这里的overflow:hidden是必要的吗？”，他们往往答道：“我也不知道，可是我已删掉它们，页面就乱套了”。
Javascript也是一样，我总是会在一个条件竞争的地方看到一个setTimeout，或者有些人无意中终止了事件传播，这往往会影响到其他页面中程序的事件处理。
我发现很多情况下，当你遇到问题的时候，你只是解决当下的问题罢了，但是如果你永远不花时间理解问题的本源，你将一次又一次的面对同样的问题。
花一些时间找出为什么，这看起来费时费力，但是我保证它会节省你未来的时间，在你完全理解了整个系统之后，你就不需要再去猜测和论证了。
学会预见未来的浏览器发展趋势
前后端开发的一个主要区别在于后端的代码通常都运行在你的掌控之下，前端相对来说不那么在你的掌控之下。不同用户的平台或设备是前端永恒的话题，你的代码需要优雅的掌控这一切。
我记得在2011年之前曾经阅读某javascript主流框架的时候看到过下面这样的代码
var isIE6 = !isIE7 && !isIE8 && !isIE9
在这个例子中变量isIE6为了判断浏览器的版本是否是IE6或者更低的版本。那么当IE10发布的时候，我们现在的程序判断就出问题了。
我理解在真实世界特性检测并不100%工作，而且有的时候你不得不依赖有bug的特性或根据浏览器检测的错误设计白名单。但你为此做的每一件事都很关键，因为你遇见到了不在有bug的未来。
对于我们现在很多人来说，我们今天写的代码会比我们工作的周期要长。有些我写的代码已经8年多了现在还在产品线上运行，这让我们很满足又很不安。
阅读更规范的文档
浏览器出现bug是难免的事，当一份代码在两个浏览器渲染出的结果不一样，人们会不假思索的认为‘广受好评’的那个是对的，而‘不起眼’的浏览器是错的。但事实并不一定如此，当你的假设出现错误时，你选取的变通办法都会在未来遭遇问题。
一个就近的例子是flex元素默认最小的尺寸问题。根据规范的描述，flex元素初始化min-width和min-height的值是auto，也就是说他们默认应该收缩到自己内容的最小尺寸。但是在过去长达8个月的时间里，只有firefox的实现是准确的。
如果你会遇到了这个浏览器兼容的问题并且发现Chrome、IE，Opera，safari的效果相同而firefox和他们的结果不同，你很可能会认为firefox搞错了。事实上这种事情我见多了，很多在我自己flexbugs项目上报的问题都是这样的。而且这些解决方案的问题会在两周后rome44上修复之后被体现出来。和遵循标准的解决方案相比，这些方案都伤害到了正确的规范行为。
当同一份代码在两个或者更多的浏览器的渲染结果不同是，你应该花谢时间确定那个效果是正确的。并且以此为标准写代码。你的解决方案应该是对未来有好的。
额外的，所谓的“卓越“的前端工程师是时刻感受变化，在某项技术成为主流之前就去适应它。甚至再为这样的技术做着贡献。如果你锻炼自己看到规范就能想象到在浏览器支持之前是如何工作的，那么你将成为谈论并影响规范开发的那群人。
阅读别人的代码
出于乐趣阅读别人的代码可能并不是你每周六习惯想到的项目。但是这毫无疑问使你成为优秀工程师的最佳途径。
自己独立解决问题绝对是个不错的方式，但是这不应该是你唯一的方式。因为他很快就会让你稳定在某个层次。阅读别人的代码会让你开阔思维，并且阅读和理解别人的代码也是团队协作或开源贡献 必须具备的能力。
我着实认为很多公司在招聘新员工的时候犯的最大错误是他们只评估应聘者从轮廓开始写新的代码的能力。我几乎没有见过一场面试会要求应聘者阅读现有的代码，找出其中的问题。并修复他们。缺少这样的面试流程真的不好，因为你作为工程师的很多时间都花在了在现有的代码基础上增加或改变它们，而不是搭建新的东西。
与比你聪明的人一起工作
我印象中的前端开发者都是自由职业者。有同类想法的后端开发者并没有那么多。可能是因为很多前端开发者都是自学成才，而后端开发者多是从学校里学出来的。
不论是自我学习还是自我工作，我们都面对一个问题：你并不能从比你聪明的家伙那学到什么，没有人帮你review 代码，也没有人与你碰撞灵魂。
我强烈建议，最起码在你职业的前期，你需要在一个团队里工作，尤其是一个普遍比你聪明的，有经验的团队里去工作。
如果你最终会在你职业发展的某个阶段选择独立工作，一定要让自己投身在开源社区当中。保持对开源项目的活跃贡献，这会给你团队工作相同甚至更多的溢出。
造轮子
造轮子在商业上是非常糟糕的，但是从学习的角度是非常好的。你可能很想把那些库和小工具直接从npm里拿下来用，但也可以想象一下你独立创建它们能够学到多少东西。
我知道有些人读到这里是特别不赞成的。别误会，我并没有说你不应该使用第三方代码。那些经过充分测试的库具有多年的测试用例积累和已知问题积累，使用它们绝对是非常明智的选择。
但在这里我想说的是如何从优秀到卓越。我觉得这个领域很多卓越的人都是每天在用的非常流行的库的作者或维护者。
你可能不曾打造过自己的javascript库也拥有一个成功的职业发展，但是你从不把自己的手弄脏是不可能淘到金子的。
这一行大家普遍会问的一个问题是：我接下来应该做点什么？如果你没有试着学一个新的工具创建一个新的应用，那不妨试着重新造一个你喜欢的javascript库或css裤架。这样做的好处是，在你遇到困难的时候，所有现成的库的源低代码都会为你提供服务。
把你学到的东西都记录下来
最后，但丝毫不逊色的是，你应该把你学到的东西记录下来。这样做有很多原因，但也许最终要的原因是他强迫你更好的理解这件事。如果你无法讲清楚它的工作原理，在整个过成中它会推动你自己把并不真正理解的东西弄清楚。很多时候你根本意识不到自己还不理解它们--直到自己动手写的时候。
根据我的经验。写作，演讲，做demo是强迫自己完全深入理解一件事的最佳方式。就算你写的东西没有人看，整个过程也会让你受益匪浅。
