到底该不该离职？
由 clear 发布于 2014年02月26日无人欣赏。
去年10月份PHP培训毕业，10月入职现在的公司，到现在也快四个月吧，还没转正，可能是刚开始的时候表现不好，分给的任务没有做好吧，给主管留下了不好的印象，现在总是感觉收不到重视，在公司也只是做一些对公司原有系统的修改【都是几年前的老项目】工作，有点想离开啊，但是还是感觉自身水平不高，给点意见吧
1、还没转正，你也说了，是自己表现不好，不是公司的原因；
2、受不到重视，不是做核心工作，这也是因为你没有表现好，你放心，大部分老板都很精的，不大可能会大材小用的；
3、想离开，你也说了，感觉自身水平不高，去别的公司就会比现在的好吗？
我的建议是，好好做好现在的工作，只有把小事做好了，老板才会把大事交代给你做的。
维护这种东西吧，确实学不到新东西，也挺枯燥的。说白了就是经常会遇到“我操，怎么写得这么屎”这样的事情。但是事实上这里才是最锻炼人的地方，因为有很多现成的代码看，而且你可以看到设计失败的地方，你也有机会去做（有限度）的重构。
以我的个人经历来讲，很多时候一个人开发/设计/架构水平高不高，不是看一开始做得有多快、多好。一张白纸随便画，想怎么快怎么好都是可以的。关键是一种平衡感要找好：技术与队友之间的平衡，功能与时间的平衡，现在与未来的平衡等等。那些你看这很烂的东西，很可能是在当时特定状况下发生的取舍问题，或者是无意识的取舍。
举一个例子，比如你看代码很烂，有可能队友的水平就这样。你设计复杂了这些队友反而不会写，甚至给你来一个深度退化过程。比如微博上王四哥等人经常吐槽印度同事写得咖喱代码，你要是理解了人家就这水平，你就要设计成他们能写、而且还写不坏的方式。很多时候你看那些设计模式，感觉高大上。是的，理论上用了很高大上，但是实际上这些队友有可能根本就弄不清，回头三下五除二就把你这些精良的结构给拆了。这种事情我见得多了，就算在国内的时候也如此。其实有的时候所谓的封装，就是为了防猪队友的，把表面做得好像很简单的样子其实把里面搞得比较复杂，就是为了让他们不要碰那些实际上就是很复杂的东西。
包括语言的设计进化，其实很多时候也是朝着这方面努力的。比如C#引入的LINQ，你看看背后的机制（编译器，库什么的），其实真的比你想象的复杂多了。但用起来就很爽，而且在同一个问题下面，要写出很难理解的代码是需要一定的努力的。（其实就算是这个Linq以及Lambda，就有些人受不了，看不懂，就会有人拆台。）
另外，陈旧系统通常已经承载了比较大的用户量、压力什么的，不像一些新系统看着好像很光鲜，一压就垮。换一句话说，那就是那些老系统也经过这一个过程，一定有人对这些问题进行过修补。你要是仔细看看一些奇怪的修改，说不定就跟这些东西有关。其实也是另一种了解为什么有些设计会是失败的，为什么那些前辈（有聪明有愚蠢）会这么改，他们的思路是什么，哪些是成功的，哪些是失败的。
过去我在老系统里面，通常至少会投入半个牛人进去，因为我知道擦屁股这种事情绝对是一种高智商的活动：首先你要理解这个庞大的系统，理解他过去为什么这么设计，后来改过什么，为什么这个改；然后才是了解现在发生了什么，要改什么；最后，改的时候还会有很多兼顾历史问题和未来发展的一些约束，才能够改得好改得漂亮。
但是绝大多数情况下，大家并不会这么想问题，自然也就学不到什么东西。是的，这种工作很枯燥，外面不知道你在干什么。搞好了是应该的，没搞好就会挨骂，虽然随地大小便的那个其实不是你，而是那些之前的猪队友。很多人会说：真的很没有成就感，包括不少我觉得智商还可以的都是这样，俗话就叫做耐不住寂寞。所以尽管我会投入至少半个牛人，很多时候我是不敢长时间指派固定的那个牛人的，生怕人家心生不满走了。
接着说一些黑暗点的事实：为什么擦屁股这种高技能岗位很多时候会长期指派能力一般的人呢？因为走了不那么可惜。
再来一个光明一点的事实：如果你擦屁股擦出花来了，那么大概基于上面一个考虑，你是可以拿到更大的话语权的。
话说本人主动请缨擦屁股，擦了5、6年吧。后来的结果就是，整个系统里面只要有我不懂的问题，那就是没有人懂了。擦屁股快准恨，其实是一个很牛逼的技能点，不是随便一个人都能够轻松点亮的。撇开对系统的熟悉程度不说，其实逻辑能力很重要，对于基础知识的了解深度广度也很重要。后来我看得上的几个人，对于同一个现场突发故障的判断上，我都会有一种深深的“导弹圆概率误差过大”的感觉，或者难听点就是一把散弹枪，对着差不多的方向喷一下，期望自己运气好小概率事件必然发生在自己身上，瞎猫碰着死耗子，守株待兔。
擦屁股绝对是一种将散弹枪调教成为神狙的活动，当然了，除了你愿不愿意持续参与之外，还有你这块料能到一个什么程度的问题。很多人擦屁股的思路，尤其是新手，是 现象->可能性->一定是这样的->解决->失败->再来N遍->终于成功了->“为什么？不知道”。很多时候他们会瞎编一个自己以为正确的解释，我一看其实那个修改就是错错刚好凑巧得正确，危害性很大。而正确的思路其实是 现象->可能性->证据->故障点->原因->证据->故障点->一直追查->找到根源->验证->解决方案->修改->验证->成功。《==好像有点点离题了。
至于你的具体情况，还是留给你自己分析吧。反正呢，我的观点是，无论做什么，刚开始时的时候一定是有很多东西可以学的。当你觉得没有什么有价值的东西可以学的时候，就该离开了。这里面很重要的一点是：你能看到什么有价值的东西。比如有的人在荒凉的地方只能看见石头，有的人能看到石头有很多种比如钻石，还有的人还可以看出这个地形下面有石油。你是哪一种呢？
哦，还有一个问题取决于你带了多少干粮。钱少事儿多压力大，自己没房没车有老婆，这种情况下你做出一些显然的决定我觉得是可以理解和鼓励的。不过话说回来，你离职换一个多好的地方取决于你有多少的资历和能耐可以炫耀。也有可能换换还不如不换的情况。
P.S.: 我喜欢来黑暗点的东西：现实是很多公司的人力包括招人的经理，对于如何招人如何衡量一个人的水平等实在是很一般，以至于其实他们只看你从那个公司出来，有多少年的经验等等。我曾经有那么些个下属同事，水平真的是渣到了说不懂做不出的程度，居然跳槽后double……当然了，这也有互联网当时的大环境，以及前东家自身的一些奇怪问题。我的意思是，尽管我上面说的都是自认为对的东西，但是有的时候世界在有限时空内是按照一种反直觉的方式运行的。浮躁而愚蠢的人，有的时候也可能比一些潜心下来深入研究的人有更好的结果，有的时候。
太浮燥了，如果是维护，把整个个系统的代码通读一遍 然后去思考为什么会这样写，不懂的function 多看手册 你的成长这样就会很快的， 一般很少从0开始的工作， 然后再多读一些 比较流行的php框架和程序的源码