前段时间在亚马逊上买了一个中国品牌的Phylian H8型电动牙刷，约25加币，用了2个月后，马达故障，停止工作。向厂家保修后，厂家寄回一套全新的，于是我闲着无聊，拆解了一下。

先说结论：这玩意的物料价格低到离谱，20元人民币都富余。

首先是外观。一个白色的刷头插座，下面是黑色主机，有一个大按钮，和几个LED指示灯。和博朗等品牌的金属震动插座不同，Phylian是塑料的，而且很粗，我之前不明白为什么这么设计，但下面会解释。

拆解思路很简单，把牙刷底部封口四周用工具刀划一遍、破坏掉防水胶，然后取下封口。

此时用改锥稍微一撬，就能拔出这个塑料封口。

封口下面有两根电线连着内部电路，因为两边有两个塑料卡扣，必须进行破坏性拆除，否则无法取出。

将尖嘴钳将卡扣掰弯，见上图红圈处，即可顺利取出内部组件。

取出后，可见到牙刷主要分为三个部分，上部的白色刷头插座，中部的牙刷主板、电池，下部的充电电路（也就是刚才拆了半天的塑料底座）。

电路部分很有趣，直接就是个14500电池，500mAh，这块电池应该是低端电动牙刷的标配了吧？取下来也很容易，和5号电池差不多大，用手一扣就下来。

拆掉14500电池以后，我想起来自己还曾把旧牙刷快递给第三方维修，花费上百元人民币只为了换个电池，突然感到损失一个亿。

接下来是牙刷主板部分。

从上到下，分别是开关按钮，5个模式切换LED，以及一个充电指示灯。模式切换LED附近，覆盖了一层黑色海绵，如下图。

这层海绵的作用，就是为了防止LED之间「串色」，例如第一个LED亮起时产生的光晕，让第二个灯看起来也亮了。粗糙的产品一般不加这玩意，对产品核心功能没有任何影响，但如果对用户体验有点追求，还是会对这种隐形Bug做一些防护。此处应该给好评。

我的牙刷故障原因大概率是马达出了问题，但我拆了半天，并未找到马达在哪，所以继续拆解上面的白色刷头插座。

用胶封住了！显然里面藏着什么电子原件，那肯定要破拆！

终于在这里发现了震动马达！原来把刷头插座做这么大，是为了直接把马达塞进去。而博朗、飞利浦等，则统一将马达放在主机里，看来这是两种基于不同成本的差异很大的设计。

零售价人民币1.8元。难怪这么容易坏，草。

最后来个全家福。充电电路实在懒得拆了，也没什么新鲜的，就到这里了。

估算一下这个零售价25加币、约合人民币130元的电动牙刷的物料成本：电池6元，马达1.8元，估计整个电路板不会超过5元，外壳10元。不包含研发、开模、营销、运营等费用，单纯物料（按零售价计算）只有不到20元人民币。以后兄弟们如果电动牙刷不好使了，直接拆开底部、掏出来换个电池就行了，耗时10分钟。

Tagged : 技术 / 电动牙刷

普通人往往高估「确定性」的收益、又低估「确定性」带来的风险。

例如考公的人看到了后面三十年连续不断的几千元/月工资外加各项福利的稳定性，却忽视了自己的真实需求和沉没成本。考公的显著沉没成本之一，就是牺牲了自己未来所有可能性和应对风险的抵抗力。当风险来袭，你将没有任何应对能力。从去年开始的大范围、高强度的公务员降薪，已经实在的影响全国上千万体制内选手；而 90 年代的「国企工人下岗潮」带来的无数人间悲剧，就是「确定性」危害的一次大规模显现。

除了考公大军以外，因就业困难而去考研的兄弟姐妹们，更只是延后了处理风险的时间，不仅没有消弭风险，反而给自己注射了麻醉剂，使得下次面对风险更加弱势（年龄增长、对市场的敏锐度下降、学历成本带来的经济压力等）。一言以蔽之，还不如考公。

除了考公考研等传统项目，当代市场化职业中，“转码”也是一种“赛博考公”。你做了500道 Leetcode 算法题，便可以中人之姿跻身Google/Microsoft等一流大厂，获得稳定的高薪和社会地位，哪怕这几百道题对真实工作而言毫无意义，亦算是你进入大厂的「投名状」。其付出的时间、精力、沉没成本，虽足以让你获取更有价值、历久弥新的知识，却并无即刻的、现金化的收益。

更何况，在人工智能等技术的加持之下，传统工程师的职业寿命到底能否继续维持下去，这是一个尚无答案的问题。但是，此类职业风险的出现，意味着「大厂工程师」的收益期望被降低了。而这，仅仅是一个开始。

