硬件开发和软件开发哪个更难_学习业务并成为更好的软件开发人员

硬件开发和软件开发哪个更难

您是否正在寻找下一件事来学习提高软件开发人员的技能&＃xff1f; 也许您正在考虑研究这种新的功能语言&＃xff1f; 还是那个新的前端框架&＃xff1f; 也许花一些时间真正地了解机器学习&＃xff0c;例如算法&＃xff0c;而不仅仅是使用现成的黑匣子解决方案……&＃xff1f;

没有。

这很可能不是您最大的受益所在。 当然&＃xff0c;紧跟该新框架可能会帮助您更快地运行。 但是&＃xff0c;以错误的方向更快地行驶不会使您更接近目标。

您需要学习不同的东西-您的业务&＃xff01;

因为归根结底&＃xff0c;您的工作不是编写代码。 您的工作就是创造商业价值。

为什么我们写代码

描述业务价值的一种方法是&＃xff0c;它是有助于公司成功和业务长期健康的任何价值。 通常&＃xff0c;它不能直接从经济角度进行衡量&＃xff0c;有时甚至可能是无形的&＃xff0c;例如客户信誉。 在其他情况下&＃xff0c;例如可以降低服务器成本的性能改进&＃xff0c;则更容易衡量。

作为软件开发人员&＃xff0c;您可以使用代码来创造业务价值。 您的目标绝不是为了自己编写代码&＃xff0c;就像木匠的工作不是将钉子钉入木头&＃xff0c;而是有目的地建造建筑物一样。 代码或锤子是创造业务价值的工具 。

因此&＃xff0c;了解您的业务领域以及使您的公司成功的原因&＃xff0c;对于能够利用您的技能来创造业务价值至关重要。

了解公司业务的运作方式有很多好处- 动机 &＃xff0c; 沟通 &＃xff0c; 生产力 &＃xff0c; 实施和解决方案本身。

动机

当您了解实现某项要求的目的以及实现该要求要实现的价值时&＃xff0c;您会更有动力。 了解基本目标将使您看到所做工作的影响&＃xff0c;并了解其与整个业务的关系。

您和您的具体任务在组织中的适合位置以及它如何对公司的远景和North Star做出贡献&＃xff0c;这将变得更加清晰。 了解其他角色和部门的目标以及他们将要创造的业务价值&＃xff0c;不仅使您能够更好地支持他们&＃xff0c;而且还能了解您如何拥有共同的愿景以及组织中的不同部门如何为之做出贡献。

通讯

技术作家或分析师不仅需要掌握自己的专业&＃xff0c;而且还需要对自己所从事的领域有深刻的理解&＃xff0c;而且往往是深刻的。 软件开发人员也是如此。 最低要求是具有足够的领域知识以了解词汇表&＃xff0c;并使用相同的术语和语言与客户和其他开发人员进行有效的沟通。

此外&＃xff0c;通过更好地了解细节&＃xff0c;查看上下文并了解推断的信息&＃xff0c;可以大大减少通信需求。 通常&＃xff0c;这种知识将决定是否可以完全掌握规范或功能描述&＃xff0c;还是让您盲目地实现您希望正确的东西。

现在&＃xff0c;与其花费所有的通信带宽来解决误解和推断信息的空白&＃xff0c;不如将其花费在主动上&＃xff0c;要好得多。 跨学科的前瞻性交流&＃xff0c;侧重于从多个角度共享知识&＃xff0c;这不仅可以加快思想的迭代速度&＃xff0c;而且最终会带来更好的解决方案。

生产率

美国开发人员喜欢运送东西-生产力的顶峰&＃xff01;

随着通信效率的提高&＃xff0c;更好的业务知识也确实有助于简化编码。 在开发过程中&＃xff0c;您将面临无休止的决策流程。 他们中的大多数归结为两件事。 什么 时候实施&＃xff0c; 什么实施以及如何实施。

大型任务可能已经确定优先级&＃xff0c;并在团队成员之间分配&＃xff1b; 尽管如此&＃xff0c;一旦设计了详细的实现并开始编码&＃xff0c;您将发现影响设计的新含义和边缘案例。 您对正在使用的功能的业务相关依赖性了解得越多&＃xff0c;您将看到的越多。 而且&＃xff0c;当您发现规则的例外时&＃xff0c;您更有可能已经知道该答案&＃xff0c;而不必在组织中进行研究或与领域专家联系。

您还将使用此知识来微优先级化实现的方式&＃xff0c;以首先解决可能的不确定性&＃xff0c;而不是在已经引入依赖项之后再发现一些东西&＃xff0c;从而使重构更加复杂。

有了更好的业务知识&＃xff0c;就几乎可以每天在下意识地确定编码时对决策的优先级。 随着沟通的减少和更多的了解&＃xff0c;人们将有信心做出更多的决定和自主权。 反过来&＃xff0c;自治导致生产力。

