Jaising666
不能躺平，不愿秃顶的程序猿
获得徽章 16
- Spotify CEO Tobi Lutke 的 All in AI 备忘录：
1、使用 AI 不是建议而是基本要求，全员使用 AI
2、申请资源或者招聘员工，需要证明为什么 AI 做不到
3、AI 带来的一定是生产效率的提升，如果员工效率超不过企业增长率就很危险展开评论点赞 - 如何衡量一个软件工程师是否靠谱？
ThoughtWorks 给出了一个很好的评判标准，评估（elimination）出的交付时间和实际偏差不大，并能基本达成目标。
当然，不同级别工程师给给出的评估结果可能有很大偏差，但是对于一个级别的工程师而言这是一个分析型思考（analytical thinking）胜任力考验。
评估一定是基于任务分解（tasking）展开的，这也是金字塔原理的核心。员工个体分解出有效任务，团队成员分解出正交任务，最后形成完整的项目计划，交付周期就是明确的了。
任务分解是困难的。需要经年累月的练习。
如果不理解需求，需要和 po 或者 ba 再次沟通；如果不具备需求实现能力，需要在 timebox 内做 spike，然后再回到任务分解上来；如果不能分析出本质复杂度，只在自己 clear 模式下分解任务，最后依然无法达成目标。
可想而知，凭空估算和不做任务分解走到哪算哪，都会给软件项目带来极大不确定性，工程师不靠谱的结果就是软件项目也不靠谱，要么交期延误，要么出现大量返工。
一个专业性体现是，在没完全理解任务时就不去工作，直到把所有任务分解完成。如果任务实现过程中发现有未识别的卡点很可能延误交付周期，就及时向团队寻求帮助。
能有效分解任务，甚至是细粒度（小时甚至分钟级）的，至少是一个高级工程师。
靠谱就是专业。展开赞过 11 - 亲历一些项目现场才意识到单元测试多重要。
私有云、专用网络这些环境里，开发与部署天然隔离，如果每次都是部署再验证不仅效率低反馈周期还长。叠加到团队后，就是隐性且巨大的开发成本。
另一方面，迫于领导压力现场开发，看似敏捷，实则堆叠人力。这样的事情，很多看似研发水平更先进的互联网公司也是如此。做项目也是为了做产品。
按照知识管理的角度，生产代码一定是 clear 模式的，技术本可以创造更多价值。展开评论点赞 - 以政企服务为主的公司里，在追逐项目收益最大化的当下，领导还能敢于拍板派同事出差去现场分析系统性能问题，解决性能瓶颈，对我个人而言，感觉技术价值得到了尊重。
正如耗子叔说的那样，技术是为了创造价值的。
学习技术是为了理解成本，如果系统性能出现瓶颈，严重干扰到了用户体验，损害了项目长期收益，那投入资源解决就是值得的。
而资源的稀缺程度决定了市场价值，找到那些需要的场景打磨手艺就可以获得超额回报，这也是工程师的成长之路。展开赞过 72 - 耗子叔离去一年了，在国内难得遇见如此执着于技术还接地气的人，怀念他最好的方式就是实践他的价值观，也是工程师的成长之路。赞过 11
- 抗压越来越成为许多企业要求的职业素养，这不仅仅是工作时长的压力，也是工作强度的压力，有来自于专业能力上的，也有来自沟通协作上的。
这要求，也包括工程师，有良好心理素质，沟通管理技巧，协作共赢认知，与工程能力是不同的能力要求。
比如遭遇了诽谤，能够条理清晰的分析出依据是否合理，识别出概念混淆、强加因果、模糊边界这些常用伎俩。明知来者不善，依然能够不疾不徐予以回应。同时注意加强内功修炼与汇报表达，好鞋子也怕小石子硌脚。
这前提是清楚自己或团队的价值定位，有迹可循的梳理业绩贡献，从产出与影响力驱动。如果说办公室政治在所难免，那么工程师可以做的就是彰显专业能力，不掉入预设的陷阱中。
当然了，如果工程师的时间用来解释价值而不是创造价值，那从公司这块业务来说就有点岌岌可危了。展开评论点赞 - 体力劳动到知识工作需要不同的认知与管理方法，软件工程师作为知识工作者是时代的机遇，也是自我价值的界定。评论点赞
