Dojo
话题
新佳
订阅
极道
元认知
元逻辑
元设计
元编程
元语言
软件工程资料汇编
麦肯锡:程序员的生产力可以量化
长期以来,测量、跟踪和基准测试开发人员生产力一直被认为是黑匣子。事情并不一定是这样的。 现在,大多数公司(在某种程度上)正在成为软件公司,无论哪个行业,领导者都需要知道他们正在尽可能成功地部署最有价值的人才。
什么是盖尔定律?
适用于软件开发人员的盖尔定律(Gall's Law,也称为加尔定律) 盖尔定律是对复杂系统的性质和演变的观察。这一原则在软件开发和系统架构领域引起了深刻共鸣。约翰-盖尔(John Gall)在其著作《系统论》(Systemantics:系统如何真正工作以及
牛X软件工程师应该知道的概念
如果你知道以下概念的含义,你就是一个伟大的工程师,: #幂等 #幺半群 #解耦 #依赖注入 - 单元 #函数式编程 #异步编程 #并行编程 #线程 #同步锁 #最终一致性 #精确一致性 exactl
最差的程序员
衡量开发人员工作效率的最大好处是,你可以很快找出那些糟糕的程序员。我想给大家讲讲我认识的最差的程序员,以及我为什么要把他留在团队里。 几年前,我在 Twitter/X 上写过一篇关于我认识的最好的程序员的文章,我应该把它写成一篇博文。现在,我也应该
幽默:我们公司的管理情况
历史上代价最高的 11 个软件错误
软件错误造成的经济损失取决于几个因素。首先,支付开发人员和软件工程师来解决混乱的直接成本。然后就是停机、数据丢失和交易浪费。在此之后,还需要考虑声誉受损。任何遭受灾难性软件错误的组织都将失去客户和更广泛市场的信誉,甚至可能违反其服务协议。这可能会导致长期的财务损失,因为人们对品牌本身失去信任
什么是Bloom分类法?
如果您是一名软件开发人员,您可能听说过Bloom的分类法。它是一个将认知能力分为较低和较高层次的框架。您可以使用Bloom的分类法来增强您的学习过程并实现您的目标。 Bloom分类法的六个层次,按照认知复杂性的增加顺序,分别是:、记忆:获取
戴尔·卡内基《如何赢得朋友并影响他人》总结和要点
戴尔·卡内基的Dale Carnegie's 《如何赢得朋友和影响他人》How to Win Friends and Influence People是有史以来最受欢迎和最有影响力的自助书籍之一。该书于 1936 年首次出版,已售出超过 5000 万册,并被翻译成 30 多种语言。这本书是一本提高社
探讨英国空中交通管制崩溃的原因
2023 年 8 月 28 日,英国空中交通管制运营商 NATS遭遇重大技术事故。BBC 报道称,有2000 多个航班被取消,损失估计超过1 亿英镑。该事件可能影响了数十万人。 导致事件发生的一系列事件的起始点可以追溯到将飞行计划输入飞行规划系统的
数学家陶哲轩在形式证明帮助下发现论文中错误
数学家陶哲轩在Lean4形式化证明时发现已发表论文中的错误: 陶哲轩在用Lean4发现了一个小错误:论文论证中出现的表达式 12logn-1n-k-1 在 n=3,k=2 的情况下实际上是发散的。幸运的是,这个问题只影响到较小的 n 值,对于 n≥
一开始就能预先设计出接近正确的软件吗?
Leslie Lamport认为:如果你从一开始就没有正确设计,那么你编写的每一段代码都是一个补丁。 Leslie Lamport 是一位计算机科学家和数学家,因其对分布式并发系统的理论和实践的基本贡献而于 2013 年获得 ACM 图灵奖。他还创
有关麦肯锡量化开发人员生产力的错误之处
今年八月,咨询巨头麦肯锡在一篇题为“是的,你可以衡量软件开发人员的生产力”的文章中宣布了自己的解决方案,但引起了不同的反应。
演示驱动开发
演示驱动开发(Demo-driven development):将工作分解为用户故事,计划每周演示,并将会议重点放在目标而不是任务上,以推动有效的产品开发。 项目计划应重点关注里程碑和用户故事而不是任务: 用户故事代表了可论证的功能
构建软件最困难的部分不是编码,而是需求
在所有关于人工智能的发展有多么令人惊叹的文章中,有很多人都在担心,我们这些软件开发人员可能很快就会失业,被人工智能所取代。他们想象所有的企业高管和产品研究人员都会绕过大部分或全部的软件开发人员,直接让人工智能来构建他们认为想要或需要的东西。作为一个花了 15 年时间根据这些人创建的规格来创建
认知偏差中六个关键特征
认知偏差与视觉错觉一样,是人类认知的关键特征。 本论文仅将其分为几类: "我的经验是合理的参考"--这种信念导致人们把自己的经验作为判断他人的锚,从而产生错误共识、聚光灯效应等偏差。 "我对世界的评估是正确的"--这种信念会
Slowify:组织制胜秘诀
我与 Steve Spear 博士合着的新书《
软件架构本是软件工程师的一项职能?
在软件行业,似乎普遍认为软件架构和软件工程是截然不同的。在很大程度上,软件架构关注的是设计,而软件工程关注的是实现(即编写代码),两者在某种程度上是相互独立的。从根本上说,两者之间的联系大致类似于建筑行业中建筑师和土木建造师之间的关系。 但是,这并不代表软
以解决方案为导向的辅导沟通
SFBT(即以解决方案为中心的短期疗法)是由温斯康星州密尔沃基的治疗师于 20 世纪 80 年代初开发的一种方法。它主要由 Steve de Shazer 和 Insoo Kim Berg 推动,基于 Milton Erickson 等之前成功治疗师的工作。
上页
下页
关闭