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

这不是我想做的

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

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

结束语

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