四宫杀手数独题目

在您的早期软件启动时要提防这些工程错误

在 2016年，我为首次创业的人提供了技术建议，他们建立了种子资金的食品外卖市场。 我认为，公司做出的每项技术选择都是错误的。

CEO相信“赋予工程师权力”。 然后，他们让第一位工程师选择框架（Scala / Play），因为这是工程师想要使用的框架，而不是因为它对公司，用例或招聘人员来说都是有意义的。 早期的许多技术工作已外包。 尽管大多数业务仍未通过，但他们的产品路线图普遍乐观（同时通过网络和移动）。 这是灾难的秘诀。

启动工程与任何其他类型的软件工程都不同。 相对于建筑系统的“正确方法”，它需要短期和中期的生产率。 它重视能够快速迭代并熟悉hacky代码的人员。 与选择最受炒作或最稳定的技术相比，它奖励技术选择上的务实。

如果您的初创企业尚未找到适合市场的产品，则可以避免以下四个常见的工程陷阱。

过早缩放

最常见的启动工程错误是过早扩展。

过早缩放意味着在您还很小的时候就进行大规模构建。 过早的扩展将立即产生的生产力换来了遥不可及的利益，而这些利益通常是从未实现的。

在启动中到处都有过早的扩展问题。 在2010年代初期，为避免NoSQL数据库（如MongoDB和Cassandra）的（可感知） 无限可扩展性，部分地避免使用关系数据库。 整体服务的启动生产力优势因微服务的刺激而丧失。 多年来，Rails被称为不适合初创公司，因为它比其他框架要慢。

过早缩放会浪费工程资源。 对于没有钱但工程师很少但功能需求巨大且不断迭代的早期初创公司来说，在达到产品与市场的契合之前进行扩展是灾难性的。

如果它是第一杀手，为什么过早发生缩放如此频繁？

首先，扩展很有趣。 Twitter的初始版本是一个简单的整体CRUD应用程序，任何新兵训练营的工程师现在都可以构建。 短短几年间，Twitter出现了一系列有趣的问题：要查询的大量数据，停机造成的巨大成本，大量的使用高峰以及庞大的用户群。 添加扩展的技术来满足这些需求使工作变得更加令人兴奋，并且对加入的人们更具吸引力。 这种兴奋使早期扩展成为工程团队容易陷入的陷阱。

第二，建立绩效体系似乎是合理的。 一些工程师对“ hacky”系统感到震惊，好像他们在道德上失败了一样。 对于那些可能需要大规模完成所有工作的大型高科技公司的启动工程师而言，这种对潜在的低端解决方案的厌恶尤其是一个问题。 “做不按比例缩放的事情”在Y Combinator中经常出现，它在工程中的应用与在业务流程中一样。

技术债务造成的早期创业损失比您想象的要少。 如果您成功了，通常就会有钱来修复所犯的所有工程错误和捷径。

第三，工程路线图和工具建立在对未来的超乐观看法的基础上。 初创企业领导人对自己的业务发展抱有理想主义的态度，因为面对现实，他们否则就不会创办公司。 即使您达到了产品与市场的契合度（这是需要重新评估工程决策时的关键里程碑），但危险仍然是您高估了所需的规模。

试图在将来的需求出现之前就将其浪费掉了宝贵的资源，而这些资源无法用于您的近期目标，即构建人们 所需 的产品 。

使用未经测试的技术

当初创企业过度依赖闪亮的或新技术时，它们会伤害自己。

闪亮的技术是软件工程师崇尚的技术。 闪亮的技术通常使工程师的生活更轻松，更愉快，尤其是在极短期内。 但是依靠最新的技术错过了在中期范围内对广大团队最具生产力的工作。

例如，与使用关系SQL数据库相比，MongoDB的类似于Java的DSL和JSON数据存储使Java开发人员更容易编写代码。 但是，在选择数据库时，易用性不应成为主要指标。

资料来源：卡波夫，瓦莱里。 MEAN堆栈：MongoDB，ExpressJS，AngularJS和Node.js （Slideshare）

在一次采访中，一位软件工程师告诉我，他永远不会在没有使用CoffeeScript的公司工作（今天，辩论可能是关于使用Elixir的 ）。 如果正确的解决方案与他的选择背道而驰，他拒绝甚至考虑其他工具的承诺也将带来问题。

新技术有其自身的问题。 人们对新工具的故障状态了解得很少，因此很难预料情况将如何破裂。 新的语言/框架没有库，也没有很多工程师可以在其中编写程序。 资源的缺乏增加了开发工作，使招募工作更具挑战性。 这也意味着当您可以专注于创建用户重视的功能时，请投入创业公司的稀缺工程资源来学习新知识。

问题的一部分是工程师，尤其是非创始人的工程师，想要实施使他们在市场中显得相关的技术。 那应该让初创企业感到担忧。 在前端工程这样的空间中，让工程师追逐当前的炒作周期可能意味着每6-12个月重写一次堆栈 。

在职业生涯的早期，开发人员特别容易使用新的有光泽的技术，而不是对眼前的项目最有意义的工具。 他们还没有经历过几次大肆宣传，也没有看到选择最新技术的弊端。 在阅读《黑客新闻》或参加黑客马拉松/会议时，他们可能会错过所有看到的营销信息 。

更糟糕的是，这些开发人员没有意识到仅仅是因为一项技术被大肆宣传而不能使其适合于启动环境。 通常会采用知名初创公司或大型公司的技术堆栈并移植其堆栈，而无需评估这些选择的适当性。 当团队规模较小时，开发人员并不总是拥有经验丰富的工程师的指导以抵消他们所看到的外部媒体。

