Thinking

在阳春三月,开启一段新的学习之旅

在今年春节结束之际,给自己订了学习计划:包括阅读一些书籍和在线课程,其目的是为了提高Go的技术水平。昨天,学习进度到了这项计划的里程碑——50%,而我毅然决然地放弃了之前的计划,花了约一天的时间说服自己制定新的计划并开启一段新的学习之旅。 文章接下来的内容会记录昨天思想斗争的片段,供未来回首。若对正在阅读此篇文章的你有帮助/启发,那真是笔者莫大的荣幸。若跟你的观点相悖,忽略以下内容即可。 从Java工程师转到Go工程师已经过去五个月(对于非程序员读者可以这样理解:从英语翻译员转到法语翻译员),现在笔者自认为处在初/中Go工程师的水平。如果按照之前订下的计划继续学习,再花几个月的时间也仅是横向扩展了知识面,对于Go语言的深度认知还会是欠缺的状态,这跟我想达到的目标不一致。 笔者不想再踩下以前学习Java的坑:“对于一个编程语言本身的设计思想,官方标准库的方法以及其它等等基础知识还没熟练掌握,就开始学习各种框架,第三方中间件的使用“。这虽然有益于快速上手企业的业务代码开发,可无益于做一个编程风格优秀的程序员,也很难在各大论坛/社区与其他优秀的程序员“对线”。 “愿意花时间横向扩展,而不愿意花时间纵向深究知识“这种现象的产生我认为一部分来自于各大企业的招聘需求,希望求职者什么技能都掌握。其实能猜到企业会将愿意将大部分投入放到招聘业务开发的程序员,毕竟业务开发直接与收入挂钩。现在还真没有勇气在简历上用“精通A”替换“掌握A, B, C”,因为在各招聘网站上发布的职位还是以业务开发的多,负责框架/中间件/容器等这类专项研发的职位相对少些。 也许很多人(至少我以前就是)就会用这些招聘需求来决定自己的学习方向,花了很多精力做知识面的横向扩展,希望在和别人聊到某项技术的时候,自己多多少少能接得上话题。这也为接下来我要聊的内容做个铺垫: “面向企业编程”还是“面向兴趣编程” 目标 做好自己的兴趣,总会有欣赏你的人/企业? 自己的未来应该由自己决定 “面向企业编程“还是“面向兴趣编程” 这个问题放在三年前刚毕业的时候,毫无疑问我会选择“面向企业编程”,因为当时还不明确自己的目标。说实话,我现在选择“面向兴趣编程”还是会有一丝担心,毕竟当大部分人还是选择“面向企业编程”,对于那些在人潮中逆行的人来说应该都会有怀疑自己的时候。 企业的职位需求可以作为参考之一,但不应该为你的学习/发展方向做决定。这是我现在践行的学习/发展方式,至于我的选择是不是最优解,就留给时间来证明吧。 目标 人的时间都是有限的,所以得根据目标对时间进行取舍。如果你的目标是成为首富,那可能要将更多的时间留给赚钱;如果你的目标是成为大多数企业都青睐的对象,那可能要将更多的时间花在学习企业的需求。 对于完成我自己的目标,可以允许我把更多的时间放在我的兴趣上(我的兴趣现在就是精通Go,包括设计思想,标准库方法等)。我认为在IT行业中,细分到某一专业领域,如果你对这一领域很感兴趣,只要你的水平在第一梯队中。我觉得收入也不会比其他热门专业领域少很多,至少应该能过上相对自在的生活。虽然收入相对没那么多,但是过得自在、快活。 显然,我不是要做赚最多钱的程序员,是想做个喜欢编程的程序员。 做好自己的兴趣,总会有欣赏你的人/企业? 其实这个小标题我的答案也不确定,但很多文章/故事给出来的答案总是积极的。我想,在IT行业中,做好自己的兴趣,应该不会失业,即使失业也不会为一日三餐发愁吧? 自己的未来应该由自己决定 现在有很多IT行业的大佬为分享自己的经历,不妨一看,但无法也不能照抄。可以作为参考,然后制定一个自己的目标和一份成长规划。即便以后没能实现自己的目标,也不会埋怨自己照抄了别人的人生规划。: -D 其实我觉得,只要是一个态度积极的人并且认真的做了分析和计划,即便没实现目标,也不会差到哪里去。 最后,分享一下我新的学习之旅将从《The...

Continue reading...

外包?非外包?哪种类型的IT公司你更青睐

