文章目录
  1. 1. 这不是我想做的
    1. 1.1. 业务需求 vs 技术需求
    2. 1.2. ToB vs ToC
    3. 1.3. 全栈?
  2. 2. 这不在我的工作范围内
    1. 2.1. 边缘工作该做吗?
    2. 2.2. 我该花时间在写 PPT 和文档上面吗
    3. 2.3. 结束语

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

这不是我想做的

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

业务需求 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 也好,文档、文章也好,将这些内容思路清晰地记录下来,才可以走得更远。

结束语

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

码生艰难,写文不易,给我家猪囤点猫粮了喵~

查看Github有更多内容噢:https://github.com/godbasin
更欢迎来被删的前端游乐场边撸猫边学前端噢
如果你想要关注日常生活中的我,欢迎关注“牧羊的猪”公众号噢

作者:被删

出处:https://godbasin.github.io

本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

文章目录
  1. 1. 这不是我想做的
    1. 1.1. 业务需求 vs 技术需求
    2. 1.2. ToB vs ToC
    3. 1.3. 全栈?
  2. 2. 这不在我的工作范围内
    1. 2.1. 边缘工作该做吗?
    2. 2.2. 我该花时间在写 PPT 和文档上面吗
    3. 2.3. 结束语