开发人员给自己的建议

2020-10-27 06:22:46

回首十多年前,有几件事我希望我能早点开始做。那些可以帮助我更快、更专注地成长的习惯。这是我给年轻时的自己的建议,他刚刚找到了他们的第一份专业软件工程工作。

每次我花时间慢慢地、彻底地阅读一本关于软件工程的推荐书时,我都会升级。通过适当的阅读,我指的是记笔记、与他人讨论章节、涂鸦图表、尝试、返回和重读。我希望我在做开发人员的头几年读过与软件相关的书籍。我是在我工程生涯的第五年才开始做这件事的。像“C#深度篇”、“干净的代码”和“Javascript:好的部分”这样的书在当时都帮助我提升了自己的手艺。这不是我推荐这些书的问题--反正有些书已经过时了。我推荐的是找一些比你现在知道的更深入的书。这可以是一本关于特定技术的书,也可以是一本关于软件工程实践的书。

当我读书时,我读得不快。事实上,我做得相当慢。我通常一口气读完一两章。我做笔记或做亮点。当我做完后,我会回顾一下,并经常与其他人讨论。我也开始在这个网站上写书评,主要是为了反思我学到的东西。在过去的几年里,我已经养成了这些习惯。作为一名工程经理,他们帮助我成长得更快:作为一名工程师,这个习惯对我很有帮助。在寻找书籍的灵感吗?这是我已经读过和正在读的书单。

为什么书籍胜过博客、视频或演讲?实际上,我会说书放在那些书的一边。与一本书相比,对于任何主题,较短的版式往往都是肤浅的。书籍是有深度、有条理的知识。写这样一篇帖子需要我几个小时,但我已经为我的“成长为一名软件工程师”这本书写了将近一年的时间。我认为书籍是一种速度较慢、但更有深度的消费形式。

不要雄心勃勃:每六个月读一本书就已经很棒了。挑选一本书,花时间好好读一读。在你读了一两本书之后,我还推荐一本书“如何阅读:智能阅读经典指南”。我对这个建议是认真的。

对于兼职工作,我开始使用PHP和一定级别的JavaScript进行编码。在大学里,我学过C和C++,这两门课我都不太喜欢。对于我的第一份全职工作,我开始学习C#。我在表面上懂很多语言,但没有一门真正懂得很好。

两年后,我开始为调试C#代码时必须依赖高级开发人员而烦恼。其中一位开发人员后来成为我的Goto调试伙伴,他似乎总是对语言的细节了如指掌。他向我深入推荐了C#这本书让我研读。我做了研究。我一直到线程,垃圾收集和泛型是如何在幕后工作的。我强迫自己花了无数个小时来理解协变、逆变和其他难以消化的话题。

深入学习我在工作中使用的语言是我做出的最好的决定之一。在我的第一个工作场所,这是偶然的,与资深开发人员激励我有关。然而,无论是在工作中,还是在面试其他工作时,这些知识都成为了一种优势。在我职业生涯的后期,我有意深入研究新的语言和框架。在Skype,我被聘为C#开发人员。但是,我们需要改用JavaScript和WinJS。因此,我深入研究了JS,掌握了WinJS,并通过Pluralsight课程教授它。

你懂的语言越多,你就越能评估它们的长处和短处。在我转到iOS之前,我已经精通了几种语言。当Swift出现时,我短暂地跟踪并参与了语言讨论,建议将ReadWrite反射添加到该语言的路线图中。了解该语言的特征可以更容易地决定我的团队应该使用什么策略从Objective-C迁移到SWIFT。而且你懂的语言越多,学习新的语言就越容易-当你需要这样做的时候,也会变得更容易。

这几天我觉得配对已经过时了。刚开始时,使用连续配对的极限编程、TDD和MOB编程都很流行。我的一些最大的职业飞跃是在与人结对之后出现的。这些飞跃比读任何一本书都更有意义。

一个令人难忘的配对是与一名开发人员的合作,他对每个人都进行了严厉的代码审查-包括我。有一天我受够了,我决定不在代码审查工具上回复,而是坐在他们旁边,请他们向我介绍他们的评论。我最终学到了很多东西--同时也告诉他们,我认为他们的评论不公平。他们注意到了,每次我觉得是这样的时候,他们就建议我配对。这就是我所做的。这位开发人员对性能代码很感兴趣,通过我的配对,我了解了潜在性能瓶颈的细节-作为回报,我想我教会了他们有关可维护性问题的知识。

另一个很棒的配对记忆是和另一位工程师一起做TDD,我们在编写测试和为其编写生产代码之间通过了键盘。我们这样做了两天,实现了系统的一个棘手部分。很难描述这个练习有多让人大开眼界。我们在中途完全改变了我们的方法,因为我们计算了所有的边缘情况。我们还与这个开发商建立了牢固的联系,这种联系将持续几个月。

高级工程师经常谈论单元测试的重要性。但整件事似乎太违反直觉了。为什么您要花更多的时间来编写看似琐碎的测试呢?这是我一段时间以来的测试方法。