很高兴这个标题把你吸引进来了,不得不承认,多少有点标题党的意思了。在你往下看之前,我想说明:文章内容都是出自于笔者亲身经历,且文中提到的两类公司都是中小企。目的是分享给一些有需要的小伙伴,大佬们可以直接忽略掉这篇文章了。 工作职责比较 各部门间的协调合作 部门内部的协调合作 个人的日常工作 项目/版本上线流程 工具的选择和使用 其它 面试经验 笔者在新公司已经工作一个多月。在这段时间里,我感受到工作职责与上一家外包公司有很多不同之处。趁着周末给自己做一下总结,也顺便分享给有想要了解这方面内容的你们。任何一种类型的公司,都有其利与弊,文中我尽量不带自己的情感偏好,把客观的事实展现出来。另外需要注意一点的是:文章中仅为个人经历的情况,并不代表所有公司都如此。 有一些小伙伴会私聊问我面经,所以在文章留了一节《面试经验》用来分享在之前的面试中被问到的部分问题,仅供参考。 工作职责比较 各部门间的协调合作 这部分会简单介绍一下组织架构,以及这些部门的协作。 外包 以业务范围划分,主要分为以下两个部门: 金融部 项目经理 售前组 前端开发组 后台开发组 客户端(IOS, Android)开发组 测试组 政务部 项目经理...

Continue reading...

结束Java工程师生涯,往新蓝海出发

一周前我入职了新公司,不再以Java工程师的身份。做出这个决定的难度可比写下这篇“看似吸引”的标题的难度大多了。除了想借此篇文章对上一份工作做一次总结,也想为自己留一份“记录”,用以回首这个职业生涯,甚至可能是人生的转折点。

Continue reading...

有感:代码审查

Hi, 好久没见,你还有在为一个月前时定下的目标在奋斗吗?笔者仍在朝目标前进噢。 距离一篇博文的发布已经过去一个月,在这段时间没更新博客的原因除了陪伴家人,还有还有因为项目投产接二连三地出现了问题,复盘后发现根本原因是团队沟通不足以及项目版本控制混乱。于是花了些时间和精力组织同事们将投产流程和版本控制梳理了一遍,整理出一些文档以供日后参考。 我现在多了一项工作——代码审查,其实刚开始会有抵触情绪,因为我觉得每个人应该对自己的代码负责。可是,作为团队的“小组长”有必要对项目负责,对客户负责。简单的功能测试可能会忽略掉一些BUG,例如流未关闭,这是需要压力测试才能反应出问题。按照公司现有流程,未必每一次上班都会做压力测试,所以现情况代码审查也是多了一重保障吧。当然,每个公司/组织的项目情况都不一样,还是需要视情况而定吧。 代码审查这项工作,让我觉得自己的责任又重了些,管理者的这个身份标识又更“锃亮”了。会有感慨:这就是程序员成长的必经之路吗?我现在所经历的事,似乎跟以往看过的一些《写在入职*周年》、《***的必经之路》所写的内容相差无几。不由感慨,原来自己的工作早就被预言过了 😀 最近朋友圈的封面换成了硅谷,先用做“望梅止渴”吧,希望有朝一日能去看看,即便是旅游。 感谢看完文章的你,如果你也在坚持一些事,也想跟别人诉说,欢迎在下方留言。成长路上很开心有你共行,谢谢,共勉。

Continue reading...

与FISCO BCOS同成长

Hi,各位读者,最近过的怎么样?在今天,我们一起告别了“难忘”的2020,迎来了崭新的2021,希望大家在新的一年能实现自己的愿望。还有,新年快乐!值此辞旧迎新之际,我想以此文记录我第一个接触的开源社区,以及和他的“故事”。 第一次接触FISCO BCOS社区的小伙伴是2018年在HK的CityU科技展上,我还很清楚地记得这两位小伙伴是David和Henry。和两位小伙伴在参展去交流了一些社区、行业发展的情况,互换了联系方式后,我便去会议室等待他们进一步的分享,当时FISCO BCOS的版本还是1.0x。道别后,可能大家都没想到三年后的今天,我们的交流会是如此频繁且密切。

Continue reading...

有感:英语与未来

