关于问题程序员为什么是个青春饭，而不是像医生律师一样越老越值钱？一共有 2 位热心网友为你解答:
【1】、来自网友【华为云开发者联盟】的最佳回答：
分享菊厂一位 20 万行代码哥的经历：
“你肩上扛了 20 万行代码，搞得定不？”这是我刚进华为时听到最多的一句话。
2008 年 9 月新员工培训完，我没有回西安，而是直接飞到上海承接产品。刚进上海项目组，就受到了热情的接待。
“这次西安来了多少人承接我们模块?”上海 X 模块的 PL 问我。
我愣愣地指了指自己：“就我一个”。
“什么，就你一个？我们组有 20 万行代码，赶紧反馈再加人。 ”
其实，刚出校园的我对 20 万行代码并没有太多概念，但是看到他的反应，顿感不妙。我赶紧找到在其他项目组承接产品的西安 PL，却得到了安慰，“没有想象的那么严重，你那块业务我也知道一些，我给你分析看。X 模块代码逻辑比较简单，Y 模块基本不出问题可以暂时不学，这样……这样……你只要集中把这几个模块搞定就行了。 ”
加人是不可能的，于是我的培养计划也相应有了变化。入职前两个月，我每天的任务就是读代码，下班前半小时给全组讲解。而同期其他新员工在入职一个月时已经开始处理问题单和开发需求了。第三个月中期答辩时，其他人的胶片上呈现的都是“处理了 XX 个问题单，开发了 XK 代码的需求”，而我的胶片都是模块的代码功能介绍。
学习期结束后，20 万行代码的威力很快得以体现。为了让我快速熟悉业务，项目组把活最杂的接口人工作安排给了我，负责所有的网上问题、实验室问题定位以及几个高风险模块的问题单修改。很快，我就淹没在电话和邮件的海洋里，焦头烂额。
“问题定位没？邮件都发好几个小时了，环境不保留了。”
“这个问题我分析应该是你们模块的问题，快看下，下班前没结论我就转单了。”
“怎么回事，你名下问题单怎么不见少，版本都快过不了点了。”
……
是的，我成了各个组的“焦点”，同时也开始变得焦虑，虽然每天凌晨才回公寓，依然无法阻止上窜的 DI 值（问题密度），这下该如何是好？
很快，导师和 PL 注意到了我的窘境，伸出了援助之手。看现象，找原因，和我一起分析现状，一件一件分析手头的事务，传授四象限工作心得，把眼前的事务按照四象限法则排好优先级，再一一击破，慢慢坚持一段时间后，我终于开始变得从容起来。
就是为了晚上能睡安稳觉
转正之后，我很快就遇到了第一个网上问题，并且经历了一次深刻 bug 修复过程。依稀记得那是周日，凌晨两点，电话响起时我感觉像是刚躺下就被叫醒。
“我是在一线支撑的测试经理，新版本升级报错了，需要马上解决！”
“好的，什么情况？先尝试做下这几步恢复操作，再收集下日志，我马上去公司。”一听是现网的问题，本来一脸迷糊的我瞬间清醒，这可容不得半点马虎。快速穿好衣服，打车直奔公司。
还好，问题很快定位，之前现网的服务器出现过网卡故障，客户把服务器拆封，两块网卡拔出来擦拭金手指，插进去的时候交换了插槽位置，导致网卡的 PCI 总线编号发生变化。为了防止客户私装其他网卡，引起兼容性问题，新版本代码做了强制校验，但对于这种更换网卡位置的场景，却没有考虑到。
“这谁设计的功能，画蛇添足！老版本都没问题，这是致命 bug，我要求必须回溯！”虽然功能不是我开发的，但听到电话另一端的措辞严厉，也感觉像犯了大错，不敢吱声。这次的经历，让我再后续很长一段时间，一接到网上问题电话就非常紧张。
网上问题引起的风波还没过去，修改这个网上问题的任务就落到我头上，没有想到的是这次修改也不顺利。代码很快就修改完了，但是验证时遇到一个问题。由于老型号服务器存量并不多并且前几年已停止发货，三种老型号服务器，实验室只有一台了，其他两种类型的服务器没有办法验证，怎么办？
“代码判断的就是这几个信息，你可以通过模拟打桩，之前我都是这么测的”，在老员工的指导下，我很快完成了打桩测试，但心里总有点不踏实。
结果在版本内部转测试前的预验证环节，兄弟项目组的同事找到了我，他们的一台服务器装上新版本后运行不起来。我心里“咯噔”一下，不会是那两种没有验证的服务器吧？果然，经过实机分析，发现我用的打桩模拟方法和真实的硬件还是有差异。
对于这次的修改引入，PL 特地过来辅导：“这次主要是你经验不足，不要太放在心上。不过我们也要好好想想，遇到困难，是不是尽全力了。”再次修改时，还是有一种类型的服务器没找到，感觉真的没办法了。
一大早我只好再求助导师和 PL，几小时后，PL 过来对我说：“我已经给周边几个部门打过电话了，有几台服务器可能是我们要找的，我带你去确认下。
又经过几个小时，我们终于在一个实验室的角落找到了一台落满灰尘的服务器。拍拍灰尘，一看，好家伙，这不正是我们要找的么！找电源，接线，上电，安装版本……看到版本软件顺利启动，心里悬了很久的大石头总算落地了。
“好，我们再把交换网卡顺序的场景覆盖下。”然而折腾了半天，网卡还是没拔下来。原来这个型号的服务器硬件设计上也做了防呆，卸网卡需要专用的小工具。
半个小时后，网卡终于拔了下来，PL 手上不小心被划了口子，鲜血直流，他却蛮不在意：“为了晚上能睡个安稳觉，这点小伤，值了！”
后来每当看到“打造质量口碑，构筑质量文化的教堂”时，我想说我们的质量追求真的很简单，就是为了晚上能睡安稳觉。
没有定位不了的问题
“Hello，sir……”下班刚出公司，我就接到了一个老外的电话。竖起耳朵再加上熟练的“sorry”“pardon”，才终于搞清楚了，原来是之前在 espace 上交流过的印度一线小伙，马上要去客户机房操作了，还有两个操作步骤不太清楚。
从来没跟老外通过电话的我，一时语塞，面红耳赤，嘴巴几次想张但就是张不开，到嘴边的单词，就是说不出来。
对方还在时不时的“hello? hello?”以为我不在线。哎，平时都是由 GTAC 的兄弟帮忙沟通，这下没人帮忙了，这可如何是好……不管了，管他语法怎样，突然，一句“yes”蹦出了口，慢慢地，一个单词、一个单词地蹦出，虽然磕磕巴巴，但总算可以用英语交流了。
我在电话了说了一通，反复确认对方了解了我的意思后，才放下电话。一看手心紧张得都是汗。好在总算交流完了，顿感身心舒畅了许多。
就这样，入职两三年后，一切逐渐步入正轨，不管是遇到什么难题，我似乎都可以从容应对了。
不过，现网出现的两三起未定位的 Linux 系统挂死问题，一直是大伙儿笼罩在头顶的乌云。由于使用的 Linux 是几年前外购的版本，一直未升级，维测功能比较弱。而我们作为业务软件团队，也不具备定位这种疑难问题的经验，求助公司的 Linux 团队后，仍无法定位，只能以老旧 Linux 系统问题进行了答复。
没想到，不久，在一个大 T 局点又出现了这个问题。没办法，我们只能再次求助 OS、硬件相关人员，快速组建了攻关团队。由于缺少日志，大家从软件硬件各种角度进行大胆猜测，然后在实验室进行故障注入测试，持续了一个月后，实验室连问题都没有复现，更谈不上定位，所有人都很沮丧。好在新版本软件已经合入了挂死时自动复位的自愈功能，问题影响可以将到最低。一线也接受了自愈方案。第一次的集中攻关就这样心有不甘地以失败告终。
出来混，迟早要还的。问题攻关永远不会缺席，只是来得晚而已。大半年后，中国区的一起 Linux 挂死问题拉开第二次攻关序幕。由于是晚上出的问题，一线还没来得及处理，我们请求一线保留环境，立刻协调了公司 Linux 和硬件的专家马上出差到现场定位。
“这次抓到第一现场，总算能定位了。”我心里想。可惜从一线并没有传回好消息，只是进一步确认，确实是 Linux 系统挂死了，原因还是不知道。一时，又陷入僵局。
但是攻关不能因此停滞。我们再次静下心来，继续分析日志，看代码，分析这几个问题找共同点，很快发现这几个问题涉及的设备都是在运行了快一年左右时出现了问题。莫非与单板的运行时长有关系？累积效应的故障模式？大家很快调整了攻关方向。不久，就找到一篇关于 Linux 内核内存泄露的案例，经过计算，在我们的单板上正好在一年左右 Linux 系统一些关键内存就会耗尽，出现系统挂死。真是踏破铁鞋无觅处，得来全不费工夫。
后续我参与甚至主导过多起耗时长久、艰苦卓绝的疑难问题攻关，Linux 系统挂死攻关在这些问题中不是影响最大和最紧急，但却让我受益最多。经历过这次攻关后，面对任何疑难问题，我心中都有一个信念：在我司，从来没有搞不定的事，也从来没有定位不了的问题！
2014 年到 2017 年，由于工作调整，我转战产品开发，暂时离开了网上问题处理。2018 年我又重新回归。
又是一次半夜紧急电话，我急匆匆赶到 GTAC 的攻关室处理紧急问题，一进门，又见到以前的几位老伙计：“看见你来我就放心了”。这句话一时间又让我浑身充满了力量！
以上内容来自华为内刊《华为人》，请勿转载
【2】、来自网友【犍为真人】的最佳回答：
我先后从事过机械、电气、信息技术行业，有对比才有伤害。
第一、程序员所涉及到的技术更新换代快，经验难以积累
计算机编程，总共出来也才几十年，现在还在高速发展中，更新换代非常快。从 DOS 编程到 windows 编程、Linux 编程，再到移动端编程。每一次跨度都非常大。需要不断地熟悉不断变化的操作系统、编程语言虚拟机(或解释器)、框架、引擎。比方说你做安卓，得熟悉安卓操作系统，使用 python，得熟悉 python 的解释器，使用 spring 框架，又得熟悉这一整套不断更新迭代的“大家伙”，做 Web 开发，还要遵循不断升级的 Web 标准。好不容易学会了表格布局，结果出来一个 div+css，好不容易熟练了 jquery，结果听说 vue 火了……在一个技术变成主流之后，之前好不容易积累的经验，就会变成过时的技术。比如说某个人现在 40 岁，那么他可能 35 岁之前学的东西都不值一文。医生、律师、机械、电气则没有这个问题。拿电气里面更新比较快的 PLC 编程来说，我接触 20 多年了，现在和以前，还是没有什么变化。没有听说过哪个电气工程师 20 年前的经验过时了的说法。
既然经验难以积累，那自然不会越老越吃香了。
程序员也有过时比较慢的技术，比如系统底层开发、驱动开发、嵌入式开发、芯片开发。但是技术要求高，需求小，工资还不一定高(收入与市场高度相关)。不是说技术难度越高收入就越高。比如一个苦练 20 年的京剧艺术家的收入就不及一个只学过 2 年唱歌的流行歌曲明星。
第二、程序员试错成本低
一个人在写代码时，会非常频繁地调试(debug)以及测试(test)。它们的成本是如此的低廉！我写代码时，基本上不到两分钟就要 debug 或 run 一下。可以说，写的东西，立马就能看到效果。如果写对了，或单元测试通过，皆大欢喜，如果报错了或结果不是预期，马上修改了再来一把。但是，其他行业，就远远没有这么幸运了。一个医生，不能对病人说，我没有把握，我给你开一剂药，咱们试一把；如果不行，咱再换一剂药。病人不得骂死你啊。电气上，大家把电线接好了，要开始合闸了，现在竟然谁也不敢合闸通电。这要是烧东西了谁负责呀？于是请来了最资深的电气专家坐镇，让他亲自检查、合闸。
试错成本低，导致了“老专家”的地位没有其他行业高，不容易受待见。因为年轻人也可以上，错了就修改代码再来，bug 嘛，没有什么大惊小怪的。这不像医生、律师、机械、电气等其他行业，出了 bug 是要出人命的(包括律师的人命官司)。这时候，经验比技术重要(因为没有试错论证机会)。一般年级大经验多，因为接触的案例多，遇到问题就参考经验做法。不像程序员遇到问题，就搭建虚拟仿真环境，动手写代码调试一番，经验教训的作用被淡化。
第三、程序员的工作容易被推翻重来
一个东西被推翻重来，就意味着这东西可能已经过时了，不再需要维护了，里面的细节就没有必要深究了。如果是这样，那么老人的价值就会降低。代码重构是再正常不过的事，其成本相对其他行业要低得多。有时候甚至就是翻天覆地的变化，基本是使用新编程语言重新实现了一遍。京东、豆瓣、知乎、涛宝，等等，都不能例外。我从事的机械行业，很多同事可以自豪地说，看，那台价值几千万的设备就是我 10 几年前设计出来的，它的每一个细节我都了如指掌。但是信息技术行业，却很难如此。当机械设备出现问题，找老专家出马。但是信息系统出问题，恐怕没人想到老专家了。因为它早已经不知道被重构多少次了，找正在升级和维护的年轻人才是常见的做法。
很多行业都有核心技术，不传之秘，它们就不容易被推翻重来。信息技术领域也有，但是相对要少一些(bat、华为等顶级公司开发的除外)，特别是小型业务系统。甚至可以说得更直白一点，那东西就是靠人堆出来的。你要不信，随便找一个高档写字楼看看，看有多少程序员，然后又有多少人做的是核心技术，大部分恐怕都是增删改查。在他们眼中，需求远远比核心技术重要。做需求的收入最高。需求，或者说业务流程往往与增删改查高度映射。
如果一个行业的某个人做技术，却不能掌握核心技术，动不动就被别人推翻，那就容易吃青春饭。
第四、程序员学习成本相对较低
这是相对的。甚至一台电脑就能开始学写代码。很多年前，程序员还是比较难的，因为自己要造很多轮子，要学习很多基础知识，比如数据结构、编译原理、操作系统。现在好了，直接用“框架”呀，底层别人帮你实现好了，你只需要专注业务即可。然后就变成了，我们比的不是谁的数学好，谁的基础扎实，而是比谁更熟悉“框架”。最后还会变成，就比谁更熟悉需求(业务)。甚至一度认为高大上的人工智能深度学习，也慢慢变成了“调参高手”，意思是说，我不需要懂数学，别人(以外国人为主)现成的算法都写好了，我调调参数就能用了。这是一门体力活，非常花时间，也很挣钱。
学习成本低，还得益于两点：一个是盗版软件，不花钱就能享受顶级体验，二是开源精神。其他行业可没有这样的好事，要花真金白银买实验设备、材料才能自学东西。
通过搜索引擎，很多编程问题都能找到答案，很多人也笑称，我们是面向百度(谷歌)编程。但是其他传统行业就没有那么幸运了，网上的资源乏善可陈。他们遇到问题，不是找百度，而是找师父，找老专家。老专家的地位自然被提高了。医院招一个应届硕士生，先得跟师父(老师)学习至少一年，没有工资，然后才敢慢慢上手，还必须非常谨慎，人命关天嘛。我们招一个应届本科毕业生，你用一周熟悉业务，一周熟悉新技术点，两周后开始上手干活，遇到问题，你先百度。区别就是这么大。
多数情况下，学习成本越低，就越容易吃青春饭。因为门槛低，有更多的人和你抢饭碗。
