24 korrents from this recording
Every claim below is a statement made in this recording, quoted word for word and linked to the second it was said, so you can hear it rather than take our word for it. The wording comes from the transcript published alongside the recording; the sentence above each quote is our reading of the claim, not their wording.
0:07:09 · watch on youtube.com↗
Their wordsIf I had to summarize what I found in general, I'd put it like this. Everybody hates waterfall.
0:07:18 · watch on youtube.com↗
Their wordsThe core tension of engineering is between how expensive it is to make a mistake and how quickly you can iterate. The faster you can iterate, the less planning you need to do before you iterate, and the more expensive it is, the more planning you need to do.
0:08:30 · watch on youtube.com↗
Our reading
Software did not invent iterative development: mining engineers had their Agile revolution in 1960.
Their wordsAnd the first thing he pointed out to me was that they had their Agile revolution in 1960.
0:12:11 · watch on youtube.com↗
Their wordsSoftware is kind of unique in having the third kind of the practitioner conference where we are just meeting to get better at what we do. We also are really the only kind to really focus heavily on like open source in making our knowledge freely available.
0:15:07 · watch on youtube.com↗
Their wordsYeah, I interviewed like 20 people on this. I think all 20 mentioned version control as the thing they wish they had in their old field.
0:15:54 · watch on youtube.com↗
Our reading
Software iterates better than every other engineering field and plans worse than all of them.
Their wordswhile we are a lot better at iterating than other fields, we're worse at the planning part. Like we still need to do some kind of planning before we iterate and we just aren't as good as those other fields.
0:17:03 · watch on youtube.com↗
Their wordsAnd that kind of compiling of information about the materials is something other fields do that we don't do. An analogy that I would think of in software would be something like a 500-page book on how to version an API.
0:17:35 · watch on youtube.com↗
Their wordsI think this project and writing about it and thinking about it has firmly moved me from the camp of we are definitely not to we probably are.
0:23:46 · watch on youtube.com↗
Their wordswhen you start talking about like most interesting domain problems, you have to pull in so much context that basically even writing what the function is supposed to do becomes a nightmare. The imperative program you write that will get correct 99% of the time is probably good enough to use in almost all cases.
0:24:55 · watch on youtube.com↗
Their wordsbut I can tell you with first hand experience nuclear power plants do not care about this stuff. They're actually just fine with with with thorough testing.
0:26:19 · watch on youtube.com↗
Their wordsThen the actual system might still have bugs, but we can iron out the issues in the abstraction such that we don't actually build them in the real system.
0:42:42 · watch on youtube.com↗
Their wordsI think a large part of the problem of why it's hard for us is because you don't get a lot of practice. Usually when you have a race condition in a system, you find out months later and then you try a fix and you find out weeks later after that if the fix actually worked.
0:47:02 · watch on youtube.com↗
Their wordsBut I think it is more useful for most developers to have an exposure to like what math has in the various fields versus just going all in every single field when they see them, right? You've got to know what's available to know what's most useful for you. And most math will not be useful for you.
0:49:13 · watch on youtube.com↗
Their wordsAnd I wonder sometimes if that is the reason people don't recognize the use of math in software engineering is because the math they do need is not the math they've been exposed to.
0:50:29 · watch on youtube.com↗
Their wordsI think the case of TLA+ and most, not all, but most formal methods, they shine the most in highly computational domains, where most of the problems are highly technical and not like business embedded.
0:52:31 · watch on youtube.com↗
Their wordsI think a lot of the reason people are skeptical of these is because they've been burned by things like case and UML and all these other miracle solutions that were forced on them by people who wanted them to use it no matter what.
1:05:13 · watch on youtube.com↗
Their wordsI love formal methods, but I think it's a fairly niche tool for most people and I think like property-based testing is in general going to be useful for more people.
1:07:38 · watch on youtube.com↗
Their wordsAnd often I found with my clients I have to tell them like it's doing a good job at generating the actual design, but in actually expressing what the design is supposed to do, it cannot do that yet. You have to do that part yourself.
1:09:03 · watch on youtube.com↗
Their wordsAs a general thing we've seen like to get good results you have to already know how to get good results without it. It just helps you get good results faster.
1:10:32 · watch on youtube.com↗
Their wordsI think it is making it more popular. I don't know if it'll make it go mainstream, but it's definitely making it a lot more popular. It's bringing it from maybe like 0.1% to 0.3% which is huge.
1:16:05 · watch on youtube.com↗
Their wordsSo, it's hard to tell how much of like the loss of the past few years was AI versus the end of like zero interest rate policy and like the post-COVID crash. And I think it's more the latter, but like again, LLMs are still getting better.
1:19:09 · watch on youtube.com↗
Their wordsI predict that in the next 10 years software development will survive, but it will become like any other white-collar professional work. No more $200,000 salaries, unlimited vacation, or incredible employee bargaining power.
1:21:02 · watch on youtube.com↗
Their wordsAnd up until now that like could only really happen if one of those people in that family that community or that school was like really really into computers. But now it's possible for everybody to have situated software.
1:22:43 · watch on youtube.com↗
Our reading
Nobody in software treats debugging as a discipline; it is left as a handful of basic heuristics.
Their wordsBut this is the book that I give to every junior engineer because I think like nobody ever really talks about debugging as like a discipline outside of like basic heuristics.