今天,知乎《北美码农的包子铺》专栏里,提到了,跟老板 1 on 1 聊天时讲什么的话题,文章是站在一个员工的角度讲的。

正好,最近我在做绩效面谈,我想站在 leader 或者说 mentor 角度讲讲同一个问题。这样未免有些恬不知耻,也不能涵盖所有的情况,但是我觉得说不定还是能给新人一些参考。

逻辑思维,我只看过一期节目,但是一直印象深刻,就是讲我们这个时代的人,应该怎么自处,在这一期节目中,罗胖提到了“U盘型人才”,以及“手艺人”的概念。我深以为然。大体意思就是说,你在这个时代应该像一个U盘一样,有自己独特的功能,而且极其专业化,到了任何一个企业,插上就能用。这个话,有好几层意思,一个是说“专业”,有自己独特而且强大的技能,所以又叫“手艺人”;还有一层意思就是说,聘任关系,相比从前,表现出了更多的不稳定性,人才随时可以从一个企业“拔出”,然后“插入”到另一个企业。

Keep Reading — 2312 words totally

以前一直没有使用 zsh,理由是,这不是一个默认安装的 shell,我所工作的环境一般都是 Linux 服务器环境,一般系统默认不会安装这个 shell 的。另外,bash 我也没有使用得多熟练,为了逼自己熟练掌握 bash,不用 zsh。

听起来好有道理的样子,我竟然信了。这个里面,我忽略了最重要的一点,就是趣味。

其实,日常需要在 shell 下完成的事情,就那么一点,如果不是刻意去训练,使用任何一种 shell 的水平根本不会进步,如果刻意去训练的话,我想,任何一种 shell 都可以使用得不错的。而我这个人如果用不上,根本不可能去刻意训练的。

Keep Reading — 536 words totally

因为网络原因,可能导致某些静态文件无法被用户直接访问到,我这里提供一种解决方案。

我发现,不知因为什么原因,我博客里引用的 Google API 提供的静态类库和字体样式,是没法正确加载的。比如:

https:/ /fonts.googleapis.com/css?family=Open+Sans%3A300italic%2C400italic%2C600italic%2C300%2C400%2C600&subset=latin%2Clatin-ext

Keep Reading — 736 words totally

你手下有一群很棒的工程师,并且,他们想要在自己的职业生涯中更进一步。由于他们付出的努力,他们的团队在成长,而你,想要对他们的工作成果有所表示,最显而易见的一个方式,就是让他们负责管理他们自己创建的团队,尤其,他们已经是团队的事实上的 Leader 了。但是,这真的是他们想要的么?或者只是他们所相信的“自己应该想要的”?

人事管理是一种(与技术)不同的技能

在工程世界广为人知的一个事实是,只要学会一整套新的技能,工程师就能达到一个技术的巅峰,而围绕他们这段职业生涯的“社交”和“软实力”则可能被忽略了。为了掌握这一整套技能,他们进行了无数的试错,并花费了他们绝大部分的时间。现在,他们却不是把时间花在写代码上——这是他们本来被奖励的原因。突然间,他们就从很擅长他们的工作,变得不擅长自己的工作,这摧毁了他们的自信和工作满意度。

Keep Reading — 2154 words totally

当我在使用git的时候,有三个东西的出现,一度让我非常困扰,就如题所述,staging,index,和cache。

比如,当我阅读git官网提供的电子书《Pro Git》的时候,最初一章里,就提到,文件在git里面,有三种状态,working copy,staging area,和 in repository。而在读一些man pages的时候,比如git-reset命令,又会看到index,这非常让人困扰。而git-rm 指令又有一个参数叫 –cached,其作用是”unstage and remove paths only from the index”,更加奇怪了,同时提到了stage和index,而参数名竟然是cached!!!

Keep Reading — 1261 words totally

前端技术和工程实践真的是突飞猛进啊,想当年,我这个半业余前端吭哧吭哧做页面的时候,哪有这么多东西可以用啊,现在先进到我都完全看不懂了。本文主要讲一下同是包管理器的bower和npm的差别。

主要也是在stackoverflow看来的,翻译加一部分自己的理解。

npm 是伴随 Node.js 出现的一个包管理器,最开始只能支持 Node.js 的模块管理,但是后来, npm 官网经过一次改版,打出的口号是,javascript 的包管理器,所以,其已经不在局限于是

Keep Reading — 584 words totally

之前,我写了一篇文章《SVN为什么比git更好》,主要是从非常朴实和现实的角度,从一个为全团队选型的角度,分析了为什么SVN比git更好。但是公私分明,作为我个人来说,我想我还是更喜欢git的。

全分布式设计

分布式计算,早就是这个时代的趋势和潮流了,为什么版本控制不应该分布式呢?分布式到底有何好处呢?很多书会写,每个拷贝,都是整个版本库的镜像,(这是优点么?),灾难恢复比较容易,(因为每个人镜像的人,都是整个全部版本库,多少个人克隆,就等同于多少分备份,那么当然灾难恢复容易,不过这跟我到底什么关系?那是运维的事情),去中心化,(那又怎么样?写代码难道还要民主不成?),这些分布式带来的好处,感觉都有点隔靴搔痒的感觉。

Keep Reading — 2002 words totally

SVN为什么比git更好

首先我表明一个根本的立场,我个人更喜欢用git,但是,这仅仅是一个个人偏好。当我们需要将一种技术方案带给整个团队的时候,并不是由我们的个人偏好作为主要决定因素,而应该充分去权衡利弊,选择对团队,对公司更有效率的方案。抛开个人立场,理性评估利弊,可能才是我认可的一个资深程序员,或者一个架构师的本分。

我所在的团队,现在选用的技术方案是git作为全公司的版本控制系统,我们一共有差不多20个程序员,使用五种以上的程序设计语言,研发维护四个左右的项目,属于小型创业公司中,研发规模中等偏上的企业。使用git作为版本控制系统,在我加入公司之前,已经是既成事实了,在我听说这一点的时候,我非常高兴,因为我说过,我喜欢git。

Keep Reading — 2641 words totally