我每周会分享一下这周看到的好内容，加上自己的一些个人理解和评注，这算是一种比较轻的持续输出方式，前面三期为：
这是第 8 期。
Faster sorting with Go generics
Eli Bendersky 的技术文章可以作为技术写作的典范，他写这个博客已经 20 年了。
最近他写了一篇关于 Go 泛型的文章，通过排序算法来探索 Go 的泛型实现：
Faster sorting with Go generics - Eli Bendersky’s website
文中作者实现了两个版本的冒泡排序算法，第一个版本是通过 Interface 实现，第二个版本是用泛型实现的，通过 Benchmark 发现泛型版本要快 20%。
Go 团队核心成员 Russ Cox 之前写到过：
When a language decides on whether to have generics and how to implement them, it faces the following decision:
- do you want slow programmers, slow compilers and bloated binaries, or slow execution times?
不支持泛型就是 slow programmers，但是目前主流的泛型实现各有各的问题：
Slow compilers and bloated binaries 是指 C++ 那种 full monomorphization 的方式，编译器为每一处实际的泛型函数调用生成对应的函数代码，导致编译时间过长。写过 C++ 的程序员都有些体会，我以前那个公司的代码量也不至于很大，但是编译一遍得差不多一个小时。
Slow execution times 是指 Java 那种 dynamic dispatch，调用的时候会动态分发，导致运行时开销。
Go 团队采用了介于这两种之间的方法，像 int、string 这些原子型的类型就通过 full monomorphization 而其他复合类型使用 dynamic dispatch。
作者继续通过性能分析，对比反汇编后的指令来看这两者之间的差别。基于以上原理，上面的例子程序因为要排序的是 string 所以用的是 full monomorphization，这样对比 interface 版本少了 method dispatch 的时间，而且利用了编译器的另一个叫做 bounds-check elimination 的优化，这样 string 对比的时候没有 bound index 的检查。
不过既然 Go 采用的是混合的方式，也可能某些情况使用泛型的代码比 Interface 更慢，参考这篇文章： Generics can make your Go code slower
看起来 Eli Bendersky 的这篇文章也写了三周左右！他写博文通常会有完整的示例程序，非常严谨。
180 天，每天做个简单网页
After 180 Websites, I’m Ready to Start the Rest of My Life as a Coder
这位女生学习编程的方式非常独特：
- 连续 180 天
- 每天都完成一个虽然简单但足够完整的网页，写对应的博文
- 所有的代码都是开源在 Github 上
她是学美术出身的，但是对互联网很感兴趣，所以想自己试着做一些东西来分享美术。我随便选了一些她完成的网页，感觉有些想法和设计不错。
比如这个 窗户应用 的效果，看起来非常逼真，而且关闭窗户的时候声音也会跟着变。
在这个过程中她学到的最重要的是：
“Start Small. Keep Building.”
这个女生的学习编程的方法非常好！
我虽然编程很多年，但是前端开发很少涉及，去年我想做一些东西所以自学了些前端技能。自学时我发现最有用的是这个 Github 代码仓库 Mini projects built with HTML5, CSS, JavaScript ，如果一个前端新手，能把这些例子都看一遍，基本就能上手了。
有的人在学习编程的时候，会有一种学生思维，比如等我先学 HTML，然后再看完这本 css 的书，然后就可以继续学 JavaScript，然后再学 Vue 之类的。
这样很可能会磨灭学习兴趣，特别是对学习偏实际应用的前端技术而言，更好的学习路线就是想一个应用，做出来，然后再接着做更复杂的，在这个过程中边学边做，不懂的时候去补。我们要掌握的是能力，而不是知识。
Valve 的员工手册
Publications - Valve Corporation
这个员工手册有各种语言的版本，手册里面还配有漫画，写得也很简洁，非常用心。
Valve 的这种企业几乎是独一无二的，这是他们的组织架构随着人数的变化演变：
可以看到里面完全是自由组织的一些项目组，员工自己决定做什么，加入哪个小组，手册里还说明了如何快速移动办公桌，这样你就可以随意搬到自己喜欢的项目组🤣。
每个组都有一个组长一样的角色，但主要是承担沟通枢纽的职责，而不是纯粹的管理，Valve 认为完全按照等级制度来构建公司会有严重弊端：
等级制度会通过招募更多适合这一制度的人从而实现自我强化，让更多的人来充当下属的角色。最后，原先为客户服务的单纯目的将逐渐被成员利用体制谋求私利的欲望和行动所取代和吞噬。
员工的成长不是等级的攀升，而是能力和收入的提升，Valve 鼓励员工向各个方面多元发展自己的能力。
这样看起来每个人都在掌握方向盘：
那这样组建公司的前提是什么？
就是要招聘到能力强而又协作、沟通足够好的人，所以他们的第一任务是招聘。
看完他们的员工手册后，引起了我的一些思考，Valve 看起来像是构建了一个乌托邦，居然还运行得如此好。
等级制度的弊端我们很容易体会到，比如员工为了晋升可能会做一些短期就有成果的事，虽然员工晋升了，但是这些事对公司而言真的是有价值的么？比如我们看到，很多公司的中层管理肆意招聘，因为手下的人多往往意味着 visibility，这在很多快速扩张的公司并不少见，而当危机真正来临的时候，大量裁员就出现了。
为什么世界上绝大部分公司是按照等级的架构来组织的，我想这几乎是刻在人类基因里的，我们可以看到在动物世界里，大猩猩、猴子、狼群等都有类似的组织形式。
另一个原因大概是，大量的优秀而又善协作的人才太少了，等级制度可以认为是精英治理，最基层的员工做的活都是单一而细分的，这样员工都是可以随意替换。
而且世界上大部分公司，所需要做的事大量是实施类工作，而 Valve 这样的游戏公司需要的是很多创意，公司性质的不同也决定了不同的组织模式。
当然，世界上有 Valve 这样的公司真是太好了！我顺便看了看这篇文章： 关于 Steam、Valve 和 G 胖 你可能不知道的二三事
