习惯是一种可怕的力量。 它使您抵抗变化，阻碍发展。 但是在IT领域，我们喜欢站在技术的最前沿，我们喜欢挑战，我们喜欢实施仅在短短几年内就会传播到其他领域的东西。
我们已经为新事物做好了准备，可能不会等到未来来临，我们将不得不适应它。 我们可以前进，只知道朝哪个方向。
Egor Bugaenko知道现在要做什么才能在5-10年内保持受欢迎的程序员。 一如既往，他的想法似乎有争议。 您无需无条件地同意他们的意见，但是例如考虑一下有关宠物项目的问题就不会再次受到伤害。 程序员需要英语这一事实，几乎没有不同意见。 但是，在剩下的几点上，在评论中了解社区意见将很有趣。
接下来是Egor在
AppsConf上的报告的文本版本，但他不仅提及移动开发，还提及整个行业。 Egor Bugaenko，Zerocracy的创始人，Cactoos，Takes Framework，JCabi和其他开源项目的开发人员。 他撰写了一系列名为“ Elegant Objects”的书籍，维护了一个挑衅性的
博客，并提供了诸如此类的令人发指的报告。
我将从一个故事开始，这个故事是关于不久前我决定开始为移动设备开发软件的，但很快就发生冲突，因为我不知道该怎么做。 因此，我决定寻求别人的帮助，他们会告诉我如何以完全打包的形式创建应用程序。 也就是说，制作一个将在Apple Store上可用的应用程序。
我想知道如何将应用程序组装到一个程序包中，也就是说，不仅要在屏幕上绘制一些按钮，还要制作
整个应用程序 。 显然，例如，Swift上的代码和手机上的产品，是两个完全不同的东西：第一个很小，第二个很大，并包含以下问题：
- 单元测试
- 静态分析；
- 持续整合
- 依赖管理；
- 持续交付；
- 登台环境；
- 应用程序在Apple Store上批准流程
- 组装生产缺陷等的过程
如何在屏幕上排列按钮很容易在Internet上阅读。 我需要一个专家，一个专家来帮助我组装整个管道。 对我来说，作为一名程序员，这比在屏幕上排列按钮更重要。
我找到了这样的专家，但他告诉我：“您为什么要考虑这一点？ 首先绘制应用程序。 什么是持续集成？ 等到单元测试-使它起作用。 什么是交付管道？ 为什么选择TestFlight-使用模拟器。”
当然，他是一个优秀的程序员，但在我看来，在他的脑海中，
一切都被颠倒了 。 他认为代码很重要，其余的包装是次要的。 我认为这是一个大问题，我想谈一谈。
由于某些原因，许多开发人员认为
代码本身很重要，而汇编是 DevOps 工程师或其他人所做的事情。 通常，当您进入团队时，它已经完成并配置。 您发现自己在编写代码的项目中，却不知道一切最终如何在生产中完成。 我相信程序员看不到完整的汇编周期，也不知道它是如何工作的，这是一个问题。
首先部署，然后编码
我写过有关编程的书，而且我自己也知道，
如果您首先设计精美的
书 ，那
本书就会奏效 。 也就是说，我在写书之前先设计好这本书。 首先，我制作一个makefile，该文件直接从命令行从LaTeX上的文件中收集整本书，准备文本，图片和封面。 我花费了大量时间，并通过一个命令将整本书收集为PDF文件。 我非常注意它的外观，缩进在哪里，哪些文本块以及它们之间的距离，页面的编号方式。 当我喜欢这一切时，即使到目前为止只写了一页纸，我也看到所有东西都组装得很漂亮，并且本产品中的所有东西都是完整的，才开始写书，这才给我带来快乐。
程序员通常会做相反的事情：他们编写，在模拟器上运行，检查工作。 我认为
先部署然后再部署代码是更正确的。
我再举一个例子。 一位新手开发人员自愿与我们一起做一个开源项目。 他选择Flutter，进行了第一次迭代，开始了它，并说一切都很酷，而且愿意提供外观。 我们问：“如何尝试？ 这是iPhone —可以推到哪里？” 他开始解释，去哪里，下载什么是一个漫长的过程。
这让我们感到不舒服，最后，他同意将应用程序确实需要上载到TestFlight。 一段时间后，他在TestFlight上显示了该应用程序。 我按下按钮，发现一些缺陷。 我没有和Flutter一起工作，也并不想这么做，但是我想快速解决我发现的问题。 我问如何做到这一点，在哪里以及如何发送拉取请求。 我打开存储库，自述文件：“这是一个很棒的应用程序……单击下载……”。
这些说明是复杂且难以理解的，我再次询问如何在我的计算机上部署所有这些。 我只想通过在计算机上单击几下按钮来修改别人的代码，启动模拟器并发送拉取请求。 那家伙去形容这一切，再也没有回来。
这种情况说明他作为程序员的素质很好-他能够运行该应用程序。 但是，作为一个能够看到整个项目的人，他的素质仍然有很多不足之处。 结果，该项目不仅使我失去了作为贡献者的权利，而且也失去了许多其他人。 这个程序员没有收到别人的回报，他像一个孤独的人一样工作。
我认为，
孤独现在
是错误的 。 市场正朝着人口更大的团队发展：他们中会有更多的人，他们来回的频率会更高。
人力资源的动态正在朝着更高的人员流动方向发展，因此每个再次参加该项目的人都需要完整地了解它，而不仅仅是在模拟器上运行的代码。
从汇编的角度来看，新手应该进入一个对他友好的环境-他需要打开一个自述文件，并在几分钟后了解如何使所有内容都在模拟器上启动。 单击以检查是否所有内容都是从命令行构建的，而不是从需要再配置几个小时的复杂IDE构建而成。 应该可以在命令行上编写make / build /etc。 之后，将收集所有内容并打印一条绿线-一切就绪-然后拉请求。 这是我今天要分享的第一个想法。
当然，您会说您不是一个人工作，不是作为项目的唯一创始人，也不是作为CTO。 您与团队合作，您不能只是说现在要处理部署，TestFlight，并且需要紧急了解CI。 这不是您的任务，不会给您时间，等等。
因此，我建议您做自己的宠物项目-您自己做的项目-全面了解所有内容。
只有20-30％的程序员拥有自己的已发布应用程序，每个人都应该拥有它。 如果您考虑自己并想成为一名受追捧的程序员，我建议您制作移动应用程序，并完成其进入市场的整个周期：检查Apple Store，CI，包装和其他所有内容。 使它开源，以便人们可以做出贡献并向您展示他们如何失败。
查看您如何与市场合作，尝试并了解您是哪种类型的程序员。 我认为没有宠物项目的程序员是不好的。
他或者对自己的职业不感兴趣，或者他不在乎，或者他不感兴趣，或者害怕。 担心看到整个周期。 我们很害怕将项目视为准备好为客户准备的产品。 在很多情况下，我们的客户是另一位开发人员，例如在我的示例中，我是Flutter的客户开发人员。
我认为，第二个恐惧是金钱。
您将为100美元编写多少代码？
我在Zerocracy平台上与许多程序员一起工作，并注意到他们经常害怕钱。 他们习惯于在月底付款，而且当他们以货币计价时，他们会非常痛苦。 许多人无法回答这个简单的问题：“您知道您可以用100美元制作多少代码？”
您当然知道每个月要赚多少。 想象一下您一整个月的生活费用：一间公寓，一辆汽车，定期付款，通常的舒适度和娱乐度。
全职，固定薪水的开发人员时间已用完。
我认为我们将在临时组建的团队中开展越来越多的工作，在这些团队中，人们会在需要的时候来，然后再进一步。 开发人员坐在一个地方的时代已经离开，因为该公司很多年前就聘请了他们，他们只是喜欢这家公司，因此他们也与它在一起-公司使用什么技术都没有关系。
我知道用C ++编写多年的此类项目的示例，然后意识到他们需要用Java编写。 同样的人，在同一间办公室，为同一位投资者进行资金转换，需要再培训半年，然后开始摇摇欲坠地使用Java。 这是过去的方法。 我认为，将来这种方法将不复存在，因为它们将毫无意义。
市场正在变得全球化 ；对劳动力市场的远程访问变得越来越容易。 设在莫斯科的一家公司对人员进行再培训将毫无兴趣且无利可图，例如，从iOS到Android或从C ++到Java的再培训。 雇用新的专家来做自由职业者，完成任务然后离职比较容易。
我认为这种形式的项目将会很受欢迎：在自由职业者见面的临时项目上，完成他们的任务-一位专家，另一位专家，然后离开。
程序员新的期望是：
- 了解您的价值的能力。 也就是说，估算一下您的工作时间价值多少，以及将为其创造多少价值。
- 能够在临时条件下工作。
- 推销自己的技巧，正确呈现。 全球市场上的自由开发者必须具有“交易优势”和价格。
许多人害怕建立简历，害怕推销自己。 正如我所说，我认为摘要中肯定包含宠物项目。
自己的项目将成为市场价值的第一指标 ，而不是您连续5年开发继承软件的位置。 您是从头开始创建Pet项目的，它的用途，复杂程度或在Apple Store上的下载量无关紧要。 设为0个赞和2个下载，但这是您自己创建的一个完整项目。
在我看来，作为雇主，这些人比那些已经在办公室工作多年并拥有一两个雇主的简历的人更有价值。 我很难理解如何与这个人打交道，如何评估他。 我知道他要我整个月坚持下去，无论结果如何，都可以和他成为朋友。 对于我来说，这种格式现在是不可接受的，对于将来的许多雇主来说，这也将是不舒服的。
因此，建议是
数钱，尝试按合同工作 。 也许这不太适合您的雇主，但请尝试全职工作并坐在办公室，同时寻找一些兼职工作的微型项目。 不是为了钱，而是为了了解市场是否需要您作为自由职业者，以及您是否需要作为专家。 或者，您只需要害怕失去您的老板，因为只有您知道项目代码的工作原理。
寻找替代方案，看看，尝试，出售 。 起初您不会被购买，会有问题-很多问题！ 但是解决这些问题，您将成为更高层次上更受欢迎的程序员。
不幸的是，不仅程序员自己无法确定工作价格，而且客户也无法确定。 有时他们建议我以专家身份执行某些任务。 通常，为我提供工作的客户不了解如何评估我。 人们常常只希望更便宜，例如每小时50美元，而不是100美元。 我了解采用这种方法的人仍然无法理解我将在这小时内实时写多少内容。 然后，我同意并将小时数乘以2。结果，我得到了原本想要的一切。
我知道我的真正价值和速度。 客户不愿意为每小时100-500美元的金额做好准备，因为他们已经习惯了20个小时的全职工作格式，这对他们来说已经是很多了。 就是说，当一个人收到他据称用于发展的时间的钱时。
我不认识你，但是我不能坐8个小时来编写代码。 我确信你们每个人都会确认在办公室或计算机上的8个工作小时内，您实际上编写的代码更少了。 他们支付这8个小时的费用，而客户认为这是8个小时的工作。 这是一个双重欺骗的体系：他们很高兴被欺骗，而我们正在欺骗他们。 因此，我使用乘法因子。 我至少要工作20个，但是我将在3个小时内完成2个小时内的实际工作。
教您的客户，并学习如何自己数钱。
好的程序员写代码，最好的-门票
客户和程序员都习惯于非正式交流。
以聊天，电话，聚会，电子邮件等形式进行的非正式沟通是一种破坏项目的沟通方式，只会使客户和程序员变得更糟。
非正式交流仍然存在，它没有记录在文档中，也没有受到监视，因此很难返回，并且使项目难以维护。 当团队发生变化时，正如我之前所说，团队必须进行变化并且将进行更深入的变化，因此如何理解项目中的过去交流变得非常重要。
如果我要去开发项目，我想了解过去一年中所做的事情，不仅是代码形式，还要对代码有某种解释：为什么选择这样的框架或算法，谁已经表达了对该算法的意见我不同意。 我想看到所有这些，而不是在办公室里聊天或找可以向我解释一切的人聊天。 我需要有机会直接在存储库或票证系统中阅读此内容。
不幸的是，大多数情况下程序员会跟随客户。 当然，为了客户的利益，有机会与开发人员进行非正式的交流。 我们发现自己足够虚弱并跟随他们的领导，在电话上倾听应该做的事情，回答，倾听，回答……然后我们去做。
然后经过2-3周，我们不再记得我们达成的共识。 客户说他不想要这个，我们试图证明这是他的要求，我们正在聊天中寻找提及-跳蚤捕捞开始了。
我认为原因是担心票务系统。 我们与之合作的许多程序员（当然，这也涉及到您）不知道如何，不喜欢，不希望以票证的形式制定任务-简洁明了。
人们说起来容易些：“让我们聊一聊！” 我们将举行一次集会，坐下来共同决定一切。 我们将在3个小时内相互了解，然后我去编码。 我会记得我们已经达成的共识，并将对所有程序进行编程。” 忘记什么，再见面。 因此，我们将以某种方式从集会延伸到集会。
错了 作为程序员，我们必须将任何非正式交流都转换成票证。 我们与客户（客户，产品所有者，另一位程序员）进行了交谈，找出了需要更改的内容-我们将任何通信都转换为受系统框架（Jira，GitHub等）限制的票证，并在其中写下：不起作用，如何工作您需要修复它，为什么需要修复它，什么动机，然后我们才能处理此故障单。
程序员无法组织门票中的工作可能表明他的资格较低。 我相信有两种发展类型：
- 持续开发 -从上午9点到下午5点编程：我到了，打开了计算机，然后我做了点什么，在那里，午餐，我也编码了，一天结束了-好吧，明天我会继续。 也就是说，我们在充满活力，时间和力量的同时进行编程。
- 增量开发是不同的：任务编号为13，直到最后，然后再看下一步是什么。 以这种形式，任务（票证）将始终完成。 但是，如果没有凭单，就没有制定的文档化任务，项目就不会移动-不会编写代码，也不会出现拉取请求。
我经常发现自己在第一种情况下工作。 我喜欢编程，早上我打开计算机，然后开车离开。 然后我刹车-停止，让我们将其划分为任务，确定我们将移至哪个任务。
在第二个版本中，每张票证都以拉取请求结尾：这是问题，它的描述，此问题领域的讨论，代码的更改。 拉取请求已发送，已验证，已接受-票证已关闭，您可以继续下一个。
通常人们都是双向工作。 但是由于某种原因，我们面临的主要问题之一是：人们根本不知道如何将任务分解为较小的任务。
有些人错误地认为，增量开发必然意味着需要进行为期2周的任务，并且凭单应以5,000条变更线的拉动请求结束。 这不是增量开发。 增量任务的执行时间为0.5–2个小时，并在50-100行代码的拉取请求结束时执行。 相反，连续工作-您需要长时间（几天，几周）工作，却很少产出。
因此，我说好的程序员写代码，但是最好写票。
编写代码比买一张合格的票更容易 -这很好地解释了为什么需要编写此代码。 因此，如果您想发展和提高自己的水平，则应着重于向其他程序员解释需要做什么的能力，以及倾听客户或客户并将其思想转化为凭单的能力。
我将举一个生活的例子。 最近，我们有一个客户，与许多其他客户一样，想通过电话解释项目的实质。 他多次与我们的一位建筑师通电话。 一周后，我发现尽管讨论正在进行中，甚至可能正在编写某种代码，但系统中只有一张票。 这是一个建筑师的错误，因为他收到了信息流却没有构造它。 然后，如果项目中有问题，我们将无法解决不满意的客户。 我们不会增加电话交谈的日志。
这只是建筑师的错误。 客户不需要知道这一点。 客户是一个混乱，无纪律的生物，在发育过程中很少了解。 他应该是那样。 但是
我们的任务是要纪律严明 ，所以要写票，结构。
首先要学习哪种编程语言？ 英文！
我经常遇到并且要注意的下一个问题是英语。 许多说俄语的开发人员忽略了英语，认为英语是次要的，不想学习，否则他们很难授课。 在IT领域中，有一个说俄语的社区，在我看来，我们必须与之竭尽全力。 哈勃（Habr），作为这个社区的先驱，提供了伤害。
当然，俄语是我们的母语，没有必要拒绝它。 但是，在与您阅读的票证，代码，会议，书籍相同的领域，我认为我们应该切换到
仅英语格式 。
正如我所说的那样，发展世界正在全球化，来自莫斯科的程序员将越来越少-例如，只有Swift上的程序员，并且很少有人在莫斯科关心您。 程序员将通过互联网而不是通过办公室采访在全世界推销自己。 即使在5-10-15年之后，这个市场也会以某种方式出现，您可能会被排除在外。
您认为与俄语的同胞交流比较容易。 Telegram-, , . — , . , , .
, . , .
, .
. , , .
. . , -, . , , , . — . . , , , .
. , , , . , .
—
. Twitter, , Telegram- . , . .
, , , , . , , , , , — .
5-10 . 2 , , .
, . — . , , .
GitHub —
, open source , 10–15 open source, (NASA ).
, .
open source . , — . : , pull requests , , GitHub, .
open source- . open source-, , , .
, , . — open source, ? , , , — .
, — , . , , . open source- . open source community: , -, , pulll request, .
open source-, : , , — - . 2 300 followers GitHub — , 6 .
— , . -, , . , .
, . , . , , , , . — , 25 , , community .
, . , . , full-time, . , .
— , . , 20 Twitter 2 GitHub, . open source-, , . .
— .
2000 , 2019. 2029 . , , followers, , .
, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .
— . .