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