六年软件工程师生涯:我学到的五个惨痛教训

译文
开发 项目管理
我本可以安排与该团队的一位负责人进行一对一交流,共同制定解决问题的计划,而不是仅仅提出问题,让任何人因问题而感到沮丧。尽管我的初衷是为了改进我们团队及客户体验,但我本可以在解决问题的过程中采取一种方式,让我们整个团队都能在这个过程中感受到积极正面的影响。

作者丨Jordan Cutler

编译丨诺亚

出品 | 51CTO技术栈(微信号:blog51cto)

作为一名高级软件工程师,我在迄今为止的职业生涯中领悟到了五大教训。可以说,这五个教训塑造了今天的我。当然,这些教训仅仅基于我个人的经验。您可能有过不同的经历,我的分享只是为了避免一部分人重蹈我的覆辙!

1.教训1:提出解决方法,而不单单是问题

当时我在一个团队中担任高级工程师职务,我们团队依赖于另外两个兄弟团队提供的数据支持。

问题来了:我们从其中一个兄弟团队获取的数据响应速度极为缓慢,由于向他们请求数据需要500毫秒至4秒的时间,这就导致了客户看到的加载时间长达3秒甚至更久。

那个团队也意识到了这个问题的存在,但他们正忙于应对各种优先级相当的竞争任务。更糟的是,我没有使情况得到任何改善。

我在团队回顾会议和团队沟通渠道中多次提及这一问题。单就指出问题而言,这并不是什么坏事。但我的态度传达出的信息是:“这是你们团队亟需解决的一个严重问题”,而不是“我们能否共同合作找出解决方案?”这样的协作态度。

直到我的经理给出反馈后,我才意识到我当时这么做的问题。

我本可以安排与该团队的一位负责人进行一对一交流,共同制定解决问题的计划,而不是仅仅提出问题,让任何人因问题而感到沮丧。尽管我的初衷是为了改进我们团队及客户体验,但我本可以在解决问题的过程中采取一种方式,让我们整个团队都能在这个过程中感受到积极正面的影响。

比如像这样:端点的性能问导致客户的加载时间超过 3 秒。我很乐意与您合作共同解决这个问题。我能提供什么帮助吗?

2.教训2:干净代码并不是终极目标

作为一名初级工程师,我在代码审查时极其严苛,坚决不让任何在我看来“不够美观”的代码进入生产环境。结果这让我的一位同事对我相当不满。

此事最终被上报给了我的上级经理,我们三人之间进行了一次对话并解决了问题,但这并非是一个令人愉快的局面。而且在这次事件之后,我并没有吸取应有的教训。

虽然我稍微有所收敛,但随后又因为我的评论意见,与另一位同事产生了分歧。

我们在GitHub上进行了多轮来回评论,双方关系因此变得紧张。

我当时询问了我的上级应该怎么办,他反问我:“如果你放弃一半的评论意见会怎样?每一条评论都值得争论吗?”

我的回答是:“代码可能会稍微不那么整洁。”

现在仔细想想:为了追求“代码整洁”,是否值得牺牲你与同事之间的和谐关系呢?答案显然是否定的。

于是,我开始对评论意见变得宽松。我减少了评论次数,明确区分哪些是小瑕疵,并且大部分时候我都选择批准,除非我有严重的疑虑或担忧。

结果如何呢?我的关于小瑕疵的评论更容易被接受。我和同事之间建立了信任关系。他们不再感觉受到攻击,而是觉得我们是在共同合作。

保持代码整洁并非最终目的,协作才是。

3.教训3:团队产出大于个人产出

我有一个坏习惯,就是在从事主要项目时容易被我能做的代码改进工作分散注意力。当然,适度地进行这种改进是可以接受的,毕竟在前进的过程中优化事物是有必要的。

但我会承担起一些完整的改进计划,比如对于JavaScript代码中的某些部分感到不满意,进而决定将40多个文件转换为TypeScript,并提交审查。  

幸运的是,至少我所做的事情通常都是组织内部已经达成共识的改进计划。然而,我没有充分认识到更大的全局性问题。我提交审查的所有代码不仅仅是占用了我的时间,同时也占用了队友们审查的时间,并且对我们团队来说,合并和部署未预先规划的工作意味着额外的风险。

