有问题的播客是《Future of Coding》的第61集。它实质上是对两篇我不熟悉但相信实际上很有名和有影响力的论文的通读/评论。
为什么听这个感觉像顿悟呢？嗯，我突然觉得我理解了软件是怎么回事。为什么当你加入一家公司时，已经在那里工作多年的工程师看起来像个不可思议的天才？为什么有些我所在的团队挣扎，而其他团队却能把每件事都做对？为什么每个人总是那么热衷于重写东西？
播客表达的两个观点是：
把这两个观点放在一起解释真的很有帮助。如果我自己读赖尔的书，我可能会想，“有趣但没用”。如果我不知道理论概念就读《Programming as Theory Building》，我就不会理解。
我建议听播客并阅读论文。但如果你不想这么做，我会试着解释这两个观点。
根据吉尔伯特·赖尔的观点，什么是理论？
当赖尔说理论时，他的意思与其他人说理论时的意思完全不同。真烦人。他应该想个新词。他指的是存在于我们头脑中的思维对象，它允许我们做事情。
例如，我知道如何煮意大利面。当我煮意大利面时，那是这种知识的某种表达。当我试图向你解释如何煮意大利面时，那是它的另一种表达。这两种表达都不包含我关于煮意大利面的全部知识。事实上，有些我知道的东西我真的无法用任何方式表达。这种知识就是赖尔所说的理论。我有一个“如何煮意大利面的理论”。这个理论不是存在于语言或行动中的东西，而是我们永远无法完全表达的东西。我们能做的最接近传递理论的事情就是一次又一次地向某人展示理论的表达，直到他们建立自己的理论。那个理论不会和我们的一样。
编程是理论建设意味着什么？这意味着我们创建的代码库并不是我们工作的真正产品。真正的产品是那个代码库的心理理论：
允许我们首先创建它允许我们诊断问题并修复它们允许我们轻松地修改它如果回想一下我与团队合作得很好并完成了工作的时候，那是一个这样的团队：
有人从我们开始工作的任何代码库/功能的开始就一直在那里其他团队成员慢慢加入，并有机会与知道更多的人一起工作；关注的领域没有改变。我们没有被重新分配到现有的随机项目，或者被要求修复其他团队的工作论文还讨论了当所有对给定程序有理论的人都停止在其上工作时会发生什么。它死了。哎呀。据说我们无法从代码和文档中重建理论。
这个模型解释了一些奇怪的现象：
“遗留代码”实际上是什么——它是一个不再由其理论人员维护的代码库。一个能够比一群同等能力的专业人士做出更好产品的独立工程师。独立工程师花时间建立了他们程序的完整理论，而专业人士则定期在项目之间移动——并且只对他们所从事的工作有理论。为什么熟悉不熟悉的项目比重新构建项目要困难得多。要真正建立一个理论，你需要在精神上重建现有的代码库。为什么外包或雇佣承包商总是看起来很糟糕。你可以从中学到什么留住软件工程师真的很重要！
！
！
Suddenly, I Understand Software
Even though I don't respect podcasts as an information delivery system, I recently listened to a podcast that felt like having an epiphany.
The podcast in question was episode 61 of Future of Coding. It is essentially a read-through/review of two papers with which I was unfamiliar, but which I believe are actually quite famous and influential.
Why did listening to this feel like an epiphany? Well, I suddenly felt like I understood what the deal is with software. Why is it that when you join a company, the engineer who's been there for years seems like an incredible genius? Why do some teams that I've been on struggle while others manage to get everything right? Why is everyone always so keen to rewrite things?
The two ideas that the podcast expresses are:
The concept of what a “Theory” is, according to Gilbert Ryle.That being a programmer is doing “Building theories” in the Ryle sense of the word.Having these two ideas explained together was really helpful. If I had read Ryle by himself, I would have thought, “interesting and useless”. If I had read Programming as Theory Building without knowing the theory concept, I would just not have understood.
I recommend listening to the podcast and reading the paper. But if you don't want to do that, I'm going to try and explain the two points.
What is a Theory, According to Gilbert Ryle?When Ryle says theory, he doesn't mean anything like what other people mean when they say theory. Annoying. He should have just come up with a new word. What he means is the thought object that exists in our minds which allows us to do things.
I, for example, know how to cook pasta. When I cook pasta, that's a certain expression of this knowledge. When I try and explain to you how to cook pasta, that's a different expression of it. Neither of those expressions contains everything I know about cooking pasta. And in fact, there are parts of what I know that I can't really express in any way. This knowledge is what Ryle would call a theory. I have a “Theory of how to cook pasta”. This theory is not something that exists in language or action - it’s a something that we can never fully express. The closest we can get to transferring a theory is to demonstrate the expression of the Theory to someone over and over again until they build their own theory. That theory won't be the same as ours.
What Does it Mean that Programming is Theory Building?It means that the code base we create is not the true product of our work. The real product is the mental theory of that code base which:
Allowed us to create it in the first place.Allows us to diagnose problems with it and fix them.Allows us to modify it easily.If I think about times when I've worked on a team that works well and gets stuff done, it's been a team where:
Someone has been there for a long time, since the start of whatever code base/feature we work on.Other team members have joined slowly, and had a chance to work with the people who know more.The area of focus does not change. We haven't been reassigned to a random existing project, or asked to fix some other team’s work.The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.
This model explains a few curious phenomena:
What “legacy code” actually is - it’s a code base which is no longer maintained by people who have a theory of it.The solo engineer who can make a better product than a team of equally competent professionals. The solo engineer has spent the time to build a complete theory of their program, the professionals move between projects regularly - and only have theories of what they've worked on.Why getting up to speed with unfamiliar projects is so much harder than just rebuilding the thing. To truly build a theory, you need to mentally rebuild the existing code base anyway.Why outsourcing, or hiring contractors, always seems to go so badly.What You Can Learn from ThisRetention of software engineers is really important!!!