初创公司开发人员引用了Paul Graham的著名文章《 Python悖论》 ，其中Python与Java相比提高了初创公司的生产力。 格雷厄姆（Graham）的文章通常被用来证明实施每一个最新的框架和语言都是正当的。 但是，Graham的真实观点是，软件工程师应该选择能够最大程度提高启动生产力的工具，而不是一味地支持最新技术。 实际上，在2013年在Y Combinator看到了众多创业公司之后，格雷厄姆被问到了理想的语言。 他指出 ：“我的意思是，我们有一些初创公司使用PHP编写代码-这让我有些担心。 但是没有其他事情让我担心。”

作为工程师，您冒着加入初创企业的巨大风险。 您不应增加被炒作的风险，而应将不必要的技术添加到混合中。

雇用错误的工程师

雇用错误的工程师会导致许多启动工程问题。

新兴企业经常寻找“摇滚明星”或“忍者”。 他们想要华丽的教育证书和成功企业的一部分所带来的小小的灰尘。 在硅谷，初创职位发布会筛选使用新技术和闪亮技术的候选人，而不是偏爱务实的工程师，这些工程师可以快速学习必要的工具。 一旦公司以公认的“忍者”和“摇滚明星”开始，它将为以后的每位员工定下基调。

很少教授启动工程。 大量软件工程师为非初创公司工作。 因此，大多数加入初创公司的工程师都没有经过初学者的培训，也没有在初创环境中成功的技能或态度。 因此，初创企业通常必须依靠不太适合该项目的工程师。

这些工程师中的每一个都有自己的创业风险：

• 大型公司的工程师通常会接触到规模化的系统，并且可能对hacky代码不满意。 他们不太可能暴露给用户。
• 精英计算机科学家对代表早期启动任务的管道式工程感到无聊，从而导致工程过度。
• 经常被初创公司吸引的初级工程师可能会注入过多的新技术，而其系统架构也很差。
• 开发商店经常青睐能够使它们在许多客户中高效工作的技术。 这些商店没有动力为特定客户学习新工具，也没有在游戏中做出关键的早期技术决策所需的长期经验。

相比之下，理想的早期初创工程师对公司的使命感到兴奋。 这样可以确保他们在公司成功实现产品市场契合的过程中不可避免地遇到挑战时留下来。

他们具有最小的可行产品心态，并且具有不断迭代的舒适性。 最好的初创工程师通常在劳动力或开放源代码项目中都有几年的经验，因此他们学会了如何维护系统，而不仅仅是构建系统。

他们没有将特定的技术视为灵丹妙药，而是倾向于使用能够满足组织中期需求的生产工具。 伟大的早期创业工程师将技术视为解决问题的手段。 他们考虑问题空间（用户的需求）以及如何使用软件解决问题，而不是寻找新技术可以解决的问题。

他们需要有一个可以干的态度。 在面对（但不是拒绝）产品所有者的乐观情绪的同时，他们面对面前的严峻挑战。 这些工程师需要他们的用户换位思考和直觉，因为他们经常在迭代时扮演产品的角色。

一则注意事项。 即使在启动工程师中，在启动的每个阶段获得的经验也截然不同。 一个能在五位工程师身上发挥作用的初创工程师可能在25岁时就很糟糕。对于要聘请人才的初创企业来说，看到一个成功的初创企业中的一名工程师常常会淹没那个人实际在那做的细微差别。

初创企业应超越品牌名称，并根据当前项目的适合性聘用他们。

产品和管理问题

如此多的启动错误源于产品和管理，而不是工程。

初创公司的创始人非常乐观。 这样，产品路线图通常会超出其小型团队的能力。 这种乐观情绪会导致过多的招聘，过多的筹款活动，最终导致职业倦怠。 对于管理人员来说，这个周期看起来像是“工程师们没有表现出来”，这实际上意味着管理人员没有设定清晰而狭窄的愿景。

尽管业务模型中存在不确定性，但创始人始终坚持不懈的创业心态也使工程团队对如何构建系统产生了错误的确定性。 更好的心态是支持乐观的工程师并（内部）发展悲观的业务领导者，双方共同努力寻找适合市场的产品。

新创业公司的另一个问题是，管理层经常会找工程顾问（其他成功创业公司的工程师）来指导新公司。 当这些顾问将在其特定公司工作的东西移植到一个新的初创公司（他们花了几个小时试图理解）时，从潜在的不相关公司或领域中导入所谓的“专家”就产生了问题。

最后，管理层需要认识到其工程师是任何重大产品决策的关键组成部分。 通常，公司的工程师被视为一种服务组织，当重要的商业决策出现时，他们就会被推翻（确保健康的产品与工程的关系是聘请合适的工程师至关重要的另一个原因）。

不要脚踏实地创业

即使您避免了这些启动工程方面的陷阱，您仍将面临大量挑战。 但是，通过清除这些陷阱，您将不必担心自己造成的伤口。

在Twitter上关注我 -或访问 nemil.com/musings 了解更多 信息 。 您也可以 注册我的邮件列表 。

感谢Eddie Kim（Gusto联合创始人兼CTO），Andrew Miklas（PagerDuty联合创始人兼CTO），Shvet Jain（Spectrum 28 Capital合伙人），Michael Flaxman（Thumbtack创始合伙人; Priceonomics联合创始人），Nick DeMonner（联合创始人， Seneca Systems），Michael Lapinski博士（Decent创始人兼CTO）等人进行了激烈的辩论。 所有意见仅是我自己的。

翻译自: https://hackernoon.com/four-startup-engineering-killers-1fb5c498391d

四宫杀手数独题目