上述「确定性」的存在，为很多人提供了舒适的生活，但，是时候抛弃这些「确定性」了。

我的老读者都知道，我是一直是「不确定性」的拥趸。2015年以政治学本科+互联网运营总监背景裸辞自学编程，在2016年顺利成为初级后端开发工程师，这在当时是一种巨大的不确定性，后来却为我带来了巨大的好处：掌握了工程技能，深入理解计算机系统，也为多年后「润加」做了铺垫。

2019离职，此后两年间家里蹲写公众号。这可能是我风险最高的一段职业经历，因言获罪，得到了警察的「登门认证」，以及百度的「诉讼认证」。同时，我也习得了普通人终生难以获得的技能：大量的法律实践。在与百度长达半年的缠斗中，我学到了很多法律知识以及法律实践（在中国的司法体系中，对法条的理解和对司法的实践，几乎是各占50%的独立知识），也获得了「打官司」这个业余爱好。

2022年再次转职，回归职场，成为字节跳动高级工程师，很快与字节撕逼，凭借过去的自媒体经历和对法律的熟稔，全身而退，开开心心拿钱走人。至此，我清楚自己可能与国内任何一家大厂都水火不容，未来不会再为 BAT 之流贡献任何一行代码、任何一次管理实践。

去年以旅行签入境加拿大，一个月后莫名决定留下，接着在加拿大境内考雅思、申学校、申学签，从毫无准备到尘埃落定，每一步都充满风险，但每一步都带给我巨大的收益。

可以说，我生命中最宝贵的这些经验和收益，全部来自于「风险」。一来，我本人对于「确定性」的实际收益一直报以怀疑态度，二来作为一个风险偏好的个体，我对于「确定性」有一种来自 DNA 的排斥。

在「系统性风险」越来越鲜明的今天，不确定性，实际上是这个世界的主流；确定性，才是一种「例外」。我不觉得对于「确定性」的追求有什么道德劣势，但「追求确定性」这个行为本身最严重的问题，是其存在着手段与目的的二律背反：将身家性命寄托于「确定性」，这本身就是一种高风险行为，而这种会导致高风险的手段，恰恰与「追求确定性和安全性」的目标背道而驰。换言之，你明明想寻求安全，最终却将导向危险。这就是「确定性」最大的逻辑悖论。

既然如此，是时候抛弃「确定性」和「安全」，拥抱「不确定性」和「风险」，拥抱自己的本性。这样，每天都会收获意料之外的命运馈赠。剩下的，交给时间即可。

最近小虎7个多月大，学会了扶站，早于平均速度约2.5个月。我很好奇，为什么他学习的这么快？经过观察，一方面是因为他天生强壮，另一方面，就是他胆子大、敢冒险、不怕磕碰、屡败屡战。简单说，就是他对于“风险”有较高的偏好，对于安安稳稳的“确定性”（例如用躺、坐等安全姿势玩耍）则较为厌恶。反反复复的冒险，让他快速习得了很多实用技能，又进一步加速了学习速度、不断的自我强化。这是小虎示范给我的「不确定性」的优点，看来他未来恐怕也是一个风险偏好者。

Tagged : 代码 / 技术 / 法律 / 确定性 / 程序员 / 编程 / 自媒体

