程序员现状，看看来自二三线城市程序员的真实感受

2022年3月，乌鲁木齐市，95年26岁Java后端程序员。

我先后在乌鲁木齐市两家互联网公司工作过，通过自己努力的思考，总结出了一些对程序员现状的看法，供大家分享和参考。以下内容全部属实。

很多人会觉得程序员是高薪行业，并且有人会说朝九晚五双休，工作清闲还有业余时间去做其他事情。

我来揭晓真实答案。真实答案和上述情况基本完全相反。

真实情况我的城市，程序员的薪资算不上高薪行业，不是行业平均薪资不高，而是这里很多中小企业都会考虑降低用工成本，在招聘的时候用各种方式打压你的薪资。

这种方式尤其对新入行的程序员特别奏效。因为企业打压你工资的方式有很多种，而新入行的程序员根本就没有与企业谈判的资本。或许你入行时技术功底扎实，开发水平相对较高，又或者你学历很好，综合能力很强。但是企业依旧会以你没有工作经验，以及试用期，或者说培养你都需要付出成本，找人带你教你等等一系列举措，让你哑口无言只好接受企业的用工要求。没有能跟企业谈薪资的能力。企业最后会以一个较低的薪资利用你为企业创造更大的价值。

而处于新手阶段和试用期的你，想要获得企业的青睐获得转正的机会，会更好的去工作提升以及转正。这样你会在试用期努力工作，为企业创造效益。这个时候大多数程序员都会想，薪资低一些活多一些累一些也无所谓，因为这时候在锻炼提高自己的工作能力，对自己其实也有很大好处。企业也同样利用员工这个心里，不停的激励你去工作。而企业只是付出了很小的成本，利用新人的你去做了很多又苦又累的活，而你还不自知。这样企业很开心啊，而你除了努力付出工作和锻炼，钱却没有收获进口袋里。

你以为你能力锻炼了就会对应的拿到较高的薪水的时候。但是你别忘了，小企业把程序员当码农并且降低用工成本的核心思想并不会因为你的技术提升而发生改变。

企业依旧会以招最少的人用最低的成本让员工干最多的活去运行，并且项目大人员少，这样上线前一个就有理由让你加班，并且告知你是不可避免，去要求你加班工作。我自己的真实经历是连续加班一个月，并且在每天正常下班之后还需要额外加班5-6个小时，工作日连续五天加班后，周末再额外加班一天的强度去工作。基本就是一天工作14个小时一周工作6天，这么个强度。而且企业并不会在乎你是不很累，加班不会付加班费，而是以加班可以调休的方式安慰你。然而你想想这种小公司，并且开发人员企业不配备很多的情况下，怎么会让你调休。调休是需要上级领导项目负责人到经理，一系列人的签字的。可想而知，调休说是有，基本想想就可以，不会让你想休就休的，哪怕加班很累，第二天还是要上班。因为你不干就没人干，但是公司项目需要上线。而且你的工作每天都有人监工，你就负责干活就好，让你做什么就做什么。这样你还会觉得程序员薪资很高吗？

现在企业都知道招年轻人，刚入行的新人最好。因为他们没有太多经验，好对付，便宜而且干活又卖力。哪怕有几个不上进的水平差一点的，也会有人监督你把每天的任务完成。怎么说企业都不亏，所以企业能用新人和年轻人为何还会选择你要求薪水高的人呢。你以为你技术上去了，可以跟企业要高薪的时候（其实也不高，就月薪过万而已），以你的技术可以拿到月薪过万的时候。企业依旧可以通过各种方式降低用工成本，或者压根就不录用你。比如试用期只给你80%薪水，哪怕企业知道你经验很丰富，也利用试用期少给钱让你多干活快速熟悉并进入开发。会以工作年限限制你的薪水，你说你水平高怎么证明，其实就是企业不愿意承认和付出更高的成本而已。哪怕你技术很牛学历很好，一样会面对这样的问题。等真到一定的工作年限的时候，你会发现头发和精力和兴趣都会少很多。你再去跟企业谈薪，你还会发现企业还有方式降低用工成本。你有家庭吗，你能加班吗，对你提更高的技术要求等等。虽然总的来说薪资会有一定上升，你想要拿到一个满意的薪资很难，因为你满意企业就会不满意，企业不会为了照顾你，而降低自己的企业的效益。

