具体描述
本书作者在软件行业从业、创业多年，对中国的软件开发领域理解非常深刻，对这个行业的前景和职业规划有着非常独到的见解。本书可以让大家知道这个行业整体是什么样的。只有了解了这个行业，才能更好地从事这个行业。
本书分为6章，内容包括程序员的职业规划、给程序员的职业成长建议、给程序员的技术建议、如何管理技术团队、国内软件开发之殇、软件外包公司生存指南。
本书既适合准备从事软件开发的求职者、软件开发从业者、项目经理和软件公司的管理人员阅读，也适合其他想要了解这一行业的人士阅读。
作者简介
申思维，软件行业从业者。2005年毕业于华南理工大学.
目录信息
第1章 程序员的职业规划 1
IT从业人员的职位介绍 1
开发人员 1
测试人员 3
产品经理 4
UI设计师 5
运维人员 5
用户体验师（UE/UX） 6
技术经理 6
架构师 7
如何选择编程语言 8
做Web后端开发建议选择Ruby 8
做Web前端（H5）建议使用Vue.js、React 8
做移动前端（App）建议使用原生语言和React Native 9
理想的职业发展路线 10
#一阶段：新手 10
第二阶段：熟手 11
第三阶段：技术经理 11
第四阶段：创业公司CTO 或大公司技术顶层 11
程序员的基本门槛 11
英语必须好 12
思维清晰、反应敏捷 13
表达沟通能力强 14
程序员的进阶门槛 15
具备领导气质 15
技术过硬 16
IT从业人员的去路 16
继续做IT 16
小幅转行 17
大幅转行 17
不看好的职业：测试、运维、架构师 17
测试 17
运维 18
架构师 21
软件培训机构 21
确实能改变少部分人的命运 21
在一定程度上推进了国内技术的发展 22
培训机构之痛 22
第2章 程序员的职业成长建议 25
务必有技术博客 25
表达能力得到极大提高 25
技术可以得到积累 25
个人博客是一张好名片 26
不要敝帚自珍 26
要会与人和睦相处，不要任性 27
控制好自己的脾气 27
越牛就越谦逊 28
沟通能力是立足社会之本 28
沟通能力很重要 28
千万不要性格内向 29
任务没能力完成要勇敢地说出来 30
小心程序员的膨胀期 30
不要因为被上家公司坑过就对下家公司抱有成见 31
不要论战 31
使用传统编程语言的人特别容易心态不好 33
高发诱因1：过于底层的语言 33
高发诱因2：开发人群的职业年龄是2~4年 34
不要踢皮球 35
会错失机会 35
会使人缘变差 36
会使人平庸 36
要抓住一切机会带团队 36
一个人做不成事情 37
带团队能让人开阔眼界 37
具有带团队的经验能让人更好地在社会中生存 38
带团队是职业生涯注定的方向 38
要有良好的心态 39
每天都要学习 39
不要沦于平庸 40
工作就是#好的学习机会 41
办公室没有政治 42
不要参与公司的八卦 42
正确面对公司的裁员 43
敏捷方法论 44
频繁交付、小步快跑 44
能自动化的都自动化 45
必要的测试 45
每日例会 45
要培养成学习型团队 46
良好的程序员工作习惯 46
晚上十点前睡觉 47
健康问题：不要总低头弓背 48
离开显示器和手机才是休息 49
不要沙发椅，要坐硬板凳 49
显示器要有护目屏 50
程序员的工作组成 51
程序员的工作不是一直在写程序 51
技术经理 51
程序员要走出去 52
性格内向 52
过分细腻 52
容易自傲自大 52
不要坐井观天，要多看看外面的世界 53
规划好业余生活 55
不要爱上旅游 55
不要接私活 55
利用业余时间做教学 56
中国IT公司的特点 56
技术实力层面 56
人员的年纪差距 57
35岁开始失业 57
技术高层不懂技术细节 58
管理更加严格 58
国内软件岗位的地域特点：北上广深是绝#主力 58
读书清单 60
《程序员修炼之道——从小工到专家》 60
《软件工程的事实与谬误》 61
《黑客与画家》 62
《软件随想录》 63
《人月神话》 63
《人件》 64
职业前辈的博客 64
第3章 给程序员的技术建议 66
程序员如何提问 66
使用好键盘周边 67
选择什么编辑器 67
要有正确的键盘指法 68
好键盘很重要，它是我们的武器 69
合适的键盘布局 69
使用好“第六根手指” 70
如何使用快捷键 70
单键快捷键 71
两键快捷键 71
三键快捷键 71
快捷键的思考 71
薄键盘和Mac键盘不适合程序员 72
程序员的理想装备 73
大屏显示器 73
机械键盘 73
游戏鼠标 74
大容量内存 74
固态硬盘 74
高速网速 74
版本控制工具 75
控制源代码的必要性 75
历史上的一些SCM工具 76
版本控制终#者：Git 76
在技术的天空中留下痕迹 77
必须有技术博客 77
必须要有Stack Overflow的账号 78
必须参与开源项目 79
绝#不要写重复代码 80
让程序员丧失工作的兴趣 80
让程序难以修改和测试 80
让人容易辞职 80
解决重复的原则：事不过三 81
命令行在大部分时候要优于图形操作界面 81
几个例外 83
操作系统的选择：优先使用Linux 84
技术广度比深度更重要 84
以#价比#高的方式点亮技能树 85
如何学习多种技能 87
技术债 88
技术债的后果很严重 88
典型的技术债1：错误的底层架构 88
典型的技术债2：错误的技术实现 88
典型的技术债3：低劣的代码质量 89
解决方案 89
一种高效的需求分析方法：可视化分析 89
用户的需求特点：不明确 89
方法概述 91
具体方法 92
几点注意事项 97
登录页面一般分成两端 98
估算工作量 98
代码质量 99
良好的命名是#好的注释 99
为什么不要注释 100
不要使用缩写 102
慎用匈牙利命名法 102
废代码 104
看起来美好却不实用的技术 105
屏幕自动适配 105
语言的国际化（i18n） 106
多数据库的同时适配 108
其他 109
为什么要自己搭建博客 110
要学会分享和开放 110
博客是重要的名片和笔记 110
写博客可以极大地提高表达能力 111
追求自动化 111
编译的自动化 111
部署的自动化 111
测试的自动化 112
第4章 如何管理技术团队 113
基本的管理原则 113
就事论事 113
任务划分得当、精确到人 114
公平公正 114
保持开放的氛围 114
程序员的特点 114
容易骄傲 115
程序员之间的鄙视链 115
比较单纯 115
有职业病 116
容易自我关闭 116
技术人员的性格特点 117
实力决定地位 ...
· · · · · · (收起)
读后感
用户评价
这本书的文字功底令人叹服，它没有采用枯燥的学术语言，而是以一种近乎散文诗般的、充满画面感的笔调，描绘了一个个令人心悸的软件项目“垂死挣扎”的过程。我尤其欣赏作者在构建场景时的细腻处理，比如描述项目经理如何在没有足够资源的情况下，用各种“激励”话术来粉饰太平，以及团队成员在疲惫与不信任中逐渐走向麻木的心理轨迹。书中对“沟通鸿沟”的刻画尤为精准，那种跨越了部门、层级和角色之间的隔阂，使得技术人员像是在雾中航行，每一步决策都充满了不确定性和潜在的灾难。如果说技术书籍是蓝图，这本书更像是一幅解剖图，它揭示了那些在快速迭代中被忽略的组织病灶和文化毒瘤。读完之后，我不再只是抱怨流程问题，而是开始思考，是什么样的企业文化孕育了这些“殇”，那种无力感和对体制的反思，比任何技术规范的讲解都来得更为震撼和持久。
这部作品简直是一场思想的洗礼，它以一种近乎冷峻的笔触，剖析了现代软件工程实践中那些被光鲜外表掩盖的深层弊病。作者的叙事并非简单地罗列技术难题，而是将其置于一个宏大的社会与商业背景下进行审视。我印象最深的是其中对“敏捷”概念被异化为“快速交付的枷锁”的深刻洞察。书中花了大量篇幅去描述，当指标和速度成为衡量一切的唯一标尺时，创造力、代码的健壮性乃至工程师的职业尊严是如何被一步步蚕食殆尽的。特别是对需求变更失控、技术债务积累成灾的案例分析，简直就像是翻开了我过去十年工作记录中的血泪史，那些曾经在深夜里独自面对的Bug和无休止的返工，终于有了一个有力的、集体的注脚。阅读的过程中，我时常感到一种强烈的共鸣与痛楚交织的情绪，仿佛作者能穿透屏幕，直达每一位深陷泥潭的开发者的内心。它不仅仅是关于代码的，更是关于人与工具、人与系统之间权力关系的深刻反思，其哲学思辨的深度远超一般技术书籍的范畴，值得反复咀嚼。
这本书给我的感觉，就像是走进了一间布满精密仪器的实验室，但这里的实验对象不是机器，而是人类的协作和期望。它对“预期管理”失败的剖析入木三分，那种从项目伊始，各方对“不可能的任务”抱持着不同版本的解读，到最终多方在失望中互相指责的场景，被描绘得淋漓尽致。我特别欣赏作者对“黑盒化”现象的批判，即随着系统复杂度的增加，越来越多的关键决策被包裹在不透明的流程或技术栈之下，使得任何个体都无法对整体结果负责。这种责任的稀释，是导致“殇”产生的温床。阅读时，我感觉自己仿佛参与了一场高强度的辩论，作者不断抛出挑战性的观点，迫使我重新评估自己对“成功交付”的定义。它不是一本读完就能解决问题的书，而是一部引导你深入探究组织行为学、心理学与工程实践交界处的重量级作品，需要用批判性的眼光去细细品味。
这本书的结构设计颇具匠心，它不像传统的理论著作那样线性推进，而是通过一系列看似独立却又环环相扣的个案研究，构建了一个庞大的、关于软件项目失败的生态系统图谱。我注意到作者巧妙地穿插了历史的对比，将当前的困境与早期软件工程的黄金时代进行了对照，这种时空的反差感，极大地增强了批判的力度。特别是关于“技术选型债务”的章节，它没有陷入对具体框架的争论，而是聚焦于组织如何在短期利益的诱惑下，不断积累那些需要未来数倍成本才能偿还的技术包袱。这种“前瞻性的悲观主义”贯穿始终，让人读后既感到沉重，又不得不承认其逻辑的严密。更难得的是，即便是在描述如此消极的现象时，作者的文字依然保持着一种克制的、近乎冷静的客观，避免了情绪化的宣泄，使得它的论点更具穿透力。
老实讲，这本书的视角非常独特，它没有试图提供一个万能的解决方案，反而更像是在构建一个警示录。作者的叙事重心似乎更多地放在了“人”的能动性在僵化系统中的消亡上。书中有一段关于“专业主义的消逝”的论述，至今仍在我的脑海中盘旋：当一个知识工作者被降格为流水线上的操作单元，其内在的驱动力——对完美和优雅的追求——便会逐渐枯竭。我发现书中对技术人员心理健康的关注，远远超过了许多主流的行业报告。它探讨了那种长期处于“救火”状态下产生的慢性焦虑，以及如何将这种焦虑内化为一种对工作质量的妥协，最终导致了对自我价值的怀疑。这本书的价值不在于教会你如何写出更好的代码，而在于让你重新审视自己工作的意义。它强迫你停下来，问自己：我是在创造，还是在仅仅应付？这种自省的力量，是阅读体验中最为珍贵的馈赠。
比较真实的反应了行业状况
比较真实的反应了行业状况
推荐给两种人看： 1. 在校的学生：你需要对这个行业有所了解，才能辅助你更好的做抉择。 2. 想要创业的人：这本书的作者本人就开了企业，能够让你更加明确，应该如何做选择。你未必要重复，但可以参考。
上图还书的时候偶然看到，书名很特别，出版日也比较新。不是行内人也能看懂的科普类书籍，了解了一线程序员的类型，和面对的问题。后面偏向管理层的介绍了，很多工作模式与医疗行业也很相似，FSP的风险是一样的显而易见。 当我们不再关注本身行业detail的事情时，看看隔壁行业的水深火热和窘境，未尝不是给自己一个出路。
上图还书的时候偶然看到，书名很特别，出版日也比较新。不是行内人也能看懂的科普类书籍，了解了一线程序员的类型，和面对的问题。后面偏向管理层的介绍了，很多工作模式与医疗行业也很相似，FSP的风险是一样的显而易见。 当我们不再关注本身行业detail的事情时，看看隔壁行业的水深火热和窘境，未尝不是给自己一个出路。