我当时本可以专注于推动团队业务发展,例如:

* 向我的上级询问他们的首要关注点,并集中精力解决这些问题;

* 寻找方法协助团队完成任务; 

* 处理客户服务团队转交的bug报告。

那时,我过于专注于自己想做的事情,而忽视了团队的高级别目标以及如何推动这些目标向前发展。

有几件事让我意识到这一点。我的一名指导对象,另一位高级工程师,在短短6个月内就获得了晋升,原因就在于他具有这样的专注力。

他能够以极快的速度完成预期的工作,然后利用剩余时间来解决团队及其合作伙伴(如客户服务团队)面临的最大问题。

专注于团队成果,而非个人成果。

4.教训4:适应你的老板

尽管我们都希望能有一份与上司相处的万能指南,但实际上唯一有效的指南是那些教你如何适应不同上司的方法。

在我的职业生涯中,我曾有过五位直属上司,每次都需要针对具体情况做出适应。

举例来说,当涉及到晋升或职业发展规划时,有些上司会非常主动,明确告诉你需要做什么。而另一些上司可能由于工作繁忙,无法给予你那样的关注。在这种情况下,我不得不主动为自己制定一份计划,并寻求反馈意见。

5.教训5:影响力不在于措辞

长期以来,我一直阅读关于影响力和说服力的书籍,试图找出如何措辞以增强自己的影响力。

我听到过这样的建议:“让人们先答应一个小要求,这样他们在面对你的下一个请求时就已经处于‘愿意答应’的心理状态。”或者,“使用‘你是否愿意考虑’而不是‘你能否’,因为人们希望他人认同自己思想开明,他们会把‘愿意考虑’与开放心态联系起来。”

请注意,这些技巧确实有所帮助,并且在适当的情况下我会运用它们。但在影响力方面,它们并不是最有效的手段。

最具影响力的举动其实是建立人际关系。

我敢打赌,你不需要绞尽脑汁去思考如何向认识多年的好友提出请求,这是因为你们之间有着深厚的关系,朋友了解你的意图并且愿意提供帮助。

当我意识到这一点后,我把重心从“措辞”转移到了建立关系上。我开始与队友定期进行一对一交流,更多地赞扬他们的优秀工作,并抓住更多机会去支持他们。正是这种方式帮助我提升了影响力。

重点在于建立充满信任的人际关系——这样一来,你甚至无需担心如何去提出请求。

6.小结

长话短说,简单总结一下。

教训1:提出解决方案,而不是问题。重点展示你如何支持需要帮助的团队,即使只是作为顾问。

教训2:整洁的代码并不是最终目标。与团队有效协作比确保每一行代码尽可能干净更重要。

教训3:团队成果 > 个人成果。你花时间做的事情应该与能给团队带来最大影响的事情直接相关。

教训4:适应你的上级。每个老板的领导风格都会有所不同。了解如何适应其风格和目标,以实现最佳的集体成果。

教训5:影响力与措辞无关。专注于建立以信任为基础的关系。这比你如何选择你的表达技巧更重要。

参考链接:

https://careercutler.substack.com/p/5-lessons-i-learned-the-hard-way

责任编辑:武晓燕 来源: 51CTO技术栈
相关推荐

2020-03-16 14:25:57

软件开发 经验

2012-08-27 10:06:28

设计网站设计

2019-10-08 11:17:20

开发者技能工具

2009-02-23 11:22:29

系统架构师软件开发经验

2014-09-05 13:37:29

程序员

2010-08-30 10:32:59

2019-09-02 22:34:48

2018-10-11 20:57:40

工程师微软搜索引擎

2009-03-02 10:19:26

软件工程师职业生涯职业规划

2018-02-10 09:02:27

DevOps持续交付模型

2013-06-24 14:48:18

软件工程师

2013-06-24 14:55:18

软件工程师

2015-09-08 09:25:07

编程经验教训

2021-09-08 09:27:52

软件工程师技能算法

2012-08-27 09:40:07

2009-07-16 13:28:14

2014-09-22 09:47:14

2011-07-08 16:37:20

2009-11-04 10:57:35

2013-09-03 09:30:44

软件工程师软件工程师头衔
点赞
收藏

51CTO技术栈公众号