• 设计一个该死的解决方案实际上是软件开发过程中最困难的部分。低代码工具通过暗示编写代码是最难的部分来欺骗客户。 任何低代码工具都不能使你免于花时间正确设计你的定制软件,也不能使你免于在围绕半成品设计建立解决方案时所经历的后果。
  • 虽然我在 Spotify 工作了大约 8 年,但我并不熟悉每个领域的运作方式,而且我有自己的偏见、偏好等。而且 icon
  • 敏捷方法现在可能很普遍,并且有了它,增量方法的概念应该被开发社区所了解和利用。尽管如此,在与开发人员交谈时,我仍然发现它的理论与它在日常开发实践中的应用之间存在脱节。 我认为这种脱节部分是由于我们分层构建解决方案的方式,以及我们在创建用户故事和最终 icon
  • 敏捷会帮助你高效地建造东西,但你最终可能会在建造错误的东西时非常高效。 产品迭代的短反馈循环是敏捷如何比瀑布格式更不可能构建错误的关键所在,反馈是敏捷的燃料。 与您的客户、用户和/或利益相关者交谈。 icon
  • 在计算机科学的许多领域(密码学,NP复杂性),验证解决方案比生成解决方案容易得多。这篇博客文章发现大语言模型LLM(主要是GPT-4)可能能够自我验证其解决方案。 与概率推理和最优控制中的大多数算法思想一样,让代理者自己批评其决策以使其变得更好是一 icon
  • 领导力是最大的推动力,但也可能是最大的障碍。要使变革取得成功,我们需要最大限度地激励员工,最大限度地减少对员工的威胁。 乔纳森·斯马特(Jonathan Smart)和西蒙·罗勒(Simon Rohrer)是《Sooner Safer Ha icon
  • 讲故事使人类能够将知识传给下一代,并依赖于我们存储记忆的方式。我们可以通过举例说明,一个系统从开始到结束应该做什么,在时间轴上,而且没有分支。要做到这一点,我们需要用特定的时间线画一条线,代表状态在不同时间的不同变化。为什么是时间?时间是系统的一个重要方面,因为每个应用程序都是一个场景中的分 icon
  • 无论是从头开始建立一个新的项目,实现一个大的功能,还是开始一个大的重构,要保持动力和完成大型技术项目都是很困难的。对我来说,一个非常有效的方法是不断看到真实的结果,并以此为基础来安排我的工作。 当我把大型任务分解成几块,从而看到切实的进展时,我往往 icon
  • 创新本质上是一种失败又失败的努力吗?如果您了解客户做出他们所做选择的原因,则不会。 从我们有记忆以来,创新一直是领导者的首要任务,也是他们的首要挫折。在最近的一次麦肯锡民意调查中,84%的全球高管报告说,创新对他们的增长战略极为重要,但令人吃惊的是 icon
  • 衡量开发人员工作效率的最大好处是,你可以很快找出那些糟糕的程序员。我想给大家讲讲我认识的最差的程序员,以及我为什么要把他留在团队里。 几年前,我在 Twitter/X 上写过一篇关于我认识的最好的程序员的文章,我应该把它写成一篇博文。现在,我也应该 icon
  • 敏捷和设计思维已经针对同一个问题提出了两种不同的解决方案。 设计思维首先寻求学习。 另一方面,敏捷寻求先构建。 敏捷团队成员将设计思维视为 BUFD(Big-Up-Front-Design)。他们提倡先构建,再发 icon
  • 构建真正为客户带来改变的产品所带来的满足感,比追赶最新技术潮流所带来的短暂兴奋更有价值。 依靠稳定且易于理解的技术来优先考虑交付价值。有选择地、有意识地进行创新。 这种创新属于 icon
  • 如果您发现自己在担任产品负责人时难以做出有效的决策,或者您在想出一个有凝聚力的产品策略时遇到困难,那么您并不孤单。也许您的直接下属不断向您寻求指导和方向,但不确定该走哪条路。 听起来有点熟?如果是这样,您可能会受益于更多地了解由Martin Eri icon
  • 本文试图以一种简单的方式写下敏捷方法之间的区别:把它写成两个朋友之间使用送餐应用为案例的对话。 拉克什Rakesh,一个聪明的、精通技术的开发者,和他的朋友汤姆Tom,一个没有技术背景的人,正在进行一场轻松的谈话。 icon
  • 什么是系统思维以及为什么它在软件开发中至关重要? 什么是系统思维?系统思维是一个广泛的知识领域,通过理解所有部分如何相互联系和影响来解决问题。这个理论并不新鲜,不同行业已经应用了数十年。一个很好的例 icon