工作十五年的路过

工作十三年的路过

硬汉啊，给PO主支持了

又一个水军～～～

要遵从科学的学习方法，先整体后个体，先框架后部分，先浏览森林，后模仿一棵树。如果我能早点认识到这些，那我当年就不用那么痛苦了。
很有同感

恩，这类文章还是比较少的，看看

写的不错，对我们这些马上毕业的人有指导作用。

三年是会不爽的，我也是第三年跳槽了！刚开始也有恐惧，但是不断地面试，不断地和各个公司的管理人员聊，慢慢就恢复自信了，后来就跳槽成功了！

4.换岗之殇
因为业务调整，整个部门需要搬迁到外地研究所。
我因为不适应外地的生活，返回总部，到新部门报到。
这次岗位的更换，对我是个很大的挑战。从一个已经很熟悉的业务领域，跳到一个新的领域，几乎是从零开始，这需要不小的勇气。更何况是我从设计又跳转回编码。我是纠结了好久，还给公司一位有名的人力资源领导写了一个邮件，倾诉了自己的一些疑惑和看法，她人很好，虽然在高位，但还是尽心的给我回了邮件，非常感谢她。我最终是抱着慷慨赴死的决心到新部门报到的。
我刚过去报到时，刚好新部门正在进行一个大版本的开发。新部门的业务是用C++，大家都知道C++就是一个混合体。我重拾C语言，并开始学习面向对象的编程，更是一边重新加强自己原先那点可怜的计算机基础。只是我太过羞涩了，进步太不明显。
记得在新部门接手的第一个开发任务是，重构日志模块，构建日志的格式定义/级别定义和日志收集等各个API。记得当时版本SE是一个很有气场的家伙，动不动就喜欢用一句“我跟你不是同一个级别的，我不跟你争论”把对方噎得一句话也说不出来，但我到现在也没发觉他有多厉害，也许是我真的跟他打交道比较少吧。有个交集的地方是：大家当时对于日志模块是归属于公共模块范畴还是OM范畴，没有一致的意见，有过一番争论，最终具体是放在哪个范畴已经不记得了，我当时只觉得这个新系统有点怪，怎么会有这种问题的争论，归属于哪个范畴都无所谓，关键在于你是如何定义你的系统。
在这个部门有过争论的一次是：和版本经理讨论过需求分析和方案设计的方法过程。其实说争论也不太对，说交流更为贴切。版本经理是一个女孩子，温柔是女孩子的天性，所以根本没有版本SE的那种盛气。交流过程还是挺愉快的。

说实话，这个新系统真的让我感觉很不好，混杂了太多东西，整个框架让人很不舒服。后来我在这里遇到我原来部门的大SE，一个很牛的家伙，写了很多专利，其中不少还是基本专利/杀手专利。经打听才知道，他是被拉来撑起这个部门的技术水平的。确实是牛人，过来新部门之后，他继续每年都有不少专利产出。
很不幸的，这个部门后来也搬迁到外地研究所，我又一次要跳到别的部门，开始从通信领域踏入IT领域。
回顾这次部门的更换，从开始考虑换部门的纠结，到刚报到的紧张，再到努力适应，这几乎是我后续换部门必经的心路。不管怎样，我克服了自己的心魔，在新天地中，努力找到属于自己的位置，没有困死自己。有一句话说“强者到哪都能生存”，那位大SE就是属于强者。
没有绝对的安稳，唯一不变的就是变化。

四、转战IT
1.一个跳板
在通信领域干了3-4年后，因为工作需要，首次进入IT，是去搞小型机。
小型机看起来很高端，其实我们涉及的只是皮毛，什么虚拟化等等核心技术真的太难了。
我参与的地方很简单，就是做BMC部分的优化，用C语言，所以又回到写代码的阶段。高端的技术没法参与，处理的都是比较简单的事情，况且也不属于正式的产品，那段时间相对来说比较空闲。人天生就是懒惰的，所以我平时没事情干的时候，就是看看小说，乱七八糟学点东西。当时身边有位同事，名校出身，对计算机和软件方面理解还是很深的，起码比我强很多；所以，遇到一些困难经常请教他，可惜都只是工作上的事情。人的惰性确实挺大。
可以猜测，公司对这个东西肯定做不长。确实如此，半年后这个小部门又拆了。我在这半年里，没什么进步。现在想起来，后悔的就是没珍惜这段时间，好好补回原来薄弱的地方。

