在日常工作里,我们常常会遇到一些不如预期的事情。我们在做的常常又不全是自己想要做的事情,要怎么去理解和面对这样的矛盾呢?

这不是我想做的

工作对于大多数的人来说,主要在于养家糊口。随着越来越多年轻人涌入程序员这个行业,大家的危机感慢慢浮现,想要保持竞争力、提升自我等念头让我们想得更多,也常常出现一些选择和矛盾的情况。

业务需求 vs 技术需求

做业务需求好,还是做技术需求好,大概是所有程序员都想过的事情,也是很多人会纠结的点。

一般来说,大家都会认为技术需求对个人的成长和提升帮助更大,同时技术需求也很少有业务面临的突发问题、外网投诉、活动发版等可能熬夜通宵的情况。而业务需求则有较可观的用户量,收益和稳定性可能会更好,但工作内容可能更偏向日常问题定位、产品需求的开发等“技术含量较低”的枯燥和重复性工作。

每天埋头写“差不多”代码的,羡慕做有挑战性的技术的。每天在做底层基础支撑的,苦恼于没有业务接入、团队面临调整等问题。

实际上业务需求也好,技术需求也好,我们都是在为某一个产品提供稳定、可靠的服务。对于业务来说,这个产品可能由产品经理提出需求而自己负责实现;而对于技术来说,这个产品则是由业务衍生出来的基础需求,需求的服务对象则是日常进行业务开发的人。

所有的技术需求都来源于业务的需要,自动化能力、灰度发布能力、监控告警能力、全链路跟踪能力等等,都是因为业务某个方面到达一定的瓶颈而提出的解决方案。

所以,对于做业务需求的小伙伴来说,需要关注到是什么导致了我们日常工作的枯燥,“重复性”的工作是否可以用工具解决?“相类似”的工作是否可以进行抽象然后提出解决方案?对于做业务的小伙伴来说,如果能积极思考和主动提出解决方案,也一样能获得很多的成长和机会。

对于做技术需求的小伙伴来说,需要关注我们正在做的事情,是否真的符合业务的需要?是可以让业务更加方便地使用,还是会给它们带来更多的麻烦?只有能贴切地解决业务的一些痛点,这样的技术方案才可能有更多的业务愿意接入,技术需求的意义才得以体现。

ToB vs ToC

对于前端同学来说,我们也常常会对 ToB 和 ToC 怎么选有过烦恼,其实区别更多在于用户群体和数量。

一般来说,ToB 的业务服务于某一类用户群体,因此会根据服务对象的不一样而工作重点有所区别。例如,如果服务于银行,则对技术方案要求严格,如果服务于政府机构,则可能需要兼容较低版本的 IE 浏览器,技术选型比较局限。但通常来说,ToB 业务的用户量并不会特别大,对性能要求较低,有些情况下也会由于机器部署环境封闭的原因,对网络和安全性要求较低,因此 ToB 业务可以更多关注开发效率提升、技术管理选型、项目可维护性等方面。

ToC 的业务用户量较大,对加载性能、浏览器兼容性等都要求很高,因此常常需要进行性能优化、兼容性检测、实时监控、SEO 优化等工作。

按理来说,在找工作的时候,ToC 业务的会比 ToB 业务的人优势要大一点,因为 ToC 对前端的各个角度要求都相对较高。但其实真正工作中,由于精力和工作内容分配的问题,很多参与 ToC 业务的人更多只关注自己负责的一小部分,因此其实并没有掌握到 ToC 业务的关键技术方案。而即使是在做 ToB 业务,也有不少小伙伴会有很多的时间去研究一些新技术、做很多的选型调研,也可以在这个过程中获得很好的成长。

所以,决定我们能否掌握更多的、成长更快的,最终还是一句话,要靠自己。

全栈?

如今随着 Node.js 的普及,也有不少的前端开发慢慢转型做全栈、大前端等方向。

的确,对于有全栈工作经验的人来说,找工作的时候会更吃香。但我们日常工作中是否都有机会去接触后台开发、客户端开发这些内容呢?我们是否一定需要有这样的工作经验才能获得更好的发展呢?