我时不时会收到一些小朋友们的私信，问是否招实习生或者「程序员学徒」的，可以不要薪水。我一般回复「没有」，就不再多说什么了。并不是我高冷，而是觉得这样的小朋友恐怕并没有什么潜力值得去挖掘。
这么冷酷的结论，并不是拍脑门想出来的。经历了多次打脸，我最终明白一个道理——如果一个人把「廉价」甚至「不要工资」作为核心竞争力，那么他不仅对自己没有信心，其实也不会有任何主动性去发展自身。他们只期待一个武林高手从一招一式开始教起，像妈妈带娃一样照顾始终，而自己只需负责饭来张口即可，希望在人畜无害的气氛中，无能的成长起来。
显然这是做梦。即便这样一位「程序员学徒」不要工资，其他人为了培养他而投入的巨大精力和时间难道不值钱？武林高手有这个时间干点什么不好，不能去争一争武林至尊吗？为什么要把时间浪费在一个连学习知识技能都需要他人喂食的巨婴身上呢？这些幻想成为「程序员学徒」的小朋友明显算错了数，他们以为「不要工资」是自己的巨大优势，实际上这样的人带来的往往是负价值，对团队和项目都有巨大损害。
举一个我自己的例子。我曾经在一个水平相当低的工程师身上耗费了近半年时间，从 Google 搜索引擎和 stackoverflow 的用法，到代码规范，到 Python 各个标准库的用法，再到各类 Pythonic 代码的写法。之所以耗费这么大精力，是因为我是一个不错的老师，能把很多道理讲的深入浅出（例如我可以在 1 分钟时间里让任意一个无技术背景的人理解金融量化交易引擎的技术原理），经过我的细致培训，他一定有机会成为一个代码细腻而简洁的工程师。
直到被我劝退前，他都一直在用百度搜中文关键词并跳转到 CSDN 上看技术文。
这是什么概念呢？就是一个数学老师教了你半年的二项式展开，最终面对最简单的二项式题，你依然在掰手指数数。
这样的程序员带给同事的往往是噩梦。在他离职之后，我们依然时不时的从他代码中发现骇人的 bug，然而数据已经被污染，重新修正几乎不可能。由他引入的问题，很有可能直到公司破产都不会有人愿意去解决。这样巨大的负担，当年的我如果更成熟一点，是万万不会惹祸上身的。所以现在收到各类的「不要工资」的申请，心里都会默默的想，「你当我是傻子么」。
每个人都渴望成长，但成长不是商品，不是你用「不要工资」就能够换回来的。成长源于你一步一个脚印的学习，在学习过程中，你又创造出了价值。本质上，只有当你持续创造价值的时候，你才会成长；而不是反过来。
如果你技术不好、没公司要你，能否在力所能及的范围内，对开源社区做一点贡献？
如果你技术不好，能否仔细研究业务代码，试着花一个月甚至两个月的时间写一个简单但核心的模块？
如果你技术不好、又想找个老师，能否先帮这个老师做一点事情、哪怕只是帮他写单元测试？
……
可做的事情太多了，简直数都数不过来，而它们的共同点就是——持续创造价值，而不是持续索取关照。
所以，当我们对一件事情有了强烈的渴求时，最好先问问自己，能不能用已有的技能先创造一些价值出来。如果不能，说明你其实并没有那么渴求。那么，请不要再去骚扰那些工作量已经很饱和的工程师了，码农滞销，可怜可怜老乡们吧。

Tagged : 代码 / 成长 / 技术 / 程序员

工作近5周，共完成了2个项目（第二个项目已经基本完成测试，准备收尾中）。第一个项目，是用爬虫抓取数据，然后做好 API 供用户使用。第二个项目，是扫描僵尸用户，发邮件唤醒，如未唤醒则关停僵尸用户的进程。
做这两个项目的过程中各有各的体会。
首先，是关于解决问题的方式。做第一个项目时，刚刚进入公司，很难适应工程师文化，加上和同事不熟悉，脸皮薄，不愿意问问题，甚至没有仔细确认需求和工程方式就动手开搞，最终耽误了不少时间。在工程上，沟通极为重要，工程师不是低着头闭门造车的，恰恰相反，工程师们是用集体合作的方式共同搭建一个或繁或简的系统，最终完成个体无法完成的大规模工程。这应该是工程师们在一起工作的最重要意义之一吧。
工程被分割成一张张工单，并不意味着其整体被切割成无关联的个体。在完成工作的时候需要尽可能多的理解工程的有机性。例如我将爬下来的时间序列存入数据库时，每条数据的时间都被我存成了str，于是在后期制作 API 的时候就遇到了一些问题，最后需要通过将其转成datetime来解决。类似的问题说明我在完成某件工作时，并不知道这件工作在工程中的位置与意义，这就需要多问和多做了，在对整体熟悉了以后，自然会逐渐清晰。
其次，是关于单元测试的重要性。其实『单元测试』这四个字，有弱化其意义的副作用。我在做第二个项目的时候，由于内部处理数据的逻辑比较复杂，导致大大小小的 Bug 一大堆，每次提交都认为自己已经做得差不多了，但还是在 code review 时被打脸，来来回回提交了若干次，花费大量时间，甚至同事成了我的人肉 Debug 处理器。最后同事说，你还是写一些测试用例吧，覆盖的情况越多越好。
果然，写了一百多行的测试用例后，将单元测试完成，自然发现了一些之前很难发现的 Bug，无论对我还是其他工程师来说，都节省了大量调试改错的时间，多灾多难的第二个任务也随之迎刃而解。经此一役，我对单元测试的意义恍然大悟，其实单元测试并不仅仅是『测试』这么简单。在『测试』的背后，其实是将代码化整为零、各个击破的写作过程，因此单元测试的写作时间，应当与程序本体同步，也即『写一个函数，就写一个测试』，二者几乎是同步完成的。这样看上去花了很多时间在设计测试用例上，其实是规范了自己的思路和代码，同时大大提高了后期的可维护性。
在明白了第二点（也就是单元测试的真正意义后），觉得自己仿佛突破了一个模糊边界——一个软件工程师和业余代码爱好者的界限。虽然现在代码依然很烂，但是本着对代码负责的态度和对自己职业的尊重，我会把以后写下来的所有代码都同步加上单元测试，配得上一个专业人士应有的严谨。
以上就是我在完成了两个项目后的些微体会。工程师的快乐，是由一个个微小的痛苦组成的。此生竟有幸成为工程师，真是一件幸福的事情。

