软件开发人员的职业生涯可能是坎坷的。从一开始，你面临的挑战是技术层面的难关，对于这些难关你毫无解决办法。有些人可以很容易理解概念和原则，而另一些人却很难做到。这就需要你不断学习，而学习是一个艰难的过程。失败是经常的，成功只是偶然的。

在这个过程中，其中一个最大的挑战其实不是技术层面的，而是来自于社会的。在每攻克一个难关以后，你都能get到新的技能，然后再遇到新的挑战。当你开始一份新的工作或职位，发布一篇博客文章，提交请求或甚至制作产品时，会有很多人排队说你错的有多深，如果结果失败了，又会说你不够好。我就是来告诉你的，你的确就是这样！

我并不擅长处理羞辱、共情、脆弱这些问题，但是我知道我需要尽自己的一份力量，去唤醒人们的意识。请在阅读时牢记这一意图。

羞辱与内疚

内疚和羞愧就好比是同一枚硬币的两面。它们产生自同一个地方，但却有着完全不同的结果。让我们来看看它们分别是定义的。

内疚:是指为犯罪行为而负责的一种行为；是一种道德责任 - 出自The Free Dictionary

羞辱:是指由于人的行为，想法，情况或经验而被认为是或被其他人所认为是劣质或不配合的感情或尊重所造成的痛苦的情绪 - 出自The Free Dictionary

换句话说:内疚是你对自己的行为而产生的一种糟糕的感觉；羞辱是别人对你产生了不好的感觉。

内疚是一种你可以理解并从中学习的东西，而羞辱会让你质疑自己的价值。

在软件开发过程中，羞辱和内疚被用作一种强大的、破坏性的力量。开发者们在社交媒体、问答网站和其他在线游戏平台上争论不休。他们用极其严格的标准去对待他人，当别人做的事情没有达到他们的标准时，他们就会立即告知别人。这么做是为了确保你能够知道，他们认为不仅是你工作做的不够好，而且你这个人同样也不怎么好。

项目出问题时

如果由于你提交了一个小小的调整而导致项目构建有问题，在这种情况下，大多数团队都有自己的恶习，可能会把你叫出去训一顿，可能在开团队例会时进行批评，也有可能会惩罚你穿一件滑稽的帽子或者服装。

把那些导致项目出现问题的人叫出去训一顿，会让他们感到不安。出现一两次，你可能会觉得好玩，但是当它演变成一种相互指责的游戏的时候，也就是你认为是需要开始做出改变的时候了。也许你会开始怀疑自己的编程方式了？也许你的时间大部分都花在了去研究如何不出现问题上面，从而导致你不想去学习新的知识了？也许当下一个人也出现问题时，你也会指责他们，把他们叫出去训一顿？

年轻的工程师可能会因为过分在意项目出现问题而被摧毁掉，因此失去了一些宝贵的机会。这是反映这种情况的一个故事：“当你导致项目出现问题时该如何道歉”。

git的Pull Request功能和Code Reviews功能

当代码经过Pull Request和Code Reviews以后，你就相当于把你的作品展示给别人看了，并且需要他们进行评估，给出他们的反馈意见。但是问题是Code Review的作用就好比是足球场上的守门员，起到把控质量的作用，它是由那些根据自己喜好去制定标准的高级开发人员去执行的。这样就会导致复审后的评论可能五花八门，可能有人会反馈“我的一生当中我还没见过如此糟糕的代码”，也有人会反馈“代码还不是足够的好”。

我所做的一切都是为了得到公正的反馈，但是当一个开发人员在提交代码的时候被骚扰而导致出现问题，那么你也会羞辱他们。此外，由于复审工作是由开发人员自己直接做的，所以也很容易让人联想到“他们是糟糕的开发人员”。这样就会错过了学习的机会。

如果你不做X，你就不是一个好的开发者

软件开发是一个飞速发展的领域，很多人为了跟上发展的步伐而努力追赶，也变得很疲惫。一方面是因为这个领域有太多需要学习的编程语言。另一方面，同样需要学习的还包括很多技术和实践。

如果你都没有做过测试驱动开发，那你就不会是一名优秀的开发人员——互联网上的一些开发者这么认为

