【51CTO.com快译】在开始之前，我先介绍介绍自己的情况。我在一家大公司工作，同事们很好相处，而且公司允许居家办公。我专门撰写技术类文章及编写代码。当然，我也在工作当中遇到过种种困境。另外，我能在企业裁员之前有所“预感”，并提早做好准备。

下面进入正题，如果您遇到以下九种状况，请考虑为自己找位新东家。

1.您的系统被称为遗留方案

如果您目前的工作是打理某些“遗留系统”，那么请马上整理简历、参与培训并在可能时多学点新技能。相信我，这时企业已经开始物色新的人选来构建新的业务系统，而这一切都将与您无关。

也许这样的判断并非百试百灵，但请相信我，我过去几年中曾经收到了不少这类简历：从业者在两到三年内没有学习任何新知识，并在一夜之间丢了工作。因此，提早为风险做好准备往往是成本最低的应对方法。

2.未受邀参加您以往曾经参加的会议

无论出于个人、专业或者技术原因，如果您被排除出定期会议之外，往往意味着您的工作可能不保。

3.顽固的老板会给多样性带来巨大打击

歧视问题无处不在，而且很多时候表现得并不明显。这意味着可能在进行同样的工作时，老板专门把您挑出来批判一番; 老板为您设定的工作标准与其他同事明显不同; 或者您得到的奖励更少。

可悲的是，这类状况始终得不到良好解决。总而言之，不管您代表着怎样的多样性，都有可能因此受到老板的打击。面对这样的状况，不要勉强忍耐，选择真正接纳您的工作环境显然更为明智。

4.缺少质量标准

有些企业认为需要“商业动力”来推进单元或者负载测试编写工作，甚至有些企业仅仅会对帮助其找出问题并调试生产bug的员工简单表达“感谢”。别说了，赶紧走。

5.自上而下型设计/管理机制

我并不是自上而下传达架构或者业务要求有什么不妥。我的意思是，在某些企业中那些头头脑脑总爱胡乱掺和并提出一些大家都知道根本不可行的主意。快快离开，这种管理思路只会带来恐怖的软件成果与失败的开发项目。

6.极度崇拜敏捷原则

最近，某家咨询公司制定了一份“敏捷流程”图表，其看起来就像是份傻小子规划的地铁路线图。实际上，甚至有人认为这份图表是软件开发过程的最佳体现。

毫无疑问，采用SDLC/瀑布式开发流程还是敏捷方法应当视具体情况而定，且大多数情况要求我们将二者相结合。但是，偏有很多人喜欢单纯从理论出发并将仍然有效的现有方法扔进垃圾堆。如果大家希望开发能够实际起效的软件，那么这样的环境显然非常恶劣。

7.发布书面的PIP或者负面评论

一般来讲，管理者们解决问题的最好方式应该是与对应人员直接交谈。如果他们更倾向于发布书面性质的负面评论或者绩效改进规划（简称PIP），那么意味着其已经在考虑将您炒掉了。

8.随意发布新的“必须完成”要求

我曾在一家企业工作过，其经常给出大量变更要求且必须在短时间内完成。开发者们往往得通宵达旦才能完成这些新增工作。而且不出所料，这种急工赶出来的结果往往非常糟糕。

当然，在某些管理者眼中这就是“敏捷”原则——他敏他的，咱走咱的。

9.同一问题反复出现

如果您所发布的软件反复遭遇同一问题，而团队成员又拒绝改变其工作方式，那么请尽快离开——别被这帮同事带瘸了。

原文链接：
http://www.infoworld.com/article/3150292/application-development/9-signs-you-should-quit-your-programming-job.html

原文标题：9 signs you should quit your programming

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】