最近一个月,我做了两场线上的共读会,一场是3 月 1 日开始的 7 天;一场是从今天开始的 7天。
很多人不能理解,为什么你要做共读会?你明明是个程序员
对于我来说,做这个事情的理由还挺简单的:
- 因为我想读这本书,所以我就搞一个共读会,拉人和我一起读,确保我能把这本书给读了。
本来其实也没有太多的目的,所以我不会太在意有多少人和我一起读,我更在意的是,我自己有没有读过瘾。
最近一个月,我做了两场线上的共读会,一场是3 月 1 日开始的 7 天;一场是从今天开始的 7天。
很多人不能理解,为什么你要做共读会?你明明是个程序员
对于我来说,做这个事情的理由还挺简单的:
本来其实也没有太多的目的,所以我不会太在意有多少人和我一起读,我更在意的是,我自己有没有读过瘾。
我自己的 TITLE 变了几次,从「全栈工程师」到「全流程工程师」,始终没有变化的是, 是我对于技术的看法。
在过去TITLE是全栈工程师的时候,我认为技术是一个工具,因此我不希望以某一种技术来作为自己的 TITLE,我不是 PHP 工程师,也不是 Node.js 工程师,我就是一个工程师,我面向问题设计方案,解决问题。至于具体的技术是什么,并不重要,重要的是要把问题给搞定。
到了现在 TITLE 是全流程工程师的时候,我依然认为技术是一个工具,不同的是,我又向上抽了一层,现在不仅仅是技术是工具,产品、运营都是工具,对于我来说,只要能够让我解决问题,是不是我自己开发的工具并不重要。
我对技术没有追求么?有的,不然也不会这么折腾。
我对技术有追求么?没有的,因为我视技术为工具,并不太过在意它。
突然有一个想法,我应该去考公务员来着。
原因是
所有的非技术文章将继续在这里更新。技术相关文章将发布在 https://www.cnblogs.com/cloudkit/。
这里也会发布,首发博客园。如果你只对技术相关感兴趣,建议订阅博客园地址。

以训练营产生内容,作为基础,承载后续的活动。
Hakcthon 、有奖征集、TaskCoding 作为转化,产生产品的增长
线下布道 & 线上的布道可以产生新的流程,引入到训练营中。
这样,所有的活动被串联,所有的内容也被串联,形成了流量的闭环。

很多时候,我们都需要找到一个人的联系方式。但是,并不是每一次我们都可以很好的拿到他的联系方式,这个时候,我们就需要借助一些奇技淫巧来找到一个人的联系方式。
在我们使用 Git 进行版本控制时,一开始,我们会被要求设置一个 Git 的用户名和邮箱,就像下面这样。

后续,我们的每一个 Commit 都会基于我们填写的用户名和邮箱来进行存储。我们只需要查询一个人在 Github 的提交记录,就可以找到他填写在 Git 中的邮箱和名字,从而方便我们更进一步找到这个人。
想要通过 Git 找到一个人的邮箱,最简单的方法就是使用 Github 提供的 GraphQL 来进行查询,简单方便。
访问Github 的 GraphQL API Explorer,点击右侧的 Sign in ,使用你的 Github 账号登陆,这样就可以调用 Github 的 API 了。

登陆后,你下方的 GraphQL 输入框就可以输入内容了。在其中输入如下代码
{
repository(name: "grank", owner: "lctt") {
ref(qualifiedName: "master") {
target {
... on Commit {
id
history(first: 5) {
edges {
node {
author {
name
email
}
}
}
}
}
}
}
}
}
Code language: JavaScript (javascript)并将 name 替换为你要查询的人的 repo 名,owner 改为你需要查询的人的名字,然后点击执行按钮。

右侧会出现你的执行结果,你会发现,其中出现我们想要的“邮箱”地址。

你会发现,这里其实有两种类型的邮箱,一种是我们常见的,自己用的各种免费邮箱,比如 @qq.com、@gmail.com、@foxmail.com 之类的;另一种是形如 27856297+dependabot-preview[bot]@users.noreply.github.com 这样的邮箱。
这两种邮箱的区别是,前者是我们自己通过 git 设置的邮箱,而后者则是我们通过 Github 网页、 API 操作产生的 commit 。你在查询的时候,要记得去找第一类邮箱来作为参考。
当然,不排除有开发者在看了本篇文章后,去用 private 邮箱修改自己本地的 Git ,那就没办法了。
找到这个邮箱以后怎么办呢?
人需要有骨气,当不吃嗟来之食。
特别是你有的选择的时候。
在我看来,运营并不是一个好的工作岗位,原因在于,运营没有护城河。
作为工程师,你总有护城河,前端工程师的护城河是跨系统、跨浏览器的兼容、适配问题;后端工程师的护城河是系统性能优化。这些都是实打实的硬能力。回头看看,运营的护城河在哪里?

技能?可以快速学习到,很难快速做到 90 分,但快速 80 分并不成问题。
执行和规划?一个足够细致的 Todo List 可以解决绝大多数问题。
思维模式?这个是需要学习的,而且对于运营和开发来说没有区别。
什么样的东西才能算得上护城河?
第一、绝无仅有,是其他同事无法模仿或超越的。
第二、可持续,可以不断地使用,不断地加深加固。
从这个角度来看,上面图片所介绍的内容,都算不上护城河,也就是说,对于运营来说,很容易被别人所替代。
http://www.woshipm.com/zhichang/2625381.html
咨询了我的 Leader 以后,她给我的答复是这样的
如果你对于一件事本身不看重,那么你就无所谓其威胁
继全栈工程师之后,我给自己的全新定位从全栈工程师,变为了全流程工程师。
全栈工程师面向的是问题,你需要 Case By Case 解决问题,而全流程工程师,则从一个更高层面,以一个全局的视角来解决问题
全流程工程师

全流程工程师的工作不受限于具体的任务的分工,他更像是团队里的救火队长,横贯整个应用开发的所有流程,虽然看起来是一个打杂的,但因为掌握了整个流程的工作能力,也拥有更强的作战能力。