试错

部署运行你感兴趣的模型镜像

前几天看公司离职同事反馈的各种意见建议还有抱怨,很有价值。但是反馈中有一点,我是无法赞同的,那就是对待「试错」的态度。有两位同事抱怨说,为什么要不断「试错」? 这样多折腾? 搞得开发人员多累。客户为什么要不停的要我们修改设计稿? 多烦。

首先要说的是,我在工作中看到不少人混淆了「试错」和「错误」这两个事情。有些试错根本就是纠正错误,既然事情无法一次作对就别找别的客观理由了,一个功能,每改动一次,都会出现新的问题,这样产品人员肯定要你不停的去修正,几次三番,作为开发人员自己没意识到自己的责任,反而会把问题怪罪在产品人员头上。但实际上,这样的情况应该先看看自己做的事情是否不够严谨,自己考虑得是否不够周全。

绝大多数人都不喜欢频繁的被动的改动自己的已经「完成」的工作,文案不喜欢改来改去的,设计稿也不喜欢改来改去的,做完的功能不喜欢改来改去的,总而言之,你别来折腾我,别来烦老子,别来惹老娘…有点情绪可以理解,但我们应该认识到的事情是,如果你要把东西做的更好,就是要不停的改动,不停的改进。没有人能一次弄出来一个完美的东西,除非你是神。对了,乔布斯不是神,因为 iPhone 第一代产品现在看起来根本就是个半成品。「改动」和「改进」的差别在什么地方呢? 差别就在于改进是要使产品、项目乃至工作变得更好,能进步。

一看到「进步」两个字,很多人说,我喜欢进步,更想得到成长,但是我讨厌别人来折腾我。听起来你没错,只是因为「反馈」的信息不在你这里,而是被别人掌握,可你又从没想着去了解这些反馈。举个简单的例子,程序员和产品经理搭配工作,产品经理要程序员改动某个功能,程序员觉得你很脑残啊,要改动你怎么不早说,之前你干啥去了? 答案是之前他犯错了 – 因为经验或是能力的问题或是因为概率问题,然后他试图纠正或是校正这个问题。这是他的工作性质决定的。他不可能一次把所有的东西都做对,除非你做一个根本不会有人用的东西,没人反馈问题,因而也就看起来没问题。

不对劲儿,你说的好像哪里有点问题: 产品人员能否提前去做好调研,做好分析,做好各种准备工作,做好决策,然后让工程师一次把东西弄出来不需要频繁改动呢? 当然能啦,在过去的软件开发工作中差不多就是这样的。好吧,跟我们的环境有点远。还有一种呢,是离岸外包,需求分析说明什么的文档写出来一大堆,然后开发人员直接实现就行了,你可以想见,这样的环境下每个人都不过是螺丝钉,然后你一定又会觉得,哎呀,接触的东西太窄了,这样长此以往人都废掉了怎么办啊? 去「试错」。

还有一种不需要试错,其做法就是跟着别人的产品去复制,别人有的东西你也要有,别去问为什么,只是因为「竞争对手做了,我们也要做」。这样的做事思路下,的确不需要试错的,因为这个时候对错已经不重要了。

绝大多数中小公司做事情,就是要不停的试错,创业团队尤其是要如此,这并不丢人,也不是为无能找借口。因为真实世界真实商业环境真实的用户需求就是远比我们认为的还要复杂,只有不断尝试才可能找到可行的解决办法。柳井正写书剖析优衣库的成功之道,「一胜九败」,如果我们「一败」都没有过,就想有「胜」,未免也太自大了一点。如果你只想按部就班的做事情,我建议你还是早点想办法进入大公司进入大的机构去。

如果你没做成什么事情,那是因为你犯过的错误不够多,你试错的次数太少,或是你根本不愿意试错。

试错是正确之母。

Updated: 要知道,试错是有很高的成本的,这个成本,基本上是由公司在承担,公司心在流血啊…当然,个人也会浪费时间。如果能不用试错当然是最好的。问题是,谁能呢? 如果你知道,请一定要告诉我,我请你喝一杯咖啡。

Google+

您可能感兴趣的与本文相关的镜像

Kotaemon

Kotaemon

AI应用

Kotaemon 是由Cinnamon 开发的开源项目,是一个RAG UI页面,主要面向DocQA的终端用户和构建自己RAG pipeline

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
【直流微电网】径向直流微电网的状态空间建模与线性化:一种耦合DC-DC变换器状态空间平均模型的方法 (Matlab代码实现)内容概要:本文介绍了径向直流微电网的状态空间建模与线性化方法,重点提出了一种基于耦合DC-DC变换器的状态空间平均模型的建模策略。该方法通过数学建模手段对直流微电网系统进行精确的状态空间描述,并对其进行线性化处理,以便于系统稳定性分析与控制器设计。文中结合Matlab代码实现,展示了建模与仿真过程,有助于研究人员理解和复现相关技术,推动直流微电网系统的动态性能研究与工程应用。; 适合人群:具备电力电子、电力系统或自动化等相关背景,熟悉Matlab/Simulink仿真工具,从事新能源、微电网或智能电网研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握直流微电网的动态建模方法;②学习DC-DC变换器在耦合条件下的状态空间平均建模技巧;③实现系统的线性化分析并支持后续控制器设计(如电压稳定控制、功率分配等);④为科研论文撰写、项目仿真验证提供技术支持与代码参考。; 阅读建议:建议读者结合Matlab代码逐步实践建模流程,重点关注状态变量选取、平均化处理和线性化推导过程,同时可扩展应用于更复杂的直流微电网拓扑结构中,提升系统分析与设计能力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值