在其位 谋其职 负其责 尽其事

有一段时间没有更新过公众号和博客了,最近事情比较多且杂没有更多的精力编写博客。相信后面会好很多的

推荐 👍

。

讲真我从来没有写过一篇抒情类的文章,也许是因为最近事情太多或者是其他因素导致笔者想简述一下内心的想法;从工作的这几年来看,经历了各种职场的 PUA 也和形形色色的同事共事过,这也是本文想简单聊一下如何做一个好的同事。

1. 做一个负责任的人: 在其位 谋其职 负其责 尽其事 一个人大致分为, 工作中, 换工作中, 离职中三个状态；

• 离职中:写好离职交接文档, 尽可能多的想出自己负责的任务归纳总结好, 将自己负责的机器, 环境, git 地址以及一些特殊情况通过书面的形式告知下一位同学;
• 换工作中:可能这个时候你正在投简历或者面试, 但是作为一个基本的职场人, 应该将当前公司给你的任务按时按质的完成, 而不是想着自己马上就要换工作了不做好自己分内的事情;起码我们要有点职业道德。
• 工作中: 工作并不要求你一定要实时保持激情, 但是至少对于你自己编写的代码, api, readme 等文档要付责任；我一直认为写好 readme 文档是我们每一个同学都需要的;什么是好的代码？我想并没有一个绝对的标准, 但是至少一些复杂的逻辑注释是需要的。

2. 做一个诚实的人: 拒绝浪费你我时间

从今年年年初到现在面试过很多同学, 其中包括外包和社招/校招；简历造假在外包同学中占比幅度之大;为了能够得到面试的机会, 将自己的简历编写成符合面试条件的样子；却不知自己对其中的要求一点都不清楚。 笔者个人遇到的简历造假主要包括:

• 伪造自己的项目: 面试过超过 20+的外包,自己连自己的项目都不清楚,更有甚者直接告诉我说是培训机构让他这样写的;
• 伪造自己的技能: 我们团队的技术栈是 React,但是我们招聘的时候对是否具有 React 经验其实并么有那么看重, 很多同学为了增加简历通过率, 写着熟悉 React/Vue,精通 Webpack/css 等术语, 等问到 vue/webpack 的基础使用, 却不知道。

其实我并不反对大家些许夸大自己的简历, 但是也请在自己的可控范围之内吧, 今天面试了一个 4 年工作经验的 vue 开发同学, 连 vue 生命周期调用的次序,vuex 是什么都不知道。我想作为面试者 此时我的本质工作为 准备面试。当然准备面试并不意味着我们一定十分充分, 但是我想做了一个几年工作经验的同学, 非常基础的问题不至于不了解吧。

其次作为一个诚实的人, 答应别人什么时候完成任务, 做什么事情, 我想也应该按时按质完成。

3. 做一个自主学习的人: 更多的时间应该是去解决难以解决的问题, 而不是把时间浪费在百度都有无数解决方案的问题上

也许每个人的想法不一样, 但是就我个人而言, 想要在互联网行业谋求一份还不错的工作, 自主学习是必然的; 我们如何能够跟进同事的步伐,除开努力学习别无他法;繁忙的工作中有大量的问题出现, 有时候可能是一个非常简单的 css 问题, 有时候可能是浏览器的问题；但是当遇到问题的时候, 我们第一思考应该是:先自主解决, 实在解决不了再求助他人, 并做好问题的备份和记录

回顾我自己的博客, 很多文章是讲述某某方案,这也算是在工作中对问题的一种沉淀和积累;当我们遇到问题别人再帮你解决之后, 作为一个合格的开发同学, 做好问题的回溯和记录我觉得这是我们应该做的。 之所以有这样的想法是遇到过很多明明已经帮他解决过很多次的问题, 但是有些同学还是会不停的询问。

4. 做一个分得清轻重缓急的人

当多个任务并行时, 要分得清事情的轻重缓急；不要什么事情都想着做好, 最后发现什么事情都没有做好;比如现在有两个任务:一个任务明天项目上线, 一个任务后天转正答辩；此时应该如何选择？如果是我:

• 今天把项目的各种配置信息环境都准备好, 晚上加班把 ppt 准备好;【而不是今天只准备答辩或者环境】
• 明天继续跟进项目上线, 并同时找几位资深的同学一起帮忙 review 下 ppt;晚上再继续优化一下内容;【而不是只上线或者只准备 ppt】

5. 做一个有想法的人: 也许一份简单的工作却拥有不为人知的秘密

工作这么久也带过也许同学, 面对每一个新同学我都会讲, 在我们这边工作也许过一段时间之后你会发现开发活动其实是比较简单的的事情；如何在工作的同时提升自己的技术水平, 我们应该从当前的工作中反向思考一下:

• 我们当前的脚手架是怎么配置的?
• feflow 的整体设计思路是怎样的?怎么做插件化的？
• 监控怎么搞的？
• 测试环境又是如何实现的？

然而很多同学却认为我是给他们增加额外的工作, 不以为然。直到自己离开团队的时候, 发现什么都没学到。

6. 做一个善于发现及解决问题的人

能否快速的解决问题其实和一个人的阅历/工作经验是息息相关的;当遇到问题的时候, 我们能否在问题中发现出关键点的信息是很必要的；举个例子, 当构建项目失败出现一大堆报错的时候,一般会有Cause by等字样的内容;我们可以根据其进行解决；而不是将错误信息直接丢给其他同学让其帮忙看一下。

本文只是简单谈一下最近一来我的感受, 欢迎大家批评指正