成为一个高级程序员,不必担心自己的技术过时

2021/01/15

前言

程序员是吃青春饭的吗?等我们老了,技术过时了,公司有什么理由不裁掉我们,去雇一些既有活力、薪资要求又低的年轻人呢?这个老生常谈的问题困扰着诸多渐入中年的程序员。本文告诉你如何增强自己的核心竞争力,在知识飞速更新的行业中站稳脚跟,跨过“初级工程师”和“高级工程师”之间的鸿沟。

1、高级工程师

软技能

包括下面4点,这些软技能可能会成倍地增加我们工作的影响力

  • 代码审查礼节;
  • 如何优雅地遏制范围蔓延;
  • 如何向其他部门直观的方式解释高科技问题;
  • 如何在生产任务爆满和日以继夜的比赛中保持镇定自若等。

解决问题

作为一名程序员 ,编码硬实力固然很重要,但公司为何在花点小钱就能打发刚入行的新人的情况下,仍然乐于向我们这些“老年人”支付大笔工资,那是因为高级开发者,避免下面的问题

1、你的代码的可维护性如何?是否有其他工程师不停地轻敲你的肩膀,让你解释你代码的每一行都是如何工作的?你的变量名具有描述性吗?你的方法是直观、易理解的吗?当你发现自己在复制粘贴很多行代码时,你是否能将这些代码的功能写入可重用的服务中?

2、别人能够从你在拉取请求中留下的评论中受益吗?你的反馈意见是有建设性,还是太过粗糙?当你发现别人的知识存在缺口时,你只是告诉他们“把这条线从ABC更改为XYZ”,还是有能力引导他们认识到自己的方法可能不是最佳方法,让他们成长为更优秀的开发者?毕竟,同样是学习新东西,授人以鱼不如授之以渔。

3、如果今天有100,000个用户创建帐户,你的代码是否会开始引发大量超时和500个错误?你能保证公关能把这事儿兜住吗?你的程序支持高并发,高可用吗

4、你如何将非常技术的问题分解为公司其他部门可以理解的简单语言?向市场解释为什么一个功能实际上不可行时,你是否会让大量的工程术语从嘴里溜出来?

5、你对面向对象的编程有深刻的了解吗?你提出的系统架构是不是“顶多算说得通”?

6、你是否会主动提出想法,使你的团队效率更高?当需要改动现有进程时,你是否能够向所有参与方说明收益?你能使所有人都对这一变化感到兴奋吗?你是否可以持续跟进,并确保新流程确实有效?

7、你要尊重别人的时间,当你要求别人帮助你解决问题时,你能准确描述你遇到问题的代码库的确切定位(如抛出异常的行号、你在问别人之前已经尝试过的debug方法,免得别人再浪费时间重复你已经做过的工作),在别人走到你办公桌前,你已经整理好要问的问题并在MacBook上打开了。

8、在与其他部门一起确定大型项目的范围时,你对要开发的新功能的问题了解得有多深入?在开始编码之前,你是否能够考虑到每个边缘情况?你是否能够及早识别范围蔓延并尽早制止,从而使团队免于周六加班?

9、你的多任务处理能力如何?你的大脑会超负荷吗?同样,在处理大型功能时,比如涉及50个文件的功能……你可以一次将它们全部保存在脑海中吗?你有养成扎实的记笔记习惯吗?你打算如何计划跟踪今天下班前弹出的500万件事?

10、领导可以放心地让你去负责面试候选人吗?你是否擅长通过有限的信息来对人员进行分类,并可视化他们和团队的适合程度?你能识别出在什么情况下,在工程方面优秀的候选人却不能很好地融入公司文化吗?这种候选人你会建议录取吗?同样,即使你和候选人在Zoom里聊了5分钟就知道他不可能被录取,你是否还可以确保他仍然可以从你们的聊天中学到东西?毕竟,语言在网络上的传播速度是很快的。

11、你知道如何向你的下属反馈他们的绩效吗?你和他们有良好的工作关系吗?你是否将他们视为敌人?你是否正在积极尝试减轻他们的压力,使他们的生活更轻松?你是否曾经说过“你们那边有什么烦人的任务我可以帮忙削减吗”?公司雇人都是有原因的,你的下属可能比你想象的更有经验和资格。

12、你有能力扑灭生产大火吗?你是否会在遇到大麻烦时惊慌、不知所措(比如AWS中断使网站瘫痪、不小心搞丢了customer_invoices表单、某些错误导致了不同用户帐户之间的数据泄漏等)?你是会在压力之下崩溃,还是会在解决问题的同时保持镇静,并与其他部门进行有效的沟通?

高级开发者,就会在工作中解决问题,而非制造问题。

他们减少压力。他们按时完成任务。他们知道如何编写经得起时间考验、可维护的代码。他们值得更高的工资。他们对项目的方向可以有准确的把控。他们可以发现当前流程中的缺陷,并使每个人都接受他们的想法以进行改进。他们可以指导应届毕业生。他们处事冷静,不会在周二与你的最大客户的电话会议上情绪崩溃、破口大骂。

很多人想踏实当个技术人员,并不想一直向上升去当领导当主管,我认为这种想法没什么问题。编程是目前最令人鼓舞的职业之一,许多企业愿意给经验丰富的“老兵”开很多很多工资,来保证业务进行顺利。

回顾我的旅程,能从初级开发者过渡到高级开发者,归功于我每周(在繁重的编码任务之间)都试着花几个小时专注于以下事件:

  • 改进我们进行技术面试的方式,保证我们与候选人之间的沟通信噪比更高(如改善我们的面试问题、重新考虑我们的电子邮件模板、考虑是否要给面试者布置线下笔试题、反思我们对工作的描述是否准确、我们向哪里投放招聘广告、换位思考如果我正在寻找工作会如何回复该招聘信息、如何在候选人做出决定之前使其更深入地了解我们的公司文化和发展历程等等)。
  • 与产品团队合作,以更细致的方式对即将开展的工作进行分类,从而使产品团队和最终要去接收JIRA tickets的工程师之间的沟通更加顺畅,而不需要磨叽好几个来回。
  • 组织团建活动和团队聚餐。
  • 当CEO/CTO为即将到来的季度制定的目标听起来有点过于乐观时,向他们提出提醒和意见,以免团队其他成员受不了过分辛苦的工作而逃离你们公司。
  • 最好能每周与所有大的客户进行一次确认电话(亲自回答他们所有的技术问题,并确保双方之间的关系保持健康)。

  • 用6个月的时间进行积极的安全审核,不断提醒客户我们会认真对待他们的隐私,并在公司发展的每个检查点努力完善我们的流程。
  • 找出其他开发人员在知识上的不足之处,然后让他们查缺补漏(使用能激发他们学习兴趣的方式):如使用vim宏处理CSV文件、Linux终端中实用的短命令、高级SQL命令、如何使PR描述更具描述性、解释负载平衡器如何工作、讨论合并和重新定基之间的区别等
  • 帮助设计团队在花数小时将线框转换为高保真模型之前,先弄清楚哪些功能易于开发。
  • 改进我们的流程,让其他部门知道何时会增加新功能(编写更好的发行说明、在每周的内部产品演示中回答他们的问题、帮助他们编写客户能理解的外部文档),因为没人知道的功能不会解决任何实际问题。

最终发现更多的是偏向管理,站在一个大整体的高度上去看待问题。

Post Directory