几年不见,打工人你好!
流年似水,物是人非,不是么~
我的编程之旅始于2012年,当时我还只是个C++编程实习生。说实话,我根本不知道自己在做什么。即使是到了现在,这种状况依然没有改变。不过,在这个过程中,我确实学到了很多东西。
问题来了:在程序员生涯中,你觉得什么语言最重要?
PHP?Python?还是Java?
对我来说,或许,跟同事、客户打交道的语言才至关重要。
编程是一项团队运动!
现在早已不是那个一把刀闯天下的年代了,更多是需要多元化技术团队的整合,才能够创造出一个出色的产品。
沟通技巧可以成就一个项目,也可能会毁了它。相比存粹的技术,软技能对一个项目的成功起到更重要的作用。我们需要学习如何与不同的人有效地交流我们的想法和思想,以解决我们(作为一个团队)面临的问题。
试想一下,你把世界上最好的 5 个数据库专家都请来了,但如果他们各自为政,互不沟通,最后他们只会给你搞出 5 个不同的 MySQL、Aurora 或 MongoDB 实例。
人一旦有了明确目标,效率和主动性会明显提高,就像我每每深夜读完鸡汤文,我就睡不着。其实,在工作中也是一样的。
作为软件开发人员,你的目标不应该只是把 JIRA 转换成 JavaScript,或者把 Github 中的项目变成 Java。
你的目标应该是用代码来解决问题。
如果你对要构建/维护的系统有深刻的了解,则可以在纯技术之外做出决策。这个功能是必需的吗?它解决了什么问题?可以用其他方式来解决这个问题吗?真的有必要解决这个问题吗?说真的,有时解决该问题甚至不需要任何代码。
这种思路有时被称之为业务环境,如果你想把工作做好,不仅应该了解环境,还应该能够塑造和影响环境。即使你在公司里不是Leader,也不影响你这么做,至少,你要明白自己在做什么。
好家伙,代码审查。
虽然没有必要那么想,但把自己写的代码放出来让其他人围观评论,这种体验跟写代码还真是有点不一样,也难怪人们会感到焦虑。
我亲自看到有人在X不在办公室或Y出差时提交代码审查,X是位出色的程序员,但对他的审查过程很多人都受够了。试想,如果你在一个新手的 PR 底下轰炸式地给出数十条不那么友好的评论,你其实不只是在证明自己作为一名高级程序员的优越感,也是在证明你不是一个“好人”。
那么,当我看到功能有很大漏洞时,该怎么办?
你可以私底下找那个人,跟他好好聊聊,问他为什么把代码写成那样。
其实大多数人也不想把代码写臭,如果你看到臭代码,他们也可能正在处理你不知道的问题。当然,也有可能是因为他们的编程技能还不够好,这个时候你要承担起导师
的角色,给他们提供一些指导。
墨菲定律:会出错的事情就一定会出错。
这是太真实的事情之一。设计系统时,请始终假定某些东西可能会损坏。
比如登录表单,请假设人们会将整本书复制并粘贴到“密码”字段中。
如果要构建所见即所得的窗口,请假设有人会尝试搞破坏,并且他们很可能会成功。
如果系统中使用了数据库,它一定会在某个时刻挂掉。如果你没有尝试使用备份来恢复数据库,那它们就算不上是备份。
如果你在给客户做演示,请确保这个演示在任何情况下都能正常进行,哪怕把它翻个底朝天,甚至是把它丢到水底下。
我们曾如此渴望命运的波澜,到最后才发现:人生最曼妙的风景,竟是内心的淡定与从容……我们曾如此期盼外界的认可,到最后才知道:世界是自己的,与他人毫无关系。 – 《一百岁感言》杨绛
这里用杨绛先生的话来当引子,作为一位工作多年的资深程序员,当别人问一些我不懂的问题时,我可以很淡然地告诉他们:这个东西我也不懂,因为以前没有遇到过,不过我可以看一下,然后再告诉你。
当我还是一个初级程序员的时候,我总是很害怕别人会看到我的无知。经过几年的磨练,我才明白,如果碰到了自己不懂的东西,说明学习的机会来了。终身学习绝对不只是一个“口头禅”,而是现实。
等你把不懂的东西搞懂了,记得把它们分享出来。写一篇博客,录个教学视频,或者在公司里搞个分享演讲……你不要认为你刚学会的东西别人也都懂,即使是一个非常资深的人,他们也能从初级人员身上学到东西,反过来也是。
分享的过程其实是一个检验你是否真正理解所学的东西的过程。有句话说得好:当你在教一个人的时候,其实有两个人在学。
记得早先在一个问答中问到:
你的编程能力从什么时候开始突飞猛进的?
有个回答我印象很深,说:突飞猛进往往是自然发生的。你在某个夜晚苦熬一个知识点时,不会觉得自己突飞猛进;只有在多年后某日熟练地给别人讲解这个知识点后,内心才会小小地波动一下,猛然忆起当年深夜中的青灯一盏。
共勉。
更多自学视频资料免费获取见主页。