本人本科毕业之后一直在一家大型网站工作。
主要经历：
第一年前半年里，熟悉技术，不太懂工作上的事情，摸索了很久，感觉也没什么进步。做事情停留在表面，没有系统的联系起来，都是提心吊胆，结果不确定。当时组里的同事给我讲了很多系统的架构之类的东西，我感觉没有深入的理解进去，到现在也忘掉了。同时，做的事情优化和修改也不够多，也就是回顾的很少，于是经验积累很有限。其实就变成了熟悉编程语言了。
第一年后半年里，随着项目组一起去做另一个业务，然后发现自己写业务核心代码根本不行，漏洞百出，经验完全匮乏。于是被安排到后台做编辑系统，做的还挺用心的。不过常常是没有开发完善，很多细节没有处理就提测了，然后导致测试同学不停的提bug，比较埋怨我。当时对完善的开发和自测没有一个清晰的认识，于是做的东西质量也不高。
第二年上半年里，开始做一个ipad上的阅读客户端后台逻辑。做了一个索引优化的需求，连续2个月不停优化。这一次程序代码在功能上的拆分，优化做的很到位，整体很优雅。唯一一个问题是细节测试不行，部分接口和函数逻辑不完善，漏洞比较多，然后查问题比较慢。不过还好问题比较少，整体没有耗费太多时间。
第二年下半年里，开始做一个新的iphone上的阅读客户端，当时基本上是从头开始，没有用户量，也没有流量。一个哥们R给我安排事情，每次把事情的来龙去脉讲的特别清楚，怎么做，为什么这么做，都讲的很好。这对于我提高经验帮助很大。从那开始，我具有了分析业务细节的能力。
第三年上半年里，从一个新需求的具体程序员，开始转向后台功能。是另一个哥们N移交的业务给我，一个核心的模块，文章的评论。这里的更新机制，速度优化策略，整体业务逻辑，产品特殊需求，都跟我介绍的很清楚，拉上我一起分析如何优化，如何从后台功能去思考一个新需求的实现。收益良多。
第三年下半年里，我开始独立负责开发新需求，能够从全局的角度开始思考业务的整体实现细节。我接到新需求之后，开始消化和设计，将整体方案跟同事N进行商量。同事N提出了很多质疑，我能解释的解释，不能解决的就把方案拿回来继续思考和优化，最终从他那里通过了，然后开始动手开发。这个时候对代码的处理能力就已经是比较强了，代码质量很高。不但能够整体规划代码分割方法，还能够很好的实现细节的容错。但是感觉当时对进度的把握不够好，总是为了保证质量而拖慢了节奏。于是领导并不是很满意。
第四年上半年里，不但能够结合现有业务特点，对新需求做评估，还能够找到业务的瓶颈，进行优化。同时，业务节奏也把握的很好，能够快速上线见效果。领导开始有了新的要求，那就是不但要做好自己的业务，还要能够协助其他同事，必要时出来补位。这里就需要平时关心和了解其他业务的逻辑，持续关心。由于准备了一次技术答辩，了解和学习了很多东西，有了很大提高。
第四年下半年里，团队里面熟悉业务的人很少，我成了核心开发。指导新人去做任务的同时，也开始思考业务上的深入问题，经常pk产品的需求。也经常突击完成领导下发的工作任务，做一个能啃硬骨头的后台开发。这个时候还需要提高基础能力，把知识体系完善，学习更多的东西。
主要体会：
1.了解需求的人永远掌握主动权
不管你是什么级别或者水平的开发人员，如果你不了解需求和业务，你就没有发言权，你的所有构思和创意都将收到挑战和质疑。因为架构和资源都是围绕产品属性来定义的，一个架构如果费力实现，最后发现不适合业务逻辑，重构的代价是很大的，风险是很大的，责任也是很大的。在不确定性面前，谁知道的更多，谁就掌握了发言权。谁能确认，谁的主导权就更大。所以产品思维对于开发人员来说是很重要的，你比其他开发更懂产品，那么你就更能够选择合适的架构和实现方法。
2.不是所有的事情都要现在做，但是要保证以后做也很容易
你是开发人员，那么你知道某个东西的重要性，开发的复杂性，耗费的时间。当然，你不知道，你可以持续锻炼，最后掌握这个能力。但是对于领导和产品同学来说，可做可不做的东西其实很多。那么他们是要求你做还是不做，现在做还是以后做呢？如果现在做了，耗费大家时间，整体工期拉长，情绪不高。要是不做，那么领导过问是责任，后续不能实现了，产品同学就不敢承担这个责任。所以，如果你说某个东西，产品认为不太着急或者不太重要，那么你要及时告知，这个东西以后补上也行，很容易。产品会很乐意放过这个需求点，大家都轻松。
3.要在领导定的基本框架内做事情
不要认为自己突然想到的颠覆性的想法多么的牛逼，任何已有的东西，如果是用心做出来的，都不应该被颠覆，都是有其适用性的。所以，在前人的框架内做事情很重要，领导容易对你放心，你也就更容易放开手脚实现自己的想法。如果你挑战了领导的基础逻辑，你将付出更大的时间成本和沟通成本，最后领导还要质疑你的做法，如果有问题了，那么就是搬起石头砸自己的脚。
4.不要挖坑或者少挖坑
没有经验的人，需要多多细致思考方案，那么这样做出来的东西，比较容易达到自己的最佳水平。如果还能够得到资深人士的认同，那么这个方案就具有很好的实践性，坑也会比较少。在麻烦和坑面前，宁愿自己辛苦一点，也要让整体流程轻盈顺畅，查问题和节点方便，监控和追溯方便。如果加加班能够把一个事情做的特别漂亮，那么就加班吧，完成之后你会睡的更加踏实。
5.专业的人做专业的事情
这句话看上去是提高效率的一句话，在任何人之间的配合上，肯定是这么分工处理的。在不同的项目组合作的时候，特殊情况跟这个不太一样，一般情况下也是如此。特殊情况是，你不做点事情领导就不放心，这时候与你无关的事情，风险比较小的，你也要找点来做。在代码处理上也可以这么做。逻辑按照功能从代码文件上做到分开，保证最高效率的个性化调用能够实现。同时，跨项目组合作的时候，使用接口、透明调用、透明传输、各自处理熟悉的部分等等，都是很好的办法。
6.有时候不是努力就可以的
这个就是人际的含义。有的人，一开始就注定是接班人，你争不过他。你的成绩有时候跟你处于的位置挂钩，也许你做的事情没什么含金量，不牛逼，但是这个位置重要，领导同样对你刮目相看，器重有加。在领导需要有人在岗的时候，你的应答声会格外有力。不是努力就可以，不努力肯定不可以。在合适的位置努力，风口上的猪都会飞。
7.已知不好的代码要尽快修改
每个人都有青涩的过去，代码也是一开始就质量很高，但是随着你能力的提高，原来质量不高的代码要尽量修改掉，不然把缺陷留到最后，只能带来后来人对你代码质量的嘲笑，甚至让新人鄙视你。及时优化，及时修复，让你保持最好的姿态和状态。
最后，技术的提高是缓慢的，且行且努力。
8.替代性的好与坏
如果你的工作是无可替代的，那么你的低位、收入会较其他职位更高。也正因为如此，所以想完全脱离一段时间都是不可能的，导致你不断加班，不能正常休假。后台开发是不可替代的，一个萝卜一个坑，而测试则可以随时换人。
9.一个不靠谱的产品，累死一个技术团队也拿不出一个像样的东西
这也基本是做了几个项目之后，技术人员的共识。产品逻辑评估不到位，导致需求频繁改动，细节调整特别多。在产品需求细节比较模糊的时候，不要做任何事情，否则你将对不起自己的劳动和时间。