我是一名程序员，到最近为止一直从事机器学习，我自认为这是非常有趣的。我最喜欢机器学习的一点是，对于这项工作，真正重要和有趣的是我要真正花时间在机器数据上动手，并且加以理解，然后再以自己的视角去看待一个个机器。
我记得有一个星期我在想「我的工作应该是建立一个个能够准确地分类百万以上数据的系统，而不是手动地去做这些事情。」不过实际上，最终也没有任何人要雇佣我去手动的处理这些问题。
所以程序员有时候能够获得到很高的工资，我想，这是因为我们可以建立能够充分运用电脑功能的系统去处理多到不可理喻的工作量的事情。如果你能建立 Gmail 反垃圾邮件系统，你就可以帮助数以百万计的人从收件箱里删除垃圾邮件！这真的是很神奇又惊人的工作，而且它比各种 bug 和电脑问题更值得研究。
但是做这些事情是真的要花费很多时间。我做过的有意思的东西基本上，都要花费两至六个月。而且，花费比这更多时间在项目上是很常见的事情。我有一个朋友在一个项目上花费了一年多的时间，最后他建立了一个比谷歌还好的绘制大众运输地图的系统。尽管辛苦，但那真的很酷。
以上意味着实际上你能做出来的东西不多，而且如果最终的成果中有哪部分没有得到青睐，那就宣告了你一个季度的工作就这么浪费了。不过这都没关系，这好歹证明了你做的工作是值得深思熟虑的。
我在编程上面花的时间越多，实际上我就越能体会往什么项目上付诸精力实在难以取舍。就像我可以让一台电脑做十亿份的事情（就是字面意思，那其实是非常容易的），但我到底要从哪十亿开始呢？哪十亿会产生更多的影响？哪十亿的工作才能让我的公司运营得更好一些？
曾经有一次，我在刚开始经手某一项工作时和我的经理说：“嘿，我在想要做点别的什么！”他说，：“好啊，你想做什么事情来替代现有的方案？”于是我建立了这个项目的第一个版本（那是一个方便跟踪机器学习实验的小型系统），两年过后这个系统仍然被使用着，而且有一群人的学习就是建立在这个系统之上的。事实证明，这是一个好主意！
在刚开始编程的时候，我以为我的工作就是人们告诉我写什么代码，然后我就写下来那些代码，那就是全部了。当然我一路上都得到了不少指导，但那不是作为一个程序员应该有的样子。我应该为那些会给工程师们很大自主权的地方工作。
所以与之相应的，对我来说，工作应该是以下的情形：
o嗯，我们这有一个长远的目标，或者有三个，也或许有六个
o也有一堆不同的需要紧急处理的小问题
o现在你要来找出眼下解决哪个比较好
o也必须弄清楚如何解决
o还可能存在哪些不可能解决的问题
o和所有导致问题的外部因素
o你去跟那些想过这些问题的人讨论一会然后解决掉它！
o这里是这周 40 小时的工作。预备，开始。
首先你要知道你的目标是什么
那么，你要如何决定做什么呢？
我有一个同事 Cory Watson 在 Monitorama 有一些很酷的言论，他把他做的事称为为创建一份可观测的文化。 culture of observability原文链接
他对自己所做的事描述如下：
换句话说，如果我们的传感器——想想指标，日志和跟踪——都不错，那么我们可以了解我们的系统工作得是如此高效。
我在 Stripe 的工作就是确保这件事情。和 Cory 一起工作的时候，会很明显的发现他正在不懈努力地专注于让大家更容易得知道我们的软件系统正在做什么。这是非常有帮助的，公司的显示板和指标已经因此好了很多了。它更易于性能改进和检测并理解错误。
和 Cory 一起工作的时候，会很明显的发现他正在不懈努力地专注于让大家更容易得知道我们的软件系统正在做什么。这是非常有帮助的，公司的显示板和指标已经因此好了很多了。它更易于性能改进和检测并理解错误。
我那个做过地图应用程序的朋友 Anton 非常在乎如何表示公交信息，而且他总是在想这件事情，所以我并不惊讶于他能够用这么棒的方式去完成好这件事。
我认为这样的工作焦点能够起到难以置信的帮助。——当我没有一个明确的目标的时候，我会发现要去完成或者决定一件事情真的真的很难。我偶尔会模拟“如果我在一个派对上我是否能解释清楚我自己的工作？”的测试。每当我无法通过这项测试的时候（特别是如果我在派对上遇见的人是一个软件工程师的时候）我就会觉得很难受。
显然，你并不需要始终专注于同样的事情（ Jeff Dean 就像是谷歌一个传奇还是什么的，我觉得他好像做了一吨的不同的事情），但有一个工作焦点似乎真的很重要。
建立一个工作焦点并不是一件容易的事
在工作中有很多可能发生的事情都要考虑一下！而作为一个人（不是经理），在同一时间只能关注到有限的东西。我看到人们致力于：
- 我们的存储系统是超可靠且易于使用的
- 能够轻易地实时告诉你的代码是干什么的
- 让开发的体验变得更好更容易
- 使得显示板成为一个很棒的为我们的用户了解他们自己的业务的地方
所以不管怎样我需要找到一个足够大而且足够重要的工作焦点（我不知道我是否能向我的同事解释清楚我为什么做我正在做的事情），但是又小到一个人（或一个小团体）足够推动它发展。然后就能更容易地来编写代码从而实现这一个愿景！
是没有唯一的“正确答案”的
这篇文章原本的题目是“你要如何致力于正确的事情”，我把它改掉了，因为我认为那样说是一种错误（而且有一点点危险）的措辞——没有事情是对每个人来说都正确的，就像我还在和很多致力于更重要事情的很棒的人一起工作。不是所有事情都是同样具有影响力的（这也是这篇文章的主要内容），但是这篇文章是关于寻找在你能力范围之内的对你来说有用的事情，而不是找一个对所有人都是最优的东西。
如果我只写了一篇对所有人都是最好的博客文章，我就好像字面上从来没有发表过任何东西。
相信这是可能的
如果你正在做一件长期或者一项挑战很大的野心勃勃的事业，关于它，有一件事你必须做到——你必须相信你可以做完这个项目。如果你开展了一个很酷的为期一年的项目，一路上大约会有 5000 万事情会出错。那些你以为不会有问题的东西也会出问题。而如果在又一周或三周过得很糟糕的时候，或者有人不相信你所做的事情是正确的时候就放弃，那你永远不会完成你手头的事情。
我认为这是一个导师或者一个高级别的人可以为比自己低级别的人做的一件非常重要的事情。很多时候你没法分辨什么是有可能完成的，什么是不可能完成的，什么样的障碍对你来说是有利的，什么样的障碍是不可逾越的。但是，这其实是可以靠自己努力的！如果有人告诉你：“不要担心，一切都会正常的！”，然后你就可以开始了，直击问题，然后寻求建议，并坚持下去，最终取得胜利。
一旦你有了足够的胜利经验和失败经验，你就会开始有自己的感觉，知道哪些东西会起作用，哪些永远都不会，然后自己能够决定要坚持什么。
人们会经常谈论“ Agile ”和 MVPs ，但我不认为他们能够被称之为一个对问题的完整解答——有些时候你需要构建一个大项目，你要写设计文件构建原型，但最终你要决定那些更操蛋的事情，继续工作，保证投入大量时间构建项目，以及在你有能力的时候展示项目的中期进展。
此外需要你的组织支持你的工作——如果你身边的人不相信你可以做到这件事，那么你将会非常难完成任何事情。
我再也不只是一个本科生了
我喜欢做一个数学/ CS 本科生。我的教授会给我一系列的挑战任务，但是它们都始终在我的能力范围之内。我一直在一点点地进步！这些挑战真的太有趣了！我在里面简直如鱼得水！但是，这样的日子还是结束了。
我的工作更像是——我有一系列的任务，从最琐碎的小事，到我完全不知道怎么下手的东西。然后我需要搞清楚要如何向他人询问相关问题，然后提升我的能力，从而去啃那些硬骨头。我需要自己判断别人对我说的“挺好的”是不是真的在夸奖我已经决定要做的事情，因为没有人会为我完成它们，真的没有。 Dan Luu 指给我看的 Rebecca Frankel 写的关于这篇帖子（done and gets things smart原文链接）的有趣评论如下：
我十分认同 Steve Yegge 的说法——这是一个对那些在另一层次上的人极为重要的（小）群体，他们和普通的聪明勤奋的人的确不同。这里有另一种方式去解释这种巨大的突破——可能我只是一直在用这些讨论建立了这样的观念：这是两种人的差异，一种是努力在别人设置的测试下一直想要努力做好的人，另一种是已经认知到自己的能力水平，努力去提升自己对自己的能力评级，他们往往比别人更加更小心仔细，也更加迷恋完美主义。
因此，在某种程度上，着手一件重要的事情，做得好就意味着你必须确定你的目标是什么，也必须建立自己的内部标准，无论你是否曾经有过这些东西。除此之外，你要知道也许其它人可以帮助你上手，但一切结果最终还是由你掌握。
一些有用但是毫无关联的想法
- Maggie 谈了“事后推动的发展方法”——去看看那些失败了很多次的东西吧！看你能不能做到让他们不要再失败了！
- 做这些失败的实验是正常（而且重要）的。也许诀窍就是当你在尝试有风险的或者新的事情的时候，你要记得把这些失败放进你的 Timebox 里。
我不知道！
我觉得很奇怪去承认我真的在为此努力奋斗。我并不总能构建好的想法。有时候有些我认为是很好的想法，于是我着手使它们成真，它们确实挺棒的，但有时候我实践了想法却发现它们是...真的并不怎么样。有时候，对自己的工作标准让我无法弄清楚到底如何满足它，这真的很无奈。
有时候别人会有一些想法，我听了觉得挺好的然后就会帮着他们构造他们所想的东西，去让这些好东西成真。直到现在，我参与过的最好的的项目就是令我兴奋的别人的点子。
有时候我会几个月都搞不明白别人的一个想法，可是在他们把这些想法真正构建起来后，我就会开始哦！天啊！这真的太棒了！！即使在现实中去发现真正好的东西挺难的。
一些链接：
- data driven products now原文链接 有关 Dan McKinley 讲的有关如何构建面向消费者的网络产品
- secret to growing software engineering career原文链接(感谢 Emil Sit )
- high-leverage work isn't always deep原文链接
感谢 Emil Sit , Camille Fournier , Kyle Kingsbury , Laura Lindzey , Lindsey Kuper , Stephen Tu , Dan Luu , Maggie Zhou , SunahSuh , Julia Hansbrough ,还有其他为这些文章作出评论的人。
