在SEM组的工作使我从一个入门的初级程序员，成长到可以去带新人的mentor，除了做每个季度组里的季度目标意外，我也参与到全公司的推进的项目中。比如JDK从1.6升级到1.7，从旧的部署系统迁移到新的部署系统，启用CI/CD模型等等，在做这些项目的同时，自己接触到了在平常的开发过程中不会遇到的问题，比如如何解决库中的class冲突，CI/CD模型适用/不适用的情况等等。
于此同时，自己也不满足于只是去做分配下来的任务，开始观察并思索作为工程师的痛点。比如，每次上游的一些库会莫名其妙的改变一些公有接口，导致下游的项目构建收到影响，结果给下游项目的开发人员带来了额外的负担。另一方面，上游库的开发者要想改变删除过期的接口让下游项目迁移到新的接口，又苦于在公司内部喊嗓子得不到有效的回应，下游项目的工程师没有动力去及时的跟进改变，导致过期接口的删除迟迟不能进行。在这种情况下，如何可以减少不必要的公有接口修改，同时又能提高必要公共接口修改的曝光性？在研究了公司的构建系统之后，我决定在构建系统上，利用一些开源工具和Java编译插件的技术，实现了两个小功能：1. 在发布库的新版本是总是和最后一个旧版本比较API的修改，如果有任何公有接口的修改或缺失则给出警报。2. 提供编译期的注解（Annotation），让程序员可以对公有接口（类）设置过期时间，在过期时间到来之时下游的项目如果有引用则会出发构建失败。这两个功能我是一前一后做出来并在公司内部发布，但是风评却是前一个平平偏向负面，后一个得到不少的点赞和使用，但也引起了不少麻烦。然而由于当时急功近利的心里，并没有很好的去follow。
I社是我从一名初级程序员向着高级程序员成长，随着在公司的时间增长，手头的工作也很快不能够满足自己的兴趣，在SEM组待了将近三年之后我的经理建议我换组，在经历了一番挣扎后我选择了去一个有前段以及顺带一些移动应用的组，在这里我又重操了一段做移动端应用的经历，并且又学习了一些前段方面的知识。
在I社待了3年半的时间，当公司越来越大之后，时常会感到个人的贡献越来越有限，感觉个人的成长也在逐步的缓慢。在对比了其他同事的晋升道路后，仿佛看到了自己在N年后的场景。但是之前觉得在日本没有比I社更适合自己的公司了，于是也一直没有去寻求新的机会。去年随着几位前同事的离职，自己也开始认真的考虑换工作的事情。
恰逢也同样是美国总部的H社在东京开始招全栈程序员，虽然同样是美国公司，但是H社还尚未上市，团队也较小，所以抱着去施展一番拳脚的想法去面试了H社全栈工程师的职位，并于去年7月加入了H社公司。
全栈程序员加入H社后首先感到的很大的Gap，便是在公司的技术上。在I社，我所碰到的领域都已经有了成熟的解决方案。但是在H社，跟I社所对应的一系列基础设施建设却远远称不上完善。这让我进入公司之后很是怀疑了自己的选择。在进入公司的前两个月，我经常会发信给全公司的程序员，去探讨为什么我们要这么做而不是那么做。并且也提交了很多改进方案，希望可以改成我在I社所接触到的方案。当然这些都并不是很顺利，在H社的老人们给了非常强力的反击。在拿不出充分证据论证的情况下，我只好选择了暂时蛰居，先处理好眼下自己手头的工作。
加入H社后的首个项目是将一个年头已久的PHP前段+后端网页改成PHP + Apache Thrift + GraphQL + NodeJS +React的新框架，作为全栈（Full Stack）工程师，我需要从PHP到React头到尾都做一遍。首先便是读原来的PHP代码，并抽象成Thrift服务。其次便是在NodeJS服务器端将Thrift服务映射成GraphQL的Schema，并实现GraphQL的Resolver逻辑，然后便是用一个Node应用代替PHP的前段，用React的框架来渲染出一模一样的网页。在短短的几个月内，从一窍不通的React小白，到完成了整个页面的迁移，自己对于React框架的应用和一些实践有了自己的理解。GraphQL也是一个对我新鲜的概念，在GraphQL的实践中，我感到这个框架其实也很适用于我在I社工作的第二个组，甚至可以在脑海中把原来的API用GraphQL一一对应起来。这种相互印证的感觉让我再次意识到做出换工作的决定并没有错误，否则我的思路会很长时间局限在I社的框架中。