回到目录

喝完杯中最后一口咖啡，把纸杯扔进垃圾桶，利索的走回自己的办公桌。

入职亚马逊已经一个月了，深刻感受到了这家以卖书起家的电商公司对于技术的重视和尊敬。进入公司后第一周参与了关于公司文化的培训，之后就进入了项目组开始正是上手工作。我所在的组属於亚马逊核心电子商务部门下面的定价组（pricing team），这个组的任务就是利用一系列技术为amazon.com网站上出售的五花八门的商品定价。毫无疑问，定价这个功能直接影响货物销售的数量以及利润，因此承担这个任务的团队十分庞大，而我所在的组仅仅承担整个技术栈中比较底层的部分。

我的经理给我安排了一个mentor（导师），帮助我快速上手工作。导师刚开始给我的任务主要就是阅读文档来熟悉技术领域，并没有给我任何具体的项目去做。在不熟悉技术领域的时候阅读文档是相当痛苦的，我为了少给导师添麻烦，同时显示自己学习的能力，努力理解文档内容。通过我的不懈努力，对系统有了一个答题的了解。但随着阅读的深入，发现很多地方的记录自相矛盾，我终于忍不住问了我的mentor。mentor随便扫了一眼，说，应该是文档没来得及更新，有什么不清楚的可以直接看代码呀。

整个系统有几十万行的代码，对于一直在这堆代码中工作的工程师来说不是问题。然而对于我这个新人来说，在没修改过一行代码的情况下，去直接看代码是有点痛苦的。

应该是非常痛苦。在尝试了一个早上之后，我放弃了直接阅读代码来理解文档这件事情。然而之前在阅读工作流程的文档时读到，组里每个任务都是可以通过类似issue tracker的工具来进行追踪的。于是，我打开这个工具，无数条任务扑面而来。每条任务有一个标题简单描述任务的内容，点开之后任务归谁完成，任务具体内容，还有所有的讨论一目了然。这个发现简直为我打开了新世界的大门，我打开每一条任务，试图阅读每条任务的详细内容，仿佛偷听别人的对话一样。于是我彻底放弃了阅读残缺不全的文档。

我发现了最好的新手项目 - 修bug。在任务列表里找到那些自己看得懂的，并且被标记为regression（功能倒退）或者bug（功能错误）的，再从中按难易程度排名跳出最容易的一个。按照文档，在自己的机器上复现该任务描述中出现的bug，然后一层一层深入研究出现错误的原因。基于找出的原因，修改源代码使得错误消失。最终将修改的源代码提交给我的mentor来帮我做code review。在入职第四周，我终于合并了自己的第一批代码到产品代码库里。

对于初入职场的程序员来说，自己的代码第一次进入到产品中是里程碑式的。这是对于写代码整个工作流程的第一次体验，从寻找问题到研究问题，再到写代码解决问题，最终通过严格的代码审查进入产品。另外，在Amazon这种提供大规模软件服务的产品中做出的修改，很有可能会被上百万的用户使用，对于程序员来说是十分具有成就感的。

懵懵懂懂的，我为自己找到了新手项目，虽然不是一帆风顺，但算是步入了正轨。可这意味着必将是更大的挑战。