这就是现在绝大多数程序员现状。付出很多，承受很大的压力，赚取来一点辛苦钱。而且现在程序员绝大多数都会有35岁危机。这行业想要做好是有一定门槛的，还要有抗压能力和很强的学习能力，理解业务的能力。现在你还觉得程序员这份工作好干吗，高薪吗？那些年薪几十万的都是一线大厂的少数人。中国绝大多数行情，程序员就是底层的码农而已。付出这么多，收入稍微比普通职业高了那么一点而已。一样会面对买房买车的压力。谁也没比谁好多少。没有太多业余时间发展爱好，接触更多事物，压力大。绝大多数时间在跟计算机打交道。每天面对电脑的时间很久，一坐就是一天。

我这两天也是刚离职，因为企业不招人进来，就五六个人干一个项目，还加班。当你去面试的时候一大堆企业要招你，但是能给你满意薪水的企业的数量直接就大打折扣了。

当然企业不给你满意的薪水，也不代表你不好，这只是畸形商业模式下的企业招人的方式而已。你要相信自己其实比很多人要优秀。

否则企业会让你怀疑人生的。在一个没有装修过的小房间当码农的感觉亲自体会一下就明白了。就像不被企业在乎的流水线工人埋头苦干。

遇到这种情况程序员们一定要坚持自己薪资的底线，不要让企业或者根本不懂技术的hr 轻易的压低你的薪资。而你却选择默默接受。虽然我们是打工人，但是面对这样的企业也要坚持自己的原则，去进行双向的选择。并且为自己以后的发展做好规划。

希望程序员们都能找到一家满意的公司，去发展。人生只有一次，不只是工作，一定要按自己喜欢的方式去活。

这就是来自二三线程序员的真实现状。你们怎么看呢？欢迎在评论区留下你的看法。

既然他这么说，而且他有十多年的工作经验，那肯定只看出了你工作上的一些弊端，那你可以虚心的请教他，你也应该转换一下工作思路，因为程序员这工作比较枯燥，但是也不能太死板。能尽量写短一些的代码就完成工作比绕个大圈写一堆代码完成工作要好得多呀，效率也高。

作为一个程序员，最重要的职责就是： 按时保质保量地完成需求开发。

像开发新业务这样的复杂需求， PM （Product Manager，产品经理） 一般会写出详细的 PRD （Product Requirement Document，产品需求文档） ，甚至可能会制作高保真原型。

而像调换两个按钮顺序这样的简单需求，PM有可能只会口头通知一下，最多在JIRA之类的项目管理平台上创建一条只有标题的ISSUE。

如果是有和用户交互的需求，负责设计的部门或人员一般会提供设计图。专业一点的话还会帮你把图都裁好，并准备不同屏幕分辨率下使用的多个尺寸版本。

当然，如果你在一个刚刚成立的创业公司，很有可能是创始人在白板前（或者是饭桌上）讲了半个小时，然后就问你：“需要多长时间把它做出来？”

不管提出需求的是PM还是创始人，他们的脑海中一定为这个需求设想好了一个自洽的逻辑和形态。PRD也好，口头宣讲也罢，都是在描述这个逻辑和形态。他们提出需求，就是希望程序员能够最大程度地还原他们的设想。

说起来简单，做起来难。 我们可以通过一个小实验来揭示这一点。

首先，你需要找一张长方形的纸。如果你在办公室，那就找一张A4纸；如果你在家，那就找一张纸巾。然后按照下面的步骤进行 *** 作：

你的作品是什么样子？中间开洞了吗？边上呢？角上呢？如果再做一次，你能完成同样的作品吗？

你可以拿着同样的纸去找你的家人、同事或朋友，请他们来完成同样的 *** 作。在你不施加影响的前提下，他们完成的作品极有可能和你截然不同。

为什么会这样呢？

如果你仔细观察他们 *** 作的过程，就会发现：

由于每次对折都会可能产生两种不同结果，在撕第一个角时纸的朝向有四种可能性，旋转180度时有两种可能。所以仅仅两个撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 种不同的可能性。

就这样，我们还没有考虑撕角的大小、角度的区别，还有极少数人是会沿对角线对折的……

上面撕纸的需求，其实是我自己拿了张纸随意摆弄，然后记录下来的 *** 作流程。我照着这个流程，可以十分轻松地做出完全相同的作品。但是如果让别人来做，结果就完全不一样。其原因就是，我在完成作品的过程中，不光是按照流程进行 *** 作，还隐含了自己的一些小习惯，却并没有把这些细节记录下来。

