开发者讨厌图形界面吗
我们都看过那些10倍的开发人员 文章 （我写了一些-被控有罪！）。 因此，如果您想知道需要进行哪些工作以进行改进……那么，您将拥有大量资源。 但是，我很少碰到关于不该做什么或如何不以开发人员的行为的文章。 实际上，这可能是方程式中最重要的部分！
因此，早就该这样做了，我认为这是您应该真正快速进行的行为（如果您执行其中任何一项，则是最重要的）；）。 为什么？ 好吧，您可能不知道，但是您的同事可能会讨厌您，因为您很可能会对团队的整体生产力产生负面影响-至少！
如果您的团队中有这些开发人员之一，那么可能值得在您的Slack团队频道中分享此文章-出于普遍兴趣，您知道😉！
我将尝试从影响最大到影响最小的顺序排列列表。 我的目标是在列表上开始讨论并确定优先级。 所以请发表评论。
1.傲慢自大
在我看来，这是第一个。 您不能与自我吸收的开发人员一起工作。 我什至会说：
只要您愿意为错误负责并从中汲取教训，您就不是一个糟糕的开发人员。
傲慢使您认为您的代码是完美的。 您甚至可能将客户的愚蠢行为和程序崩溃归咎于客户，而不是反省您的软件为何崩溃。 这就是您得到的：
而且还会给您的队友带来混乱不堪的代码。
傲慢的问题在于，这种行为会阻止您的进步。 别再自大了，否则你只是迷失了方向。
你们中有些人可能已经知道邓宁-克鲁格效应。 我们将在列表中多次提及这种效果。 这是解释它的图：
傲慢自大的问题是：1）开发人员不了解他们是否处于“山顶”的顶峰。 愚蠢”，和2）他们将呆在那里。
2.工作中的草率
开发人员可以通过多种方式在交付的代码中表现出草率。 我们都知道至少一位开发商谁：
- 给出变量的隐名，或者充其量不言自明
- 将错别字放在函数名称中
- 在代码中留下旧的，过时的注释
- 显示数据类型和数据结构的选择不佳
- 尽管多次被告知可以不必运行代码格式化程序
- 忽略IDE警告
- 复制并粘贴StackOverflow代码，但不了解它或对解决方案进行调整以适合其自己的代码
- 无需花费时间来记录代码（没人想阅读整个函数或文件以了解其作用）
- 无法正确处理错误
- 使用过多的依赖，并在不考虑的情况下更新它们
- 不用理会添加到代码中的库或工具，可能会留下明显的问题
- 会始终坚持遵循“最佳实践”，而不理解为什么这些实践被认为是“最佳”（没有最佳实践可以适应每个团队）
不要成为这样的开发人员。 他们惹恼了同事。 他们减慢了整个团队的开发过程，要求队友在代码审查上花费不必要的时间。 他们的团队将害怕那些代码审查，变得不耐烦（我们仍然是人类），并且错误将通过网络传播。
解决此问题的最佳方法是让这些开发人员开始为自己的工作感到自豪（不要与第1点中提到的傲慢相混淆。
3.不尊重他人的时间
开发人员最讨厌的两件事是打扰和不必要的会议。 这并不奇怪，因为会议只是预定的中断。 开发人员无法轻易地回到中断之前的位置。 他们需要进入开发的思维定势，然后慢慢追溯到他们离开的地方。 每个开发人员都知道这一点。
因此，您可以通过以下几种方式不尊重同事的时间和生产力：
- 中断另一个明显不在该区域的开发人员的不重要的事情；
- 经常迟到会议，这是一个绝对的选择-不管别人怎么说。 参与者必须等待每个人都可以开始会议，或者在没有已故开发人员的情况下开始会议。 在后一种情况下，他或她将需要在某个时候加快速度，因此会浪费一些时间，而迟到将在任何情况下都中断会议的进行；
- 在会议期间不断逛逛。 或者，如果听众中有非编码员，则不愿适应听众，并浪费整个听众的时间，因为提出的任何观点都需要再次解释。
4.恒定负数
大多数开发人员都是热情的人，但有时您可能有机会（或不幸）与负面的人一起工作。 负性具有传染性。 如果有人抱怨，它将注意力集中在事物的消极方面。
他们会批评做出的每一个选择：例如，尽管语言在大多数情况下仍明显处于愚蠢山的顶部（在Dunning-Kruger效应中）。
别误会我 应该以建设性意见的形式提出一些批评。 例如，Scala开发人员可以与Java开发人员讨论诺言，说：“好的，您的语言不如我的：P。 但是您可以尝试CompletableFuture来体验一下monad是什么。 我将向您展示您可以做什么。” 但是不幸的是，这种友好的态度现在很少见。
5.贪婪
我敢肯定，你们所有人都偶尔会看到开发人员因团队制作的工作而获得好评。 这可以通过给管理人员的电子邮件，一对一谈话或其他偷偷摸摸的非直截了当的方式来完成。
开发商最重视能力。 为别人效忠就是为自己取胜，并将其从他或她身上删除。 这在我的名单上名列前茅，因为我感到这造成了很大的紧张感和不信任感。
对于贪婪的开发人员，此类策略可能会产生短期可见性。 但是从长远来看，它们将被疏远。 其他团队成员将发展他们的沟通，以更好地突出自己的贡献。 毕竟，有很多方法可以给人以荣誉。
6.无视团队
软件工程与设计师，产品经理和其他开发人员共同完成。 如果您不希望其他人进入绿巨人模式并翻转他们的办公桌，则必须尊重他们的输入和工作。 例如：
- “如何”文档：许多程序员在每一行代码中都发表了评论，却没有描述它为什么这样做。 如果程序中存在错误，而您偶然发现了这段代码，您将不知道从哪里开始。
- 实施丑陋的或不合规格的用户界面“因为他们不是设计师”
- 没有向产品经理提到UX问题，因为这不是他们的工作。 无视大局将使软件难以使用，维护成本高昂且与其他组件不一致。
- 不试图了解设计或产品决策的方式。 然后继续问同样不相关的问题-并且没有改善。
- 不考虑其他团队成员的优先级依赖性，而让他们陷入泥潭。
- 在不警告任何队友的情况下使用新工具/库。 这可能会导致无法预料的问题。
7.缺乏重点
工程团队解决问题。 他们使用自己的技术能力来构建功能部件/修复错误以解决这些问题。 一些开发人员只是忘记了这一点，就会：
- 对技术主题进行哲学思考，而不是专注于问题
- 在不考虑初始问题的情况下顽固地争论技术主题（尽管您确实需要在制定问题的解决方案时争论）
- 对这些技术主题进行了漫长的讨论，但依赖于他们自己的观点（而不是事实，事实解决问题，而不是观点）
当然，使用代码，您可以对同一个问题有几种解决方案，但是要么起作用，要么不起作用； 之间没有任何关系。 通过集中精力，您可以通过尝试例如沙盒中的代码轻松地减轻所有不确定性。 但是缺乏重点会浪费每个参与者的时间和生产力。
8.缺乏问责制
如上所述，代码要么起作用，要么不起作用，但是它需要与您的队友添加到代码库中的所有代码结合使用。 软件工程可能是当今世界上最协作的工作。 您编写的任何代码都将与其他开发人员进行交互。
因此，为了使您的团队正常工作，您需要承担责任。 当然，代码审查不会让您无所适从。 但是问责制是一种态度。
例如，不负责任的开发人员将提供借口而不是解决方案。 这些借口可能包括时间限制或任务的复杂性。 没有人想听到借口。 他们想了解解决方案要采取的步骤。 借口不会邀请其他人帮助或提供有关任务进度的好照片。
这是我的清单。 如有需要，可以随意添加更多，或提出不同的重要性顺序。
如果团队中有一个人该怎么办
您应该知道的第一件事是，这意味着您的经理没有履行职责。 如果问题被认为是可以指导的，则应该已经确定了问题并向有问题的开发人员提供了指导。 如果不良的开发人员仍在影响团队，经理应该发出警告并做出艰难的决定。
一个拥有不良开发人员的团队比拥有一个不良要素的人员更容易选择一名开发人员。
不了解这一点的经理就是不了解软件工程的经理。 您有一个糟糕的经理的情况，但这是另一篇文章;）。
所以你会怎么做？ 我想说这是您与经理一对一提出的问题，以便他们可以解决此问题。 如果您的经理什么都不做，那么您有几种选择：查看开发人员是否可以接受培训，并将其放在自己身上（并与其他队友合作），或更改团队/公司。 希望本文可以帮助说服所说的开发人员成为更好的同事。
你走之前…
学到了什么？ 不要犹豫，分享它以帮助他人找到它！
如果您对有关工程和产品领导力，生产力以及如何扩大团队规模的文章感兴趣，请订阅我们的新闻通讯！
或加入我们的工程领导社区 。
您也可以在Twitter上关注我以保持联系。 谢谢！
最初于 2019 年2月20日 在 anaxi.com 上 发布 。
翻译自: https://hackernoon.com/how-to-make-other-developers-hate-to-work-with-you-a920e3adab3a
开发者讨厌图形界面吗
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
