本节列举了一些在我的团队中工作默认遵守的原则（强制要求）。 绝大部分原则是不区分实习生（intern）和正式员工（staff）以及具有自治和指挥权的领主（lord）的。
我所组建和管理的团队，一般采用精英自治模式。 这要求每一位成员都具有高度的自主性、高度的技术能力和自我管理意识，同时能够同团队其他成员、以及整个团队实际要达到的目标出发进行事态分析和预测执行。
对于实习生而言，我内心并不想要降低要求。我相信优秀的人不是顿悟然后战斗力爆炸的，是通过长年累月的积累形成的。 注意，请注意，这里有一个误区。或者换个说法，现在我要开始揭示一个你可能从未认识到的事实： 这些我很珍视的品质，这种在劳动力市场上难能可贵的能力，并不需要任何超过平均值的智商、情商、数学功底、计算机功底、抑或其他任何需要痛苦自律才达到。 相反的，完全相反的，这些珍贵的品质，是需要对接下来我列出来的这些看起来微不足道的原则的遵守。
成为我的团队的一员，长期的那种，一个必须的前提是 Be Humble，谦卑。毕竟， 要相信只要遵守这些看起来是鸡毛蒜皮的守则就可以成为我刚才提到的顶级优秀的人才，并不是很容易。
没有会议纪要的会议或谈话，不曾发生过。
内部系统没有记录的任务，没有发生过。
未能讲授分享的知识，未能掌握。
任何离开 git repo 的代码，都是尸体（corpus）。
是真的。严谨百度网盘或者X网盘下载。如果下载速度慢或者被墙，找mentor。
做学生的时候，一般的工作流程是，有一个问题，分析，Google下代码，复制粘贴，修改。 It works，交作业。
但是做项目的时候是严格禁止直接复制粘贴的：没有标注引用出处的代码复制会被看成抄袭行为， 这在商业软件开发中是很严重的。这点尤其需要引起重视。
一般性的原则是，如果引用了他人的代码，首先需要检查是否LICENSE是跟你正在做的项目的LICENSE是相容的。
如果相容，那么引用的时候，需要注意保留作者的CREDITS。也就是说，如果是文件使用，本身有文件头声明， 那么要保留；如果是引用很少的片段，那么在注视中指出URL。如果是软件包使用，需要在CREDITS中进行致谢。
一般而言，一般是模块级别的使用，放在 third_party 目录下，同时在CREDITS中致谢。而小的代码改动，则一般是自己理解了之后重写。
对于不修改只是用的软件，使用脚本自动下载和解压缩而不是放在 git repo.
例如交叉编译，要使用到 arm-linux-gcc-8 的某一版本的编译器。只是使用，不进行修改。这种情形是跟代码LICENSE没关系的，最好是按照脚本下载压缩文件，然后解压缩的形式。
这样【仓库中只有你写的下载-解压缩脚本，是没有这个编译器tar包的】。
if 本地没有tar名字
从URL下载
# 保证有了
if 有目标目录了
删除这个目录
tar tar文件 to 目标目录一个有用的链接： https://tinylab.org/prebuilt-cross-toolchains/
（FIXME：原则07的交叉编译器的内容或许可以放在tips）
模糊指代也是歧义指代，是指说的代词可以指向一个客体集合而不是唯一的客体对象。
一个检测方法是将提到了指代的话单独拎出来读一遍，看看是否可以脱离聊天上下文成立。
提到软件，最好有具体的版本号，或者tag，或者 commit id；
提到任务，最好有 issue number 或者 T id；
讨论问题，先在GitHub或y站进行记录，然后贴url，再开口讨论。
不管是中文语言还是英语还是日语，直接使用「你/you/あなた」都是带有隐含的对抗性质的。同时，「你」也会导致文字内容复制转发的时候会需要重新编辑。 改写的方式有很多种，要看具体的上下文。一般是有意识的规避几次就好了。一个通用做法是直接写名字，「我（名字）这边」怎么怎么样，「X这边负责」怎么怎么样，类似。