很多时候,前端由于入门简单的原因,很多的前端开发(包括我)都不是计算机专业出身。我们对于计算机基础、网络基础、算法和数据结构等内容掌握很少,更多时候是这些知识的缺乏阻碍了我们在程序员这一职业的发展,这也是为什么很多前端开发苦恼自己到达天花板,想着转型全栈或者后台就能走得更远。

这其实是个误区。后台开发由于开发语言、服务器管理、存储管理等工作内容的不一致,对于专业基础的要求更高,因此看上去似乎比前端能走得更远。但随着成熟的解决方案的出现,像分布式部署和管理、全链路跟踪等,以及运维和 DBA 等职位的出现、后台基本框架的完善,更多的后台开发技术选型的范围不大,在开发过程中也是偏向业务的开发,因此更多的关注点会落在业务风险梳理、问题定位和追踪、业务稳定性、效率提升等地方。而全栈中的后台开发,可能涉及的内容会更加局限一些。

所以,其实我们在日常工作中也可以更多地关注后台的实现和能力,除了可以更好地配合和理解后台的工作外,还可以提升自己对后台工作内容的理解。当然,最重要的其实依然是,我们需要扎实地补充计算机基础知识。

全栈开发经验可能让我们更容易地找到工作,但只有基础知识的掌握足够深入,才可以在接触后台开发、终端开发等内容的时候,有足够的能力去快速高效地解决问题。

这不在我的工作范围内

除了日常开发的内容,我们工作中也有不少其他各式各样的事情需要去做。有些人会想,我来这里并不是为了做这种事情,那么这种情况下要怎么处理呢?

边缘工作该做吗?

很多时候,我们所在的团队都会有很多边界不清晰、责任不明确的工作,例如会议纪要、值班查问题、组织团建等内容。一般来说组长调节好轮流负责是最好的,但事实上也有不少的团队会把这样的工作一直给到某个人,那么这样的情况要怎么处理呢?

大家都知道,这些工作会占用一些时间,而且经常需要做一些协调性的工作。如果你是一个希望专注技术成长的人,那想必会很烦恼。如果这种情况真的发生了,首先可以提出轮班的建议,如果老大觉得就是你做得最好一定要你做的话,可以尝试提升这部分工作的效率,同时把方案和步骤都写下来,再尝试让大家都参与进来。

那么如果其他人都真的“做不到”,你每天都得花上额外的时间来做的话,可以思考下自己能否承受得住这样的安排。这里的承受并不是指工作量太大,而是指个人对待这些事情的态度,毕竟如果给工作带来了情绪,才是最糟糕的结果。当然我们可以开放地接受最好,毕竟大多数人也只是来打份工的。

好的管理者会对一直承担边缘工作的小伙伴进行奖励,但也并不是全部都是这样的。实在不行的话,可以考虑再次反馈,最糟糕的情况下就得换个工作了。

我该花时间在写 PPT 和文档上面吗

这大概是所有程序员都脑壳疼的问题了,但是它确实一个比其他所谓边缘工作都要现实的问题。

那么,我需要学好怎么写 PPT 吗?答案是要的。我们的 PPT 并不需要画的跟设计童鞋一样漂亮,大白字、表情包都可以往里面贴,重点只有一个:逻辑思路清晰。其实写 PPT、写文章和文档这些很难吗?不难,只是比较花时间。但是在写的过程其实你会进行很多的思考,会发现一些之前并没有考虑到的事情,同时也能锻炼你的书面表达能力。

所以,你依然需要花适当的时间去对你的项目进行设计、整理和复盘,用你擅长的形式,不管是 PPT 也好,文档、文章也好,将这些内容思路清晰地记录下来,才可以走得更远。

结束语

工作里总有很多让人不舒服的事情,不过生活也是这样,大多数时候我们都无法改变环境,只能调整自己。让自己开心才是正经事!

部分文章中使用了一些网站的截图,如果涉及侵权,请告诉我删一下谢谢~
温馨提示喵