方案被驳回,很多时候不是方案本身有问题,而是听的人在前十分钟没能建立起"这件事大概是什么、要花多少、风险在哪"的框架,后面的细节就全部悬空了。汇报是一种有结构的工程产物,可以拆开练。 结论先行:前三句话要装什么 技术人习惯按推导顺序讲:背景→调…
程序人生
没有归入具体专题的技术笔记、踩坑记录与工程随想。
远程协作失败通常不是因为工具不够,而是因为把办公室里的同步习惯原样搬到了线上:有事就问、开会讨论、口头确认。这些做法在隔了几层工位时是可行的,隔了时区之后成本会急剧上升。 同步沟通的真实成本 一次"顺口问一句"的代价不只是对方回答的那两分钟: …
"应该做专家还是做通才"这个问题之所以难答,是因为它被问成了一个身份选择。实际它是个资源配置问题:在给定阶段,把有限的学习时间投到竖(某一领域的纵深)还是横(跨领域的连接)。答案随阶段变化,也随市场供需变化。 竖从哪里来 深度不是靠"用了五年某…
去年我利用晚上和周末的时间,做了一个给开发者用的小工具,从有想法到真正有人稳定使用,前后折腾了几个月。中间走的弯路比顺路多,但整个过程对"一个东西怎样才算做完了"的理解,比之前几年上班攒的经验都深。这篇按时间线复盘,写法上偏个人经验,不指向…
代码评审(Code Review)是团队里少数几个"高杠杆"环节:花二十分钟看别人的改动,可能拦下一个线上故障,也可能让一个人少走半年弯路。但同样是评审,有的团队越评越顺,代码质量和信任度一起涨;有的团队越评越僵,作者拆小 PR 只为少挨骂,评审人敷衍点赞…
桌面是电脑里最诚实的地方。工作一忙,截图、安装包、临时导出的表格、"先放这儿待会儿处理"的文件就会一层层堆上去,直到壁纸彻底看不见。等到想找某个东西,只能靠图标的位置和颜色去回忆,检索基本靠运气。 整理桌面这件事,难点从来不是"把文件挪走",而…
每隔一段时间,技术圈就会冒出一轮新的热点词汇,伴随着"不会 XX 就要被淘汰"的焦虑。这种焦虑驱动下,有人一年换三四个技术栈追新,简历越来越花,遇到具体问题时却仍然说不清"这个改动会不会把系统弄挂"。问题出在对"什么在贬值、什么在升值"的判断上:具…
这两年我把一批常用工具从在线版换成了本地版:文件处理、格式转换、压缩解压、批处理脚本能用本地的就不用网页的。原因不是情怀,是几次具体的事情之后算的账。这篇文章把我算的这笔账摊开,讲讲哪些场景在线更好、哪些场景本地是正解。 一、在线工具的三笔…
学新技术最常见的两种走法都容易半途而废:一种是从第一章开始逐页读,读到第三章还没写过一行代码;另一种是直接上手抄 demo,跑通了就以为会了,等真要用时发现处处是洞。 差别在于有没有一个可验收的产出节奏。下面这套路径按 30 天设计,每周一个能拿出…
技术方案文档写得不好,代价不是"文档难看",而是评审会上二十分钟的沉默、会后零散的意见轰炸、以及两周后开工时大家对"当时到底定了什么"的记忆分歧。方案文档的真正作用是让一群忙碌的人在有限时间里做出一致决策,它更接近决策材料,而不是技术散文。 一…
几乎每个程序员的收藏夹里都躺着几百个链接:一篇讲 HTTP 缓存的文章、一份正则速查表、某个 Stack Overflow 回答、某个框架的官方文档章节。收藏的那一刻有种踏实感,好像知识已经归自己了。过三个月再看,链接失效了一半,剩下的那些"眼熟但想不起内容"。…
选型讨论里最常见的一种失效模式是:候选列了四五个,会议开了两小时,最后拍板的人说一句"我觉得 B 好一些"。这个结论本身不一定错,但它不可复用、不可追溯。半年后新人问"为什么是 B",没人答得上来。 差别不在于选出哪个,而在于能不能把判断过程外化成…
系统设计面试考察的不是"你知道多少个组件",而是你在信息不完全时如何推进:先确定边界,再给一个能跑的东西,然后逐步加压、逐步加固,并且全程能让别人跟上你的思路。 下文以一个具体题目贯穿:设计一个短链接服务。 前五分钟:把需求问清楚 拿到题目立刻…
技术方案被否掉的那一刻,第一反应往往是"对方不懂"。多数情况下对方不是不懂,而是没拿到做判断需要的信息——他知道你的结论,不知道你面临的约束;你知道约束,不知道他那边的时间窗口。两边各拿着一半信息做出判断,结论不一致才是正常的。 冲突的根源通常…
同一篇文档,读者会有三种不同的期待:看懂这件事是什么、照着做一遍能成功、以及知道什么时候不该这么做。这三种期待对应三个层次,缺任何一层,文档都会在某个时刻失效——通常是读者最需要它的时候。 第一层:能看懂 看懂的最低门槛是:读者不需要另外开一…
软件开发的产出不随投入时间线性增长,多数人有体感,但很少被当成工程管理问题。高强度本身不是问题,无法恢复的高强度才是。下面把"节奏"当成可设计的对象,而不是靠意志力硬扛。 上下文切换的真实成本 一次切换的代价不等于被打断的时长。中断后要重建的…