2.和数据结下不解之缘
这之后转入一个刚建立的全新的产品，这次转换很大：编程语言转为JAVA，彻底的正式的IT产品。
我所在的项目组，主要是负责数据的收集、分析（轻型的数据挖掘）和供检索，所使用的框架涉及到当前比较流行的hadoop、数据挖掘和搜索等各项技术，所以技术还是比较新的，部门各类技术的人才储备也很齐全，大家野心勃勃，充满干劲，就想做一番大事业。
又一次的，我兢兢业业从头开始学习，包括JAVA各类语法、面向对象编程思想和JAVA编译以及运行的各类知识。经过大半年的磨练和实践，才慢慢掌握了JAVA编程能力，感觉收获还是蛮大的。跟以前相比，这是一个全新的领域。
磨练一年后，我被临时安排带领几个人做报表收集和分析，这也是我第一次带领一个小团队，同时还负责整个产品的编译环境，这个编译环境功能很大，从代码静态检查/编译/做包/环境安装和基本功能测试，全部都是自动化的。所以，那段时间特别忙，每天都要搞到晚上10点多，白天经常开会讨论问题、澄清各类设计问题和搞管理协调工作，至于编码则几乎只能到晚上。
这个过程中印象比较深刻的是对数据计算，我们经常要算最大数据量，看数据库能否支撑，对内存冲击多大，对I/O冲击多大等等，刚开始我们想当然的都是以最大数据量来计算，结果几乎给出一个天文数字，后来我们一个SE认为我们的计算模型不对，这种统计思路是有问题的，他给了一个全新的数据模型，抹平了很多数据尖锐的地方。群里有些人讨论程序员对数学的掌握该到哪种程度，有不少人回复就是到高中就可以了，大学数学几乎用不上，我每次见到这样的回复就想骂人，你不懂就别装懂，你水平差就别让别人也变得跟你一样的差。不怕不懂的人，就怕不懂装懂或半懂不懂的人。井底之蛙，没见过外面的天空就别嚷外面没什么。

顶楼主，看着这个有些心酸啊，坚持着走着。

"感觉自己对系统就懂那么点皮毛，但又不知道该如何下手，特别的愁，压力自然也是特别的大，那个时候睡眠挺不好，特别的盼望周末，因为一到周末就可以狠狠的睡懒觉。"

这段话可以理解为懒惰。若在校这么说情有可原，没有实操经验。工作1年半时间都这样，只能说明你不热爱这份工作。

通读下来，楼主过谦了~~其实应该混得很好。向你学习~

期待下文...

今天我走的是小清新路线,所以,我只是轻轻地

3.接触web开发
等这个报表小项目差不多结束的时候，我又被安排带一帮外包做小型视频网站，收集实际数据验证我们的系统，这也是我第一次参与到web开发中来，从零开始，接触了一些web开发的东西，包括PHP，JSP等。真的是白纸一张啊。
我负责设计整个架构，包括数据后台和视频web的接口（说白了就是读写数据），至于视频web，几乎由外包搞定，我只对web页面效果做了要求。然后我参与了各个接口的开发，搭建了环境，并给领导和同事们做了演示，后来就开放给公司内部的同事们。这个视频网站大概跑了大半年，效果还不错，达到了原先的目的，唯一不好的地方是：实验室带宽有限，人多的话，网速远远不够。
项目的真正运行，让人有份不小的成就感，看着弄出来的东西，大家在实际的用，这是搞技术的一种幸福，虽然技术含量也许不高。

楼主真是做得多啊，厚积薄发还是只做一点有时很难说哪个好

4.再做一条龙
2012年开春，老领导召集了我们一帮老员工，开始一个新项目。我仍然负责数据的收集、分析和检索。
这是一个全新的项目，所以，我们从头开始分析所处领域和讨论架构。并接受各类基本需求，做设计方案。几乎每个SE都参与了需求分析/方案设计等前端分析工作，并参与了后端的代码开发、编译和调试，做到了端到端的交付。我们那段时间干得非常有热情，不管是周末还是晚上，都经常加班，几乎是在不到2-3个月的时间内，就调通了基本业务，为此领导还特的发了一个表扬邮件。所以，大家虽然辛苦，但干活的过程还是很充实的，研发屌丝的幸福点可见很低。
这个过程确实很锻炼人，并没有多少机会能让你从头开始搞一个新东西的。而一旦把东西搞出来之后，其中的成就感能大大增加你的自信心。
这段开发实践也推翻了原来那种所谓开发与设计分离的错误定位，设计人员一旦远离代码，他们对产品的敏感度将会越来越低，这绝对是个灾难。打破这种开发和设计的沟壑实在太有必要了。当然，并不是说所有的研发都要参与代码，架构师级别的就无需再参与到代码了。
这个新产品其实并没上面所说的那么一帆风顺，后来我们在可靠性和性能方面还是遇到很多阻难，在整个一年多一点的研发期间，可靠性和性能上的问题占去了一半有余的时间。后来我们经常感慨：可靠性和性能才是最大的敌人。
在市场上，因为实际情况有变，领导们决策新产品还需继续等待市场，我们这帮研发人员释放到别的部门。
所以，苦逼的我继续流浪。
不管如何，这段时间是我在参与工作之后，进步和收获最大的一段时间。

顶了123456

顶 楼主

支持顶顶顶，，，别沉了。。。。

这是神回复啊

顶顶....