Browse Source

Docsify Auto Published

willin 6 years ago
parent
commit
4704d2cfee
4 changed files with 87 additions and 2 deletions
  1. 2 1
      _sidebar.md
  2. 1 1
      mind/capability/define-good-employee.md
  3. 74 0
      mind/team/define-good-engineer.md
  4. 10 0
      mind/team/hire.md

+ 2 - 1
_sidebar.md

@@ -92,7 +92,6 @@
     - [MySQL向GraphQL迁移](experience/advanced/mysql-graphql.md)
 - 思想篇
   - 能力
-    - [好员工的定义](mind/capability/define-good-employee.md)
     - [新人成长](mind/capability/growth.md)
     - [学习能力](mind/capability/study.md)
     - [问题处理能力](mind/capability/solving.md)
@@ -102,6 +101,8 @@
     - [克服强迫症](mind/thinking/ocd.md)
     - [木桶效应](mind/thinking/buckets.md)
   - 团队建设
+    - [好员工的定义](mind/team/define-good-employee.md)
+    - [优秀工程师/程序员](mind/team/define-good-engineer.md)
     - [招聘原则](mind/team/hire.md)
     - [会议原则](mind/team/meeting.md)
     - [人才理念](mind/team/concept.md)

+ 1 - 1
mind/capability/define-good-employee.md

@@ -44,7 +44,7 @@
 
 有一句古话说:
 
-> 有志不在年高,不止空长百岁。
+> 有志不在年高,无志空长百岁。
 
 ### 自学能力
 

+ 74 - 0
mind/team/define-good-engineer.md

@@ -0,0 +1,74 @@
+# 优秀工程师(程序员)的定义
+
+很多人对于自己所处的身份并没有十分明确的认识. 技术人最初的身份可能只能算是一个工程师, 或者通俗的叫法为程序员.
+
+## 价值衡量
+
+如何评判一个工程师是否合格, 并不在于他实现了多少功能, 贡献了多么多的代码.
+
+就像我们在上学的时候也都在提倡德智体全面发展一样. 一个程序员, 本职的工作不仅仅是写代码. 随着科技的发展, 代码的价值会越来越低, 就像搬砖一样, 代码堆彻得多, 无非跟背得砖更多无差, 这种量的增长, 并不能带来更大的价值产出. 是的, 虽然我也一直不愿意面对这样的事实, 但现实是残酷的, 代码是廉价的.
+
+那么该如何评判是否是一名优秀的工程师(程序员)呢? 其实需要通过多个维度去衡量.
+
+## 1.思想
+
+要让其他人(无论是团队内的领导,同事,下属, 团队外的投资人,客户,用户)都能够轻易理解你的想法. 
+
+当然,很多时候我们并不会有很多机会直接与那么多人直接的面对面去沟通交流, 让对方了解你做的这个事情目的是什么, 意义是什么. 这就需要你通过其他的方法来让他们知道.
+
+价值评判物: **设计**.
+
+不懂设计, 就写不出好代码.
+
+!> P.S. 这里的设计, 指的不是用 PS, AI 之类的工具去做平面, UI的设计. 而是功能, 代码的设计. 在最初的时候, 可以参考借鉴既有的, 成熟的设计模式进行设计.
+
+一份优秀设计的参考标准:
+
+- 规范的文档和图(模型)
+- 简单, 清晰且全面的流程, 规避无意义的状态扭转
+- Less, More
+  - 用更少的描述, 让人更容易理解
+  - 用更少的说明, 表达更多的想法
+
+## 2.效率
+
+这是很多人在拼命追求和改善的, 但在实际的工作中, 我个人的感觉, 效率的确非常重要, 但往往任务不能按时交付并不是某个成员的效率低了.
+
+价值评判物: **单位时间工作产出** 及 **阶段性工作产出汇总**.
+
+很多人会只拿单位时间内的工作产出来衡量效率. 但这样是完全没有道理的, 有的人确实能力很强, 分了任务很快就能完成. 但完成了之后剩下的时间里, 既没有想着这么去优化, 也没有想怎么样自我提升, 就把时间又浪费掉了. 这样的"**高效**", 真的高效吗? 就像我们从小听的故事, 龟兔赛跑, 兔子睡了一觉, 就被乌龟超了过去.
+
+效率高的参考标准:
+
+- 同样的一个功能模块开发, 别人需要用2个小时完成, 而你只用了1个小时, 你的效率高一些. (`效率`与`质量`往往是需要关联起来衡量的,所以单独拿出来比较并没有任何的参考意义)
+- 时间管理
+  - 懂得如何将自己的任务分优先级, 规划得有条理, 并且能按时高质量交付
+  - 在团队协作中不浪费他人的时间及资源, 甚至能够帮助其他人提高效率
+- Less, More
+  - 更少的时间, 实现更多的功能 (注意, 并非贡献更多的代码)
+
+## 3.质量
+
+我个人感觉, 质量是最能评判一个优秀工程师的指标了. 因为`设计思想`, `代码`, `算法` 等等, 最终实现的成果, 都需要用质量来评判.
+
+价值评判物: **?** (真的是很难说什么东西能够直接体现出工作产出质量的)
+
+参考评判物: (按权重降序排列)
+
+1. 文档(设计)
+2. 测试报告
+3. 性能分析报告
+4. 代码(主要衡量: 业务逻辑, 算法)
+
+质量评判参考标准:
+
+- 各类文档完善程度
+- TDD/BDD 测试覆盖率 (95%以上)
+- 性能分析报告 (Apdex性能 0.9分以上, Bug率 1%以下)
+- 代码注释率 (10% 以上)
+- 代码重复率 (10% 以下)
+- Less, More
+  - 更少的代码, 实现更多的功能
+  - 更少的代码块, 更高的执行效率
+  - 更少的测试用例, 覆盖更多的可能性
+  - 更少的成本浪费, 更多的价值产出

+ 10 - 0
mind/team/hire.md

@@ -63,3 +63,13 @@
 ### 3.羞怯
 
 缺乏自信的表现,过于胆小被动,过于谨小慎微,或者过于关注自己,都不利于团队的良性发展。
+
+## 注意事项
+
+### 别让一颗老鼠屎, 坏了一锅粥
+
+宁愿能力低一些, 但一直都在持续不断的输出价值, 不能好高骛远, 成为团队里的搅屎棍. 脚踏实地, 踏踏实实做实事是每个员工应尽的义务和责任. 
+
+团队应该向着一个共同的目标去努力, 每个人都应该对未来有着明确的方向. 否则, 上班就像是混日子. 大家都拿着差不了太多的薪水, 凭什么有的人可以毫不努力, 却要享受着跟别人一样的工作待遇? 虽然可能只是这么一两个人的资源浪费, 但这却是对团队其他成员极其不负责任. 只要团队成员中有那么一两个人感到迷茫, 开始无所事事, 这种负能量就会很快渗透到整个团队中.
+
+团队发展应当有一个良性的趋势.