程序员工作轶事（不定更）

团队里不能没有妹子

自从招进了妹子，氛围没那么压抑了，日常干架减少了

---

有时候学姐也很主动帮助学妹

因为如果学姐不出手，学长们就要出手咯
（那为什么学姐不直接对学长出手？😓）

---

妹子长期享有的性别红利，她们却感知不到

妹子面试成功率远高于男生
妹子遇到问题时，通常会有很多男生主动手把手指导
妹子也经常加班，但通常没那么苦（男生加班通常是干体力活甚至苦力活）

男程序员们会争夺对（单身）女程序媛的指导权（帮助权）
虽然女程序员会受到很多男生的指导，但很容易会被带偏（除非带她的那个很厉害）

---

各个岗位的女生占比

占比语义	范围
高到很tm离谱	50~100%
极高	40~55%
高	30~45%
中	20~35%
低	10~25%
极低	0~15%

岗位	女生占比
运维工程师	极低
后端工程师	极低
大数据工程师	极低
数据工程师	低
算法工程师	中
数据分析师	高
前端工程师	高
测试工程师	极高
产品经理	极高
运营	高到很tm离谱
设计师	高到很tm离谱

---

到点下班了，大家都没走

导致我也不好意思立马走（开始时害羞，后来不会了）

---

登录过期

中午睡个觉，登录就过期了，重新登录要输入三次账号和密码！

---

某人开发了一个没有告诉别人的功能

然后导致对别人的功能产生轻微影响

---

为了学习某个新技术，而选择用那个技术

有时候遇到新项目，在时间充裕的情况下，会选择使用一些新奇技术去实现；
技术选择的出发点，不是为了快准狠地解决问题；等同于拿【项目or下属】做白老鼠

---

有时要背负职责之外的锅

有些事不是自己的工作内容，
不管的话要背锅，管的话又没权，
提建议也常被否决甚至忽视。

对于此类问题，有2个方案：
1、提供完备解决方案+说服方案；缺点是要消耗自身大量时间，且仍有可能失败
2、使用中间人（通常是妹子）来作为消息传达；缺点是招多一个人，以及中介传达率不是100%

很多公司采用方法2，招聘（漂亮的）妹子来缓解冲突；
很多甲方指定妹子作为对接人；
很多乙方也使用妹子作为对接人。

---

领导的技术栈决定了下属的技术栈

领导是个Java，那招的下属写算法要求用Java，而不是Python

---

产品设计考虑过于长远

产品功能过于复杂，体量设计过于庞大，导致前期进行不下去。
（好比一个后期英雄没熬过前期就gg了）

---

跨部门沟通

有个问题a，需要找A解决
A解不解决，不影响A的业绩
所以A完全可以不鸟我

---

用人经历

招了两个大数据岗的下属，开的薪资差不多

对比	下属A	下属B
工龄	1~2年	1~2年
学历	三本	一本
是否科班	是	否
（面试时）技术	会很多	会很少
数据开发逻辑错误	多	少
离职 or 加薪	中概率	高概率

• 功能有bug的话，通常会挂掉，很容易测试出来。
  但对于SQL跑出来的结果，无论正确与否，程序都没挂，因此 没那么容易测出来了！
• 建议：
  对于测试成本较高（如：AB测试）的岗位（如：SQL岗、数据分析岗、算法岗），应优先聘用数学好的和学历的高

---

年龄大的同事，有更大概率给你挖坑

年龄大、长得丑、学历低的同事，有更大概率挖坑让你踩

---

讨论大声的人通常比较老道

平常讨论大声的人，不一定技术流弊，但通常老道

---

有些“大佬”一天到晚在“指点江山”，却从来不干实事

其实罪魁祸首并不是这个“业务大佬”，而是把这个“业务大佬”招进来的老板。
进一步反思：为什么我会与这种猪队友共事？为什么我的老板不够强？因为我还不够强！

---

SQL没有注释

• 不要跟我说SQL注释不好写！嵌了十几层的子查询 一句中文都没有？
• 建议：
  子查询使用WITH AS，一个子查询至少一句注释

WITH
-- 注释1
t1 AS ( SELECT a FROM t0 ),
-- 注释2
t2 AS ( SELECT a FROM t1 ),
-- 注释3
t3 AS ( SELECT a FROM t2 )
-- 计算最终指标
SELECT a FROM t3;

---

SQL使用CURRENT_DATE

导致
10月不能跑9月的数据
或
10号不能跑8号的数据

---