Tagged : 单元测试 / 技术 / 编程

在过去的一年中，我带领一个运营团队在外贸软件行业整整工作一年，总结下团队的成果：
1. 创造了阿里巴巴国际站内效率最高的消息群发设备组，群发量全国第一。
2. 从创建一个5人QQ群开始，将之运维到10000人的用户QQ群组。我们这行业太小，所以应该是妥妥的国内第一了。
3. 是我知道的唯一一家让阿里外贸圈论坛全站置顶红色警告的软件企业，利用了阿里的一些小bug且推广量大到惹毛官方，『捣蛋分子』成就达成！
4. 整个推广团队加上我只有3个全职，用竞品10%的资源达成竞品60%的真实注册用户量，人均效率完爆同行。
运营人员有时被公司同事理解为『文员』、因而感到沮丧和困惑。这不是事实。运营绝非『文员』，并且恰恰相反，运营是科技企业里除了一线工程师以外，最需要技术的岗位。
运营意味着为一线工程师的产出赋值，将流水线产品变成更富个性的『手工艺品』。在这个意义上，一行行代码远非产品的最终形态，那只是包裹产品的外壳，而产品的实质则产生于内容运营、用户运营、社区运营等等环节之中。如MIUI的诞生固然给当时的Android固件领域带来一阵新风，但产品本身却并不能产生滚雪球的效应，卓越的社区运营才是为小米公司获得最初市场基础的核心（而市场营销，则是在那之后的事情了）。
运营需要哪些技术？
先声明，我所说的技术，不局限于写代码，还包含自由的想象力、以及将想象力变成现实的任何实践能力。因为这些大多需要以计算机技术作为工具，因此就笼统称为『技术』了。
第一，要有一定的代码能力、或阅读代码能力。能够通过代码完成一些简单的功能，如批量操作、运算等。这里除了常见的各类编程语言，Excel等表格处理软件事实上也包含在内，能够通过Excel等工具处理复杂数据，和编程是一样的。另外，能够主动运用技术手段提高运营效率，也是一条必备能力。运营中往往涉及大量重复性工作，需要运营人员寻找合理的技术方案来解决，在寻找方案的过程中不断降低成本、提高效率。
其次，理解工程师的行为逻辑。对于产品，有自己的理解。以我部门为例，运营部与产品部毫无关联，但是产品的任何改动，无疑都会在第一时间作用在运营数据上。因此一个好的技术型运营必须对于产品有整体性的理解，即：产品为什么这样调整？用户行为和数据反映了产品设计的哪个特性？运营应该怎样承接产品的迭代方向？做运营的都听过一句话，产品是一坨屎也跟你没关系，运营得好才是真牛逼——说这种话的人显然缺乏足够的行业经验，一个老资格运营必定对产品有深刻的理解，否则无法出色完成运营工作；甚至老资格运营也应该对产品充分表达自己的意见，而作为最接近用户的运营人员，往往是最懂用户痛点的，当一位资深运营看到堪比『一坨屎』的产品时，他最应该做的就是马上扭头走人，不要在这坨屎上浪费时间。
再次，能够主动认识到自己在技术上的缺陷，寻找有兴趣加入运营团队的技术人员。运营人员再懂技术，往往也并非职业工程师，在技术上的差距很难通过业余时间的学习进行弥补。因此不断的寻找技术人员加入自己的团队，也可看做是一个技术性运营的『天生嗅觉』。换一个角度，判断一家公司的运营团队是否强健，也可以『是否有工程师全职参与运营』为一个标准，能达到这个标准的企业，其运营一般都是较出色的。
以上三点，可以看做是技术型运营人员的几个特征。再次强调，所谓『技术型运营』，并非指运营人员撸起袖子写代码，而是『运营工程师』始终处于一种『寻觅更好的运营技术』的状态中，不断提高自己对『技术』的理解与品位，致力于将团队打造成自动化的『机动部队』。有这种状态的运营人员往往可遇而不可求，一旦发现，应该尽快吸纳入团队，并赋予充分的活动空间。
这是我对『技术型运营』的理解，和对『运营工程师』的画像。粗浅理解一定错漏百出，希望与各位讨论，不吝赐教。

Tagged : 技术 / 运营