心得体会

如何做一个称职的基层技术 Leader ?

首先来剖题,这里三个关键字:基层,代表再往下,就是一线程序员了,再没有下级了;技术,这里我狭义定义为程序员,别的领域仅供参考;Leader,也就是组长,或者叫领导,选英文是因为,组长和领导,我都能问出一股“官僚”气味,不想传递这种意思。

如果用选、育、用、留四个字来概括人力资源管理,那技术团队的组建,其实,就是一个“选”字。这个地方,往往实践的时候能发挥很大的主观能动性,在公司来说,其实就是招聘,展开来讲,就整个都是招聘、选人的技巧和标准了,那真的偏题太远,不展开了。

更多想分享的,是“如何当好组长”,也就是 Leader,这么一个话题。

Keep Reading — 1949 words totally

你该跟你的老大聊点什么?

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

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

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

Keep Reading — 2312 words totally

除了晋升管理岗位,还能给优秀码农奖励点什么?

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

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

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

Keep Reading — 2154 words totally

我为什么更喜欢用git

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

全分布式设计

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

Keep Reading — 2002 words totally

我们为什么需要版本控制系统?

甚至早在踏上程序员的工作岗位的第一天之前,我就开始使用版本控制系统了,那时候,使用的是SVN。而现在工作五年多了,我使用的版本控制系统,换成了Git。现在,我试图通过一个分享,将我的同事,或者一般的小伙伴,带入到Git的世界,这时候,我就必须搞清楚很多基本的问题,比如,这个问题,为什么我们需要使用版本控制系统呢?

上周五,我们公司新加入的工程师,给大伙分享了Git的一点经验心得,谈及这一类的问题的时候,表达了类似非常理所当然的态度,甚至我都不记得他有提及过任何相关的词句。但是,假如我现在必须给一个从来没有用过版本控制,甚至不知道版本控制的人,讲解版本控制系统的必要性的时候,这个问题真的有那么理所当然么?

Keep Reading — 1571 words totally