如果把所有细节都完整地记录下来的话，需求应该是这样的：

同样，PM在写PRD时，很有可能会漏掉一些自己认为应该是「常识」，无需再进一步说明的内容。比如「把一张纸对折」，我们很容易想当然地认为，应该是沿着长边对折，但事实上并非所有人都是这么理解「对折」的。

由于每个人的成长经历不同，其认知结构之间必然存在差异，因此对同一概念未必持有相同的理解。 你所认为的「常识」，我可能并不知道，或者拥有和你截然不同的理解。所以程序员在看PRD时，一定要把自己对需求的理解复述出来，跟PM确定是不是这么回事。否则就容易出现开发中、提测甚至上线后发现逻辑性错误，需要紧急修复甚至返工的情况。

此外， 很多问题在设想阶段是发现不了的，只有到了具体实施时才会暴露出来。 PRD不可能真正做到完备，也不能保证没有错误和遗漏。比如一个表单需求，很可能在做的过程中发现某个非法数据case是PRD里没考虑到的，这时的用户交互怎么做？文案怎么定？这都要和PM沟通来解决，而不能自己拍脑门决定。

PRD只是需求的一个快照性描述文档，并不是需求本身。 程序员应该对需求负责，而不是对文档负责。 只有和PM保持沟通，不断地细化需求，才能让需求真正落地。当发现PRD里有不合理或者有疑问的地方时，一定要提出来让PM进行解释。千万别视若无睹，甚至干脆将错就错，等着看PM笑话。

如果我们拿到了一份图文并茂、十分详尽的PRD，是不是应该马上照着文档开工呢？那可不一定。

一位优秀的程序员，应该在开工之前把下面这些问题想清楚：

程序员有责任对需求方案进行review，并协助PM改进设计。 要知道，PM一般不会从技术角度对需求进行考虑，所以往往提出的并非最优方案。有时只要做一点点调整，技术实现的难度就会大大降低，却不影响目标的达成效果。

比如某个业务需要用到日期选择器组件，PM为此专门设计了一个，而你知道系统中某个功能页面里有现成可用的同类组件。这时就应该和PM沟通是否可以直接复用，或者在原有组件的基础上进行功能扩展。这样既节省了开发资源，又保持了用户体验的一致。

程序员要对整个产品的可用性负责，全面评估需求可能导致的不良影响，谨慎对待有破坏性的需求。 PM由于不了解系统的底层实现和实际数据的组织方式，所以很可能无法全面地评估需求的影响面。如果程序员忽视在这方面的思考，只是机械地按部就班地执行方案，就很可能导致严重的线上事故。

比如要对某数据进行批量修改，在做的过程中时发现该数据有多个业务正在使用。这时就应该必须停下来和PM沟通，因为PM可能只了解自己负责的那一块业务，不知道修改可能会对其他业务产生影响。此类需求要和相关各方沟通协商，确认修改没有不良影响后才能继续。

程序员要有魄力去拒绝那些明显不靠谱的需求。 有的时候，PM提出需求的动机不是为用户创造更多的价值或提升用户体验，而是为了冲绩效完成自己的KPI。为此拆东墙补西墙，从兄弟业务手里抢流量入口；甚至杀鸡取卵，以严重破坏用户体验的方式拉量。遇到这种事，程序员一定要坚持自己的原则，守住自己的底线。

天赋可以对成为一名优秀的程序员有一定的帮助，但不是必要的条件。更重要的是，成为一名优秀的程序员需要大量的学习和练习，以及对解决问题的热情和耐心。

虽然一些人在编程方面可能会比其他人更有天赋，但这并不意味着其他人无法成为优秀的程序员。相反，通过不断地学习和练习，任何人都可以逐渐提高自己的编程技能，并成为一名优秀的程序员。

此外，作为程序员，除了技术方面的能力外，还需要具备良好的沟通能力、解决问题的能力、团队合作精神等软技能。这些能力同样需要学习和练习，并不是天赋所能决定的。

                                 

以上就是关于程序员现状，看看来自二三线城市程序员的真实感受全部的内容，包括:程序员现状，看看来自二三线城市程序员的真实感受、我是干了八个月的程序员，干了十几年的同事给我说我脑子不灵活，思维严谨，我是不是该转换一下做事思路、作为一名程序员，你真的理解需求吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！