I sooo agree with the apprenticeship idea. I had a couple of masters during my life and they where priceless.

Dave Farley you should really stop promoting TDD and trunk development in your videos. Embracing trens is never a good thing. You have already done enough damage. I have seen so much damage done by the practices you promote, especially TDD and trunk development.

DT lost me with the state discussion. Sorry but snapshots just kick the can down the road. If you and I have different snapshots that we have changed, we still have to figure out how to merge them back together. Anyone who has ever fried their brain on a git merge conflict knows that pain.

Wow, that was a really good video.
I really enjoyed hearing the different perspectives about testing, and I totally agreed with how we should teach programs, immutable states, and the dynamic event style of code.
Thank you for your time, and keep doing your good work

What D. Thomas says at 1:17:55 made me think of Reenskaug and Coplien's DCI. Aspirationally, DCI injects behaviour to maximise the ability to reason about code. I haven't tried it so can't comment. D. Farley's association moved in the opposite direction – not injecting essential complexity to improve the ability to reason about code. So I'm really curious if you ever tried DCI D. Farley? If so how was it?

Of course your project is fine without unit tests in 6 months and coding by yourself. That's like an initial stage for many projects. What about in 6 years on a team of 6 devs that change every 2 years? There's plenty of evidence in industry, it's not like it hasn't been tried and it's just dogmatic. I can tell you because I've seen it many times – it's a total mess! The code can't be refactored, it's not object oriented, nested private methods everywhere, etc. People are afraid to touch any code because any change can break something. Even the smallest change will require extensive E2E testing. It's so bad that it's better to throw away the code and start fresh with unit tests from the start.
And if a senior can write decent code without tests a junior in many cases can't. Spaghetti code, not object oriented, etc., etc. I've rarely seen teams of only seniors. Just by making your code testable you fix so many problems.

Re immutable code: A Maven JAR file is normally immutable, so if you request (Clojure DEPS/CLI style) something like `org.clojure/clojure {:mvn/version "1.11.1"}` you will always get the same library. However, there is alternate syntax `org.clojure/clojure {:git/sha "a8e32aefe55730119040548925cf0eba9ceacb48"}` which pulls source code directly from a Git repo with the specified SHA. In either case, you get immutable code.

16:01 I have to disagree on the advice of "Avoiding Test Nazis". Apparently I am the definition of a Test Nazis, because among all the pet projects I have created, the only one that I can sustain (others have been kept as reference and stale) is the one I keep 2 principles: All Tests pass and Coverage is 100%. Like these are the only 2 principles that you can quickly validate (given that you have the right tools). And when you have these 2, you are free to refactor your codes (cuz your codes will never be perfect and through the change of requirements, you will find it breaks SOLID or other kinds of principles in one way or another). Not only that, you also can change or refactor your tests: Make your test shorter, or easier to read with fluent validation, remove fragile tests, or reorganize them in certain orders, you are free to do it as long as the test set still pass and still cover 100% of codes (of course it does not mean the mutation test is 100%, but to be honest, you never reach 100% mutation coverage).

Still, great talk! I love the part there are things you can only learn and cannot be taught.

Dave Thomas talks about state in such an elegant way, he reminds me of high level artists talking about gesture. Partly because I understand neither.

I was in Computer Science program in the late 80's. Had to write Intel Assembly more than 50 lines.

The Enterprise believes that agile and Scrum are synonymous and have plagued us all with that misguided idea.

I think the conversation is Agile vs Project Management as waterfall is a symptom of PM. Agile is rooted in design thinking. Read the definition of design thinking and then try to explain how a schedule would make any sense. The problem is that most people, both technical and business managers can't figure out how to manage this.
"Design thinking is a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test. Involving five phases—Empathize, Define, Ideate, Prototype and Test—it is most useful to tackle problems that are ill-defined or unknown." Definition from Interactive Design Foundation