这篇博文的内容并不是准备将英语的重要性夸赞一番,而是笔者不想一日发两篇博文,且两篇博文多少有些联系,那将「英文」与「未来」这两篇题材的博文写在一起业务大碍。 英语 回想三年前的大三暑假,或是因为着急证明自己,亦或是因为对未来的憧憬,笔者做了一个跟身边同学不一样的选择——投社招。给自留的退路是:若不成功就准备老老实实的回校当一名“在校大四学生”。当时投了三家公司,幸运的是投的第一家公司就给了OFFER,当时也没有面试经验,于是就直接拒绝了后面两家公司的面试,在这家公司一直工作到了现在。至今,在公司里,与大部分同事不同,我工作可能有三分之二的时间花在了调发新技术、新框架、新工具上。深刻体会到两样东西的重要性——「梯子」与「英语」。 梯子 梯子本身并不是一个好东西。最基本的,从我国法律的定义上来看这就是一个“不好的东西”。其实我也不大喜欢这个东西,因为搭建和使用这东西过程就像是与“长城”玩捉迷藏,得小心翼翼,且麻烦。但是通过它才能找到解决各种疑难杂症的解决办法,这些疑难杂症在百度上几乎是找不到解决方法的。 英语 学生时期英语一直不好,很多人也说英语不好不影响做程序员。确实,敲业务代码不需要英语很好,懂一些专业名词就够了。可是对于调研一些新技术,官方的文档就只有英文。如果英语对你来说还是很头疼的一件事,那英文文档就会成为绊脚石,太依靠翻译工具也只会弄得你晕头转向。对于国内外技术交流,若你只停步在与国内程序员交流,那这点大可忽略。 我英语的提升还得从刚入职公司后的三个月说起,当时主要的原因是觉得能像电影明星那样说一口流利的英语真的很酷,另一个原因是或许未来自己能用上英语进行商务交流。于是就自费上了两年的周末成人英语班,除了周末,工作日的晚上也需要完成线上作业,也忘记怎么坚持过来的,但是帮助确实挺大。特别是口语,进行日常交流不会有太大困难。笔者离开周末班也一直有在坚持学习,或许在未来会有更大的帮助。 不大理解一些同事,对于一些问题的解决方法,官方文档明明是最好的教程,为什么还要花很多时间找一些奇奇怪怪的方法,而且这些方法还不一定能从根本上解决问题。 未来 我也有梦想,想去大公司掌握一些新技术,规范自己的开发流程,有朝一日能做上IT公司高管。深圳是个令程序员向往的城市,当然也包括笔者。对于笔者有多向往呢?当我看到深圳的宣传片,就联想到了GOOGLE/APPLE/FACEBOOK等等这些众多的硅谷明星企业,或许深圳在我眼中就是中国的“硅谷”吧,着实令人着迷。对比了一下所在城市和深圳众公司的技术要求,发现自己技术似乎还不足以入职在深圳的大企业,无他,只能在工作之余抽更多的时间去提升自己的技术能力。生于忧患,死于安乐。

Continue reading...

有感:研发与开发

在毕业至今近乎三年的时间里,做过业务系统的开发,也帮助公司做过新技术的研发。从身边一些朋友的交谈中不难看出,“研发”好像相较于“开发”更加让人充满自豪感。在参与研发的前一年多我对这两词没什么认知和感想,现在通过视野的拓宽、兴趣的发掘、独立的思考,自己也有了一些看法。 一些读者或许能通过历史文章猜到,笔者在上段所述的新技术正是“区块链”。刚接触“区块链”不久,笔者也成了一个非区块链不可的人,研究底层技术,参与社区讨论,翻译白皮书,买卖“加密货币”,买矿机挖矿。除了技术研究外,韭菜该做的事情笔者应该都做齐了,更甚,还拉上了几个朋友一起“玩币”。结局:损失在自己能承受的范围内。 国内企业想要在“区块链”产业中发展,必然离不开另一种形式的“区块链”——联盟链。笔者所在的公司也必然存在这样的情况,当然选择发展何种类型的“区块链”,也是一步一步探索出来的,毕竟,公司在最初没有一个同事对区块链有着完整的认识。 着手研究“区块链”一年后,带着新技术做了DEMO,也做了两三个上线的案例。回过头总结发现,其实框架上是否加入区块链对项目的影响不大,甚至不用可能还会更方便一些。那为什么会用?中间当然有商业的因素。从技术角度上来想,也许一项新技术的盛行会经历这样一段尴尬期,一段“难落地”的尴尬期?笔者见识不广,猜测而已。 “开发”这词就相对来说更贴近生活一些,更多一些“烟火气”。这类业务系统更能为人们带来生活上的便利。笔者因为一些大赛,新认识的程序员朋友,生活上的一些经历。对软件开发有了一些变化,动力源于兴趣的比例变多了。于是开始用代码帮助身边的朋友解决一些生活上的问题(或者说是便利化吧)。曾经跟身边一些程序员朋友说“开发源于兴趣”的时候并没有什么共鸣,可能想法不同吧,无谓勉强。 个人感觉,“研发”除了技术层面的难以外,可能也难在短时间找到“落地”特别合适的项目吧。无论“研发”或“开发”,能真正帮助到人们减轻生活的负担,这才是笔者敲代码动力的源泉吧。如果这些代码也能让读者过上小资生活,那可真是太好了。

Continue reading...