为了欣赏单元测试的价值,您需要有这样的时刻,那就是您编写单元测试来挽救局面的那一刻。“。然而,要做到这一点,您需要咕噜咕噜,编写那些测试,让它们与CI一起运行。而且你通常需要花上几个月的时间,才能得到那一刻。

对我来说,我有过两次这样的时刻。第一次是我为一个小的在线赌场做后端引擎,作为一个副业。API管理的是真金白银,我害怕犯错误。所以我用单元测试覆盖了我的所有代码。该项目延迟了-部分原因是测试,因为它们花费了很多时间。但我觉得这样做是对的。在合同结束时,我把项目交给了客户。两年后,他们告诉我,如果不是因为测试失败,这些测试如何多次拯救了团队,他们即将在生产中推动错误。

我的另一个时刻是在网络上开发Skype。我们在web.sky pe.com上建立了一个绿地,Google Hangout的竞争对手。团队是一个强大的团队,我们有全面的单元覆盖和大量的集成测试。项目进行了三个月后,一位工程师决定我们需要重组整个项目的结构。这是一次非常冒险的重构,我们所有人都投票不这么做。

开发人员向我们提出质疑,说考虑到测试覆盖率,这应该是小菜一碟。如果测试通过,它就会起作用。我对此持怀疑态度。但这正是它的运作方式。经过一周的重构,他推动了一项巨大的变革。什么都没弄坏。不是那时,不是以后。所有测试都通过了。这就是我意识到强大的测试套件所提供的安全网,以及它如何让重构变得无所畏惧的时候。

多年来,当我与团队一起工作时,我更喜欢对代码库进行尽可能小的更改。对于我自己的个人项目,我做了大量的重构-但在我并不完全拥有的代码库上做这件事时,我从来都不舒服。

然后,我遇到了Skype的一位工程师,他会不断地进行或小或大的重构。它们都很有意义,代码总是变得更好。他们从来没有把事情搞砸。他们是怎么做到的?

当我与他们配对时,他们非常了解他们的IDE,并添加了重构扩展。提取一个方法,重命名一个变量,移动到一个常量...。他们花了一秒钟的时间。

我意识到我害怕重构,因为我错过了做好这项工作的实践和工具。当我开始让重构成为每周的习惯时,我在这两个方面都做得更好了。这个习惯后来帮了我很大的忙--我只是希望我不要花这么多年才开始养成这个习惯。

刚开始的时候,我常常被高级工程师吓倒。他们在我的代码中发现了我没有的错误,他们知道我一无所知的答案。我认为他们只是比我更聪明、更优秀,并接受事情就是这样。

现在我已经与许多著名的软件工程师密切合作,并指导了更多的人,我明白没有什么可吓倒的。最好的软件工程师兼具所学知识和实际经验。你能学到的知识。体验,你需要去追求。

寻找在不同堆栈、不同领域和具有挑战性的项目中工作的机会。我花了七八年时间才达到我认为的高级水平。我看到一些人加入了像优步这样的高增长地区,三四年后就会到达那里。有什么不同?这些人从事具有挑战性的项目,只是为了跟上周围其他人的步伐,而且经常在中途更换团队,重新开始。他们自愿从事新项目,并作为团队中的第一人试验新技术。我最终变成了这个人--但不是在我最初的几年里。

学东西最好的方法就是教它。我是不小心开始这么做的。2010年,我开始在.NET和Windows Phone用户组上做演讲。我的报告不好,但我通过准备就学到了很多。

这些天,当我想学好一些东西的时候,我会报名做一次公开演讲。我提出在加入优步一年后的2017年,就优步如何大规模推出后端变化做一个演讲。当我这样做的时候,我并不完全理解我们是如何做到这一点的--在那之前,我主要是做移动开发,并管理一个移动团队。通过这次谈话,我别无选择,只能了解所有的细节。我有很大的压力要这么做:大约有100名当地开发商报名参加了那次活动。

许多其他人对这种方法的效果发誓--肖恩·王就是#LearnInPublic方法的杰出人物。他的成长故事比我的更令人印象深刻:在四年内从转行到Netlify和AWS的高级工程师职位,并写了一本关于他的学习的书。教别人的好处是你只能赢。你不仅可以从教学中学到东西,还可以帮助和激励他人。

我不知道任何有经验的模范开发人员不是一个好的老师和导师。你越早开始回馈和教导,这就会越自然地到来。

它长达200页,讲述了一份优秀的开发人员简历是什么样子的,而且(可能)是目前最全面的指南。我得到了20多家科技公司招聘人员和招聘经理的帮助。它对任何和所有目前失业的开发人员都是免费的。拿到这儿来。

喜欢这篇文章吗?订阅我的时事通讯,并在您的收件箱中获取未来的帖子。这是一本相当不错的书,拥有超过3500名订阅者。

订阅我的时事通讯,了解实用的软件开发和工程职业发展的最新情况。