由于开发人员需要面临这么多需要学习的选择，如果你把这些选择和那些表明他的开发水平达不到平均水准的迹象相结合，但是忽略了他之所以达不到平均水准是因为有很多知识他们还没有接触过，其实这是不公平的。

遗留代码

很多开发者认为研究遗留代码完全是一种浪费，以此为耻，从来不花费任何代价在遗留代码上面。其实只要代码已经存在了一定的时间，不管它有没有经过测试，它都已经是遗留代码了。这样的态度表明，你很羞愧地认为遗留代码是不好的，但是它可以用作警告。

你不想基于遗留代码再次进行开发，是吗？–Scott Ford（说到关于羞辱时）

代码已经存在，就证明它是没有问题的，而且它还在生产中提供了价值。这可能并不容易理解，但是你凭什么认为你写的代码在接下来的5年时间内就能被另外一位开发人员所理解呢?实际上，你觉得你写的代码都能活5年吗?

我们使用的工具 - git blame

甚至连我们的工具也会对他们说No，比如git blame。Git是一个很棒的版本控制系统，它允许您以分布式的方式制作出色的软件。这些命令很简单，但功能强大，而且似乎有一种方法可以使用该工具完成任何事情。

其中一个命令是git blame，如果需要查出哪一行代码是由谁写的，这时候它就会显得非常有用了。这里的问题是wording。其实在跟是谁导致出现问题的人交谈之前，你的心里已经满是愤怒了，已经设想好了一大堆责备的话。但是也许你可以先找这个人谈谈，之后再去想想怎么进行责备。虽然仅仅只是做了个顺序的颠倒，但是这种改变可能会改变谈话的心情或者是语气。对于工具来说，它只是一个单词而已，但这个词本身是很有分量的。

多样性

很多人将目光放到了科技行业的多样性上面，无论是好的一面还是坏的一面。尽管如此，还是有一段很长的路需要走。当阅读关于人们为什么要退出科技行业的文章时，人们很容易认为“他们不够坚强”或者“他们只是在抱怨”。

对于那些拥有少数名族背景的人来说，在他们进入到这个行业之前，这些人可能已经就遭遇过被别人狠狠的羞辱过了。而当你所在的团队恰巧信奉上述那种文化的时候，有些人选择离开也没什么大惊小怪的。

脆弱性可以治愈羞辱

BrenéBrown博士是专门研究人的羞辱感和脆弱性的，她花了数年时间去钻研这些难题。皇天不负有心人，她多年的研究还是得到了回报，她在书中和TED演讲视频里面将这些成果分享了出来。

据Brown博士介绍，如果同时浇注了脆弱性和共情时，羞耻感是无法进行生存的。脆弱、开放、诚实和关心是消除羞耻感的方法。当然这些也能是人与人之间产生更紧密的联系。

并不都是糟糕的

我仿佛描绘了一幅相当黯淡的图画，画里面充满了各种消极的情绪，但同时我也描绘出了很多希望。共情、同情、工作地点快乐最近是很热门的话题。

有一些播客可以专门帮助软件开发人员去解决一些非技术方面的问题，比如Developer on Fire，>Code (编码以外的)以及Developer Tea。很多公司把共情作为一种核心思想。似

乎有一定数量的人让自己变得脆弱，分享他们的故事。

最后:虽然我并不擅长处理这些问题，但是我也是曾经遇到过。我鼓励你去查看Brené Brown博士的一些作品。

很多开发者经过历练已经养成了“厚脸皮”，或者他们也已经有自己的策略从而去避免冲突。有些人可能非常幸运，因为他们所在的团队可能并不信奉羞愧论。其实说到底这就是一个关于如何在人际关系中建立信任的问题。当你有了信任，你就会知道每个人的最大极限在哪里。

我们应该做得更好一点。在软件行业里，初级或者没有经验的工程师的数量是要高于高级或者是有经验的（不记得是在Robert C. Martin那里无意听到的还是从别的地方）。也就是说，在态度和指导上有很多的学习经验并不能传递给年轻一代。由于我们是这个圈子里面的一员，所以我们有义务让其他人都能意识到尊重每个人的重要性。

我们中的任何人都可以就“如何在生活或者工作中避免让他人有羞愧感”这个问题贡献自己的一份力量。我知道我能够做得更好，那你呢？

Tags: 恶习 行业 软件

分享到：