自 2022 年年中以来，我一直在考虑写这篇文章——但我不记得应该写在这里的所有内容。所以在过去的一年里，我一直在收集想法并将它们写下来，现在我有足够的观点想与你分享。
你很少从头开始写新代码
在大学里，他们教你如何编写一个 400 行的程序来解决 AZ 的问题。你有一张空白的画布，你需要展示你对一些奇特算法的了解，以找到一种生成迷宫的方法。最后，你有一个很好的解决方案来解决一个简单的问题。
这听起来像真实世界，对吧？但事实并非如此。在现实世界中，你有一个几十万行的代码库，你正试图弄清楚你的同事在写这篇精彩的文章时在抽什么烟。你在文档和更了解代码库的人之间来回切换。在一周结束时，你写了十行代码来修复一些错误，然后循环重复，直到你最终成为人们来解释你为什么这样写的人。
专业的软件开发人员以小组的形式工作，并处理大型软件代码库的一小部分，而且通常情况下——它是在修复东西而不是从头开始构建它。它并不像新兵训练营描绘的那样迷人，而且涉及的开销比编码要多得多。
领域知识比您的编码技能更重要
我惊讶地发现，当你理解了如何以及更重要的是为什么需要工作的基本原则时，编码就会容易得多。
在建立一个移动银行应用程序时，你最好了解交易是如何运作的，资金结算是如何运作的，账本是如何运作的，等等。
当为餐厅建立一个销售点系统时，你最好弄清楚服务员是如何操作的，美食中的库存是如何管理的，以及信用卡授权是如何运作的。基本上，你的软件将要运行的领域的内部和外部。
在医学、物流和簿记方面建立软件也是如此。
如果没有这些知识，个人可能很难做出有意义的贡献，也可能对雇主没有价值。例如，如果你以前有银行应用程序的工作经验，你就有更大的机会在金融领域找到另一份工作，因为你已经熟悉这个领域了。
撰写文档没有强调足够的难度
大学通常为学生提供从事软件开发所需的基本技术技能，如算法和数据结构。然而，他们往往没有优先考虑编写干净的、良好的文档，以及可维护的代码。
往往只有在研究了别人写的代码，经历了试图理解和修改代码的挑战后，开发者才开始体会到写可维护代码的价值。哦，孩子，当我现在看到适当的文档时，我是多么高兴。这不一定是在课堂上学到的，而是通过实践经验和认识到有文档和写出易于理解的代码可以节省时间和精力。
代码是次要的。商业价值是第一位的。
没有人会走过来对你说："哦，哇，你写的单行本真不错，真了不起！"他们会说："用户对你写的功能很满意"，或者 "你的代码让整个网站瘫痪了"，这取决于你的运气如何。
虽然这听起来令人惊讶，但软件工程师工作的主要重点不是编写代码，而是通过使用编写的软件创造价值。代码只是实现这一最终目标的工具。代码 -> 软件 -> 价值。
你所写的东西需要填补世界上的一些需求--一些用户会使用的工具，一些能降低成本的自动化，一些人们会付钱的东西（用他们的时间、金钱或注意力）。我们可以把它简化。如果你用低劣的技术建造的东西为用户提供了巨大的价值--你已经达到了你作为一个软件工程师的目的。如果你用伟大的技术建造了一些东西，但为用户提供了低劣的价值--你没有。
优雅的代码、最佳实践、聪明的解决方案、设计模式--这些都是为了你的软件工程师同事而做的，他们将在你之后的代码库中工作，而不是帮助你实现带来价值的目的。(提醒你，带来价值也可能意味着建立一个不会崩溃的可扩展的解决方案，这需要代码至少有点像样）。
你需要在无能的人身边工作
在你所接触的大多数工作环境中都会有不称职的人。它不需要是你的经理；它可以是为你提供API的伙伴公司的经理，或者是客户方面的一些C级主管。
与之打交道是非常令人沮丧和疲惫的。他们创造了一个有毒和无益的工作环境。他们做出决定的时间太长，或者做出的决定太差，对团队和项目产生负面影响。这导致了不断的延误和返工，浪费了宝贵的时间和资源。
我已经花了相当多的时间，找出有效的方法来处理这些无能的人，而不至于成为一个混蛋。我想这是一项绝对应该在大学里教授的技能。
我发现，有效的方法之一是，尽管对方有问题，但我还是要专注于有成效。我试图找到可能更有效的解决方案/替代方案，并且不需要让无效的人参与进来。记录所有的事情也很有帮助。这可以提供具体的证据，证明他们的无能对流程的影响。
归根结底，处理无能者的最好方法是积极主动，找到绕过他们的限制的方法。这可能涉及到：
你大部分时间都在与不确定因素打交道
与人打交道是很难的。与不确定因素打交道很困难。与不确定的人打交道更难。而这正是你作为一个软件开发者要做的事情。
人们并不总是知道他们想要什么，有时他们没有意识到一个简单的变化可能非常复杂--"哦，你的意思是我们不能只是改变支付供应商？这是同样的信用卡处理，对吗？"
他们在大学里告诉你的一个大谎言是，你的项目经理会给你适当的、结构化的、简单的指示，告诉你需要做什么，然后你再编码。"画一个Mandelbrot "或者 "用环境遮挡渲染一个Rabbit网格"。在一天结束时，你有一个解决方案，你和你的经理击掌，然后微笑着回家。
将要发生的是，你的PO会带着任务的大致轮廓来找你。"我们需要一些能把我们从A点带到B点的东西，但我们还没有任何设计，第三方的集成也不会交付，直到我们告诉他们我们想要什么，X老板希望它是红色，Y老板希望它是绿色。"而这正是软件工程师的 "真正工作 "开始的地方--收集需求，弄清楚需要做什么。
收集需求并不是编程中最容易的部分。它不像写代码那样有趣。但作为一个程序员，它需要花费你相当多的时间，因为它需要与人合作，而不是与机器合作--给提供第三方集成的机构打电话，与他们的开发人员聊天，了解什么是可行的，什么是不可行的。与利益相关者坐下来，告诉他们他们的想法是没有意义的，我们可以这样做，而不是那样做。
编写任务的第一行代码可能需要几个星期。你要弄清楚需求，然后弄清楚它需要去哪里，然后弄清楚它需要如何构建，然后弄清楚它可能出错的地方，然后你写下第一行。
假设一切都有bug
这是一个流行的信任误区，很多开发者都有这种误区。
但事实是--我们永远无法完全确定我们的代码、库、甚至硬件不会在某个时刻失效；相反，我们需要假设它会失效。即使是聪明人也只是人。
如果你看一下GitHub上任何流行的库（操作系统或应用程序级别）的问题，你会看到大量的未定义行为等待被修复。我的上帝，我的Linux机器因segfault而崩溃了多少次？这很疯狂。
通过假设所有的东西都可能发生故障和有bug，我们可以采取措施来防止或减轻潜在的问题，这最终有助于确保我们系统的可靠性和稳定性。
这不是一份理想的工作
无论你的大学或训练营如何告诉你，一旦你开始从事IT工作，你将拥有美好的生活，这只不过是一个空洞的承诺而已。
美学是不能被教授的
大学课程教给我们优秀代码的基础知识，但软件开发中真正的美学是无法在课堂上传授的。
软件开发中的美学指的是代码的整体外观和感觉。这是关于它有多容易阅读、理解和维护。有美感的代码是干净的，有组织的，并遵循逻辑模式。它是那种当你看到它时让你感觉良好的代码。或者当它很糟糕的时候让你感到害怕。
不幸的是，美学是无法在一个学期的课程中被教授的。它是通过经验和阅读大量的好代码以及维护坏代码而获得的。
即使你不想提供估算，也会被要求提供估算的。
经理们喜欢数字、估算，以及用写在餐巾纸上的想法来要求估算。这就是现实世界的运作方式--企业有一些金钱上的目标，但在承诺之前，它需要了解它将花费多少钱。
在大学里很难教这个，因为准确度是高度基于你建立系统的经验。你多年来解决的问题越多样化，就越容易估计未来的工作。
我不打算讨论做估算的最佳方法；有几十种方法可以做。但我想说的是，估算是企业唯一理解的东西。如果你开始谈论 "我们有长期规划，但我不知道我们什么时候能完成"，企业就很难在这样的前提下生存。
在Mindnow，我们通常会粗略估计整个项目，以衡量需要分配多少预算--这是长期优先事项。之后，我们开始进行基于冲刺的规划，整个团队讨论、优先考虑并承诺--短期交付物使我们更接近长期优先事项。
不是所有的会议都是坏事
那么，软件工程师的工作几乎不包括任何编码，那么时间都花在什么地方呢？会议。
会议是为了确保一切顺利进行并按计划进行。它们使人们围绕着一个共同的目标，并使每个人都在轨道上。市场部知道正在开发的东西，他们可以为最终发布的功能做准备。项目经理看到开发人员正在努力的方向，并在需要时做轻微的路线修正。客户支持部带来了面向用户方面的更新。质量保证分享他们的发现和他们发现的问题。管理层分享利益相关者的更新。
这一切都相互关联，而会议就是分享信息的地方。作为一名软件工程师，你要对这种信息共享的某些部分负责，所以阻碍它是不负责任的。你可能不喜欢它，但为了保持系统的效率，信息必须被共享。
结论
如果你正在考虑从事软件工程，请准备好直面这些事实，拥抱成长的机会。极不可能为世界带来有意义的改变，但归根结底，这只是一份工作，你可以通过其他方式做出有意义的贡献。
最重要的是--尝试着去享受乐趣。
我相信还有更多我没有提到的隐藏的宝藏。欢迎在评论中添加它们。
黑客新闻讨论
更多：
Copyright © 2024 妖气游戏网 www.17u1u.com All Rights Reserved
