本文转载，工作五六年后，越发感觉对行业的认知和理解，比提高代码的水平和技能要重要的多。这大概也是领域专家这么值钱的原因吧。所以转行的风险随着年龄的增长也会越来越大
很少有人从头开始构建代码
在大学，他们会教你如何编写一个400行的程序，从头到尾地解决一个问题。你手头有一个白板，你需要展示一些花哨的算法，以证明你具有可以找到走出迷宫的知识和能力。最后，你找到了完美解决方案去解决那个超简单的问题。
这看起来很像真实的世界，对吧？但现实并非如此。在现实世界中，在工作中你很少有机会能从0到1的构建一个项目，通常都是半路参与的项目，然后你有一个几十万行的代码，当你试图弄清楚你的同事在写这部分代码时到底在抽什么风，你需要在文档和更了解代码的人之间来回切换。当一周快结束时，你写了10行代码来修复某个bug，然后循环往复，直到人们找到你，向你解释他当时为什么要这样写。
专业的软件开发人员在团队中工作，一般只处理大型软件代码库的一小部分，并且通常只是修复一些东西，而不是从头开始构建。它并不像培训机构所描述的那样迷人，而且修复所付出的开销要比写代码多得多。
对领域的认知比会写代码更重要
我惊讶地发现，当你理解了它是如何（更重要的是为什么）工作，以及工作的基本原理后，编写代码会变得容易得多。
在构建银行移动端APP的时候，你可以更好地理解交易是如何运行的，货币结算是如何运作的，账本是如何工作的等。
在为餐厅构建销售系统时，你最好弄清楚服务员是如何工作的，在烹饪清单中如何做库存管理，以及信用卡授权是如何工作的。基本上，这就是你的软件运行域的内部和外部。
构建医疗、物流和记账方面的软件也是如此。如果不了解这些，个体是很难做出有意义的贡献的，对雇主来说也就没有价值了。例如，如果你有银行APP的经验，那么你很容易在金融领域再找到一份新的工作，因为你已经熟悉该领域。
文档编写没有得到足够重视
大学经常为学生提供软件开发职业所需的基本技术技能，如算法和数据结构。然而，他们通常不会优先考虑编写整洁、文档良好和可维护的代码。
通常，开发人员只有在处理别人编写的代码并经历了试图理解和修改它的挑战之后，才会意识到编写可维护代码的价值。可想而知，当我看到正确的文档时，我是多么高兴。然而，这些都不是在课堂上学到的，而是通过实践经验总结的。通过编写文档和易于理解的代码可以节省大量时间和精力。
代码是次要的，商业价值才是第一的
没有人会过来对你说：“哇，这行代码写的真棒！”相反，他们会说：“用户对你写的功能相当满意”，或者“你的代码把整个网站都搞垮了”。
虽然这听起来可能令人惊讶，但软件工程师的主要工作重点不是编写代码，而是通过使用已编写的软件来创造价值。代码只是实现这一目标的工具。代码->软件->价值。
你写的东西需要满足世界上的一些需求——一些用户使用的工具，一些降低成本的自动化，一些人们愿意付出（付出他们的时间、金钱或注意力）的东西。我们可以简化它。如果你用糟糕的技术构建了一些为用户提供巨大价值的东西——恭喜你，你已经完成了作为软件工程师的目标。但，如果你用优秀的技术构建了一些东西，但却为用户提供了糟糕的价值——那么很遗憾，你并没有达到目标。
优雅的代码，最佳实践，智能解决方案，设计模型——这些都是为了你的软件工程师同事，他们将在你之后处理这些代码库，而不是帮助你实现带来价值的目的。（请注意，带来价值也可以意味着构建一个不会崩溃的可伸缩的解决方案，这要求代码写的至少像点样。）
你需要和不称职的人打交道
大多数工作环境中都会有不称职的人。不是指他们就是你的经理，他们可以是提供API的合作伙伴公司的经理，也可以是客户的某些高管。和不称职的人协作是非常令人沮丧和疲劳的。他们创造了一种有害和低效的工作环境。他们花了太多时间来做决定，或者做出了糟糕的决定，从而给团队和项目带来了负面影响。这导致了持续的延迟和返工，浪费了宝贵的时间和资源。
我花了相当多的时间来寻找有效的方法来处理这些事情，同时又不会成为一个混蛋。我认为大学应该传授此技能。我发现了一种有效的方法就是不管别人怎样，都要专注于高效。我试图寻找其他可能更有效的解决方案，以及避免无效的人参与。比如，记录一切也是很有帮助的。这可以提供具体的证据，证明他们的不称职对项目进程的影响。
最终，应对不称职的最好方法是积极主动，找到绕过他们局限性的方法。这可能涉及：
- 寻求额外的资源或支持。
- 想办法把任务委派给更有能力的人。
- 实现故障保护和回退机制，这样事情不会卡在你这边。
- 以面对面的方式告诉对方，他们阻碍了这个进程。
- 再说一遍，没必要当混蛋。
大部分时间都在与不确定性打交道
与人打交道很难。处理不确定性也很难。与不确定的人打交道更难。这就是你作为一个软件开发人员要做的。
人们并不总是知道他们想要什么，有时他们没有意识到一个简单的改变可能是非常复杂的——“哦，你的意思是我们不能仅仅是变更支付供应商？而是整个信用卡付款流程的改变，对吧？”
他们在大学里对你说的一个大谎言是，你的项目经理会给你适当的、结构化的、简单的指令，告诉你需要做什么，然后你编写代码。“画一个曼德勃罗特集”或“渲染一个环境遮蔽的Rabbit mesh”。在一天结束的时候，你有了一个解决方案，你和你的经理击掌，然后微笑着回家。
实际上会发生的是，你的产品经理会给你一个任务的粗略轮廓，“我们需要一些东西来把我们从A点带到B点，但我们还没有任何设计，第三方集成也不会立马交付，除非我们告诉他们我们想要什么，X老板希望它是红色的，Y老板希望它是绿色的。”这就是软件工程师的“真正工作”开始的地方——收集需求，弄清楚需要做什么。
需求收集在编程中可不是简简单单的。这没有写代码那么有趣。但作为程序员，这需要你花费大量的时间，因为它需要与人而不是机器合作——打电话给提供第三方集成的机构，并与他们的开发人员交谈，以了解什么是可行的，什么是不可行的。与利益相关方坐下来，告诉他们，他们的想法没有意义，我们可以这样做，不能那样做。
编写第一行代码可能需要数周时间。你需要弄清楚需求，然后弄清楚它需要放在哪里，然后弄清楚它需要如何构建，然后弄清楚它可能会在哪里出错，然后才真正开始编写第一行代码。
假设所有东西都有bug
这是很多开发人员对于信任的一个普遍误解：
- 你很少充分信任你的代码，因为你知道你也是人，也会犯错误。
- 你使用的第三方库可能会有bug，但它们是由比你更有能力的人编写的，对吧？
- 标准操作系统库不应该有任何bug，对吧？它们是由更聪明的人写的。
- CPU/硬件应该永远不会出错，对吧？他们花了好几年研发这个东西；它不应该坏。
- 供电是不应该中断的啊。哎。
但事实是——我们永远不能完全相信我们的代码、库甚至硬件不会在某些时候中断；相反，我们需要假设它会。即使是聪明人也会犯糊涂。
如果你查看任何流行库（操作系统或应用程序级别）的GitHub issue，你会看到大量未定义的操作等待被修复。天啊，我的Linux机器有多少次因为分段故障崩溃了？这太疯狂了。
通过假设一切都可能发生故障或有bug，我们可以采取措施来预防或减轻潜在的问题，这最终有助于确保系统的可靠性和稳定性。
这不是一份理想的工作
你的大学都会告诉你，一旦你开始工作，你将拥有的美好生活是什么。但那都只是一个空洞的承诺。
- 这是一项艰苦的工作。你一天大部分时间都坐在电脑后面。
- 工作和生活很难平衡。一般其他职业是，一天的工作在18:00结束，然后就可以完全忘记工作。但在这不是的。你很可能一直在线并查看代码，即使是在深夜。
- 你很少会有时间做自己喜欢的事情。而且通常情况下，这是一项需要完成的乏味工作。
- 职业发展机会有限。即使你是一名优秀的员工，在公司里也可能没有提升的空间。
- 压力的环境。最后期限、bug和满足客户期望的压力都会导致压力倍增。
- 远程工作可能导致孤立。根据公司和团队结构的不同，软件工程师可能会长时间独处（不包括视频通话），导致缺乏真正的社交互动。
- 工作保障有限。随着技术的不断发展，软件工程师可能会面临被更新、更高效的技术取代的风险。
美学是教不来的
大学课程教会了我们做出优秀代码的基础知识，但是软件开发中的真正美学是无法在课堂上教授的。
软件开发中的美学是指代码的整体外观和感觉。关键在于它是否易于阅读、理解和维护。美观的代码是干净、有组织并遵循逻辑模式的代码。这是一种让你在看到它的时候感觉优雅的代码。或者在糟糕的时候让你畏缩。
不幸的是，美学不能在一个学期的课程中教授。它是通过经验、阅读大量好代码和维护坏代码获得的。
经理们都喜欢数字、估算，以及用写在餐巾上的想法来要求估算。这就是现实世界的运作方式——企业有一些利润目标，但在批准立项之前，他们需要了解成本。在大学里很难传授这一点，因为准确性高度取决于你构建系统的经验。你多年来解决的问题越多，就越容易估计未来的工作。
我不打算讨论做估算的最佳方法；有很多方法可以做到。但我要说的是，估算是企业唯一能理解的东西。如果你开始谈论“我们有长期计划，但我不知道我们什么时候能完成”，那么在这种前提下，公司很难生存。
在Mindnow，我们通常会粗略地估算整个项目，以估算需要分配多少预算——这是长期的优先事项。然后，我们开始基于冲刺的计划，整个团队讨论、确定优先级并提交到短期可交付成果中，使我们更接近长期优先级。
并非所有的会议都是无用的
既然，软件工程师的工作并不是花大量时间写代码，那时间都去哪了呢？答案——会议。会议的目的是确保一切进展顺利，按时进行。他们让人们围绕一个共同的目标保持一致，并让每个人都走上正轨。市场营销部门知道有些东西正在开发中，他们可以为功能的最终发布做准备。项目经理了解开发人员的工作方向，并在需要时进行微小的修正。客户支持带来了最终用户的反馈。质量保证部门分享他们发现的问题。管理层分享利益相关方的最新情况。
所有这些都是相互关联的，而会议是信息共享的场所。作为一名软件工程师，需要对这种信息共享的一部分负有责任，因此阻碍它是不负责任的。虽然你可能不喜欢这样，但是必须共享信息以保持系统的效率。