实作

作为开发人员&＃xff0c;在使事物具有通用性&＃xff0c;抽象性&＃xff0c;灵活性&＃xff0c;可扩展性和可重用性方面容易走得太远&＃xff0c;有时会导致实现过程过于复杂。 通常&＃xff0c;这些实现永远都不会扩展或重用。

关键是要权衡何时仅根据当今的需求来设计实施方案&＃xff0c;以及何时考虑其随着时间的推移可能会如何发展。 借助领域的专业知识&＃xff0c;您将能够更好地呼吁哪种方法可以创造最大的商业价值。 如果机会窗口是下周&＃xff0c;则实施将与需要一个月的实施有所不同&＃xff08;但到那时&＃xff0c;对于创造业务价值完全一文不值&＃xff09;。

通常&＃xff0c;通过提出要实现的功能来提出功能请求&＃xff0c;通常以某种规格详细描述。 但是&＃xff0c;规范实际上永远是不够的。 您可能会争辩说&＃xff0c;源代码足够详细&＃xff0c;没有解释的余地​​。 因此&＃xff0c;将有不清楚的细节&＃xff0c;更不用说规范所基于的所有未成文的假设以及其中可能包含的错误。

通过理解实际“需求”和“需求”背后的原因&＃xff0c;您将处于一个更好的位置&＃xff0c;可以将其转化为具体问题并加以解决。

规范通常不包括与功能请求本身不直接相关的含糊不清的领域知识&＃xff0c;这些知识对于在实施过程中做出正确的设计选择可能至关重要。

例如; 在与财务相关的应用程序中&＃xff0c;对于具有会计基础知识的人来说&＃xff0c;很明显特定变量可能永远不会为负。 通常&＃xff0c;那些不言而喻的真理不会成为规范&＃xff0c;而是会被一些领域知识所接受。

知道那些“明显的”约束可能会影响要使用的数据结构&＃xff0c;数据库模型甚至相关的算法。 该数据集是否稀疏&＃xff1f; 此外&＃xff0c;一些琐碎的事情&＃xff0c;例如允许您在代码中进行更具防御性的检查&＃xff0c;甚至添加可以防止错误的测试用例&＃xff08;因为“……它不在规范中&＃xff01;”&＃xff09;可能会对最终代码的质量产生重大影响。实施。

解

根据人的天性&＃xff0c;我们经常过快地得出结论。 通常会提前考虑并仅根据我们已知的内容提出解决方案。 作为对业务领域充满信心的开发人员&＃xff0c;您可以退后一步&＃xff0c;就目标和解决方案应创造的价值进行对话。 知道此基本需求后&＃xff0c;您将可以利用自己的技术专长和有关现有代码库的知识来与请求者合作&＃xff0c;找到更好的解决方案。

看到请求背后的原因确实可以使您思考它&＃xff0c;而不仅仅是接受给定的请求&＃xff0c;发现可能的缺陷并指出错误。

获得该业务知识

那么您如何理解您的业务呢&＃xff1f;

没有一个答案能适合每个组织。 但是&＃xff0c;一个好的开始是提高您的观点&＃xff0c;并开始研究您正在从事的事情如何适合业务。 同样&＃xff0c;您正在处理的应用程序的目标是什么&＃xff0c;应创建什么业务价值 &＃xff1f; 这如何适合更大的组织&＃xff0c;最终适合产品或服务的业务模型&＃xff1f;

也要采取自上而下的方法。 公司的愿景是什么&＃xff1f; 商业模式如何运作&＃xff1f; 是什么使客户/用户活跃于产品中&＃xff1f; 哪些KPI与公司级别相关&＃xff1f; 在功能层面上&＃xff1f; 您的工作将如何帮助您朝正确的方向更改这些KPI&＃xff1f;

最重要的是-与您的同事交谈&＃xff01; 销售过程如何&＃xff1f; 什么营销成功&＃xff0c;什么营销不成功&＃xff0c;为什么&＃xff1f; 客户服务最常见的问题是什么&＃xff1f; 市场行为如何变化&＃xff0c;产品策略如何加以利用&＃xff1f;

这些只是一些对话入门&＃xff0c;可以帮助您成为一个更好的软件开发人员。

这会引起您的共鸣吗&＃xff1f; 在 Relatable上 查看 当前的职位空缺 。 我们是一家营销技术公司&＃xff0c;总部位于斯德哥尔摩&＃xff0c;洛杉矶和伦敦&＃xff0c;致力于与全球最富创造力和影响力的人们进行大规模的口碑营销。

翻译自: https://hackernoon.com/learn-business-and-become-a-better-software-developer-6db96ef852b1

硬件开发和软件开发哪个更难