Kent Beck

Kent is an amazing guy! Met him a year+ ago at a friend's house and was fantastic to discuss the initial idea he had around this book, which was based on tons of experience at various engineering firms. He has been posting parts of chapters or thoughts in his newsletter for a while now - so it's awesome to see it compiled in one place! Newsletter if anyone wants to subscribe https://tidyfirst.substack.com/

Interestingly Kent Beck (the originator of Extreme Programming) has been doing a lot with AI coding and figuring out how it could be useful: https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes I remember he first posted 2+ years ago, back when people first realized ChatGPT might be useful for coding, that "90% of my skills are now worthless and the remaining 10% are worth 1000x" https://tidyfirst.substack.com/p/90-of-my-skills-are-now-worth-0

The first comment to the post referenced Kent Beck's: > "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate" [0] At the time that felt like an exaggeration, but from my own use of Claude Code over the last month, I now entirely agree. My take on this is that we need to educate future devs from the very start as engineering managers - to be concerned a lot more with the "what", the "why" and the "is it good for our expected needs" rather than the low-level "how". [0] https://tidyfirst.substack.com/p/90-of-my-skills-are-now-worth-0

See also "Eventual Business Consistency"[0] by Kent Beck. Really good read. > Double-dated data—we tag each bit of business data with 2 dates: > * The date on which the data changed out in the real world, the effective date. > * The date on which the system found out about the change, the posting date. > Using effective & posting dates together we can record all the strange twists & turns of feeding data into a system. [0] https://tidyfirst.substack.com/p/eventual-business-consistency

My general advice is to be aware when you're in the grief cycle and get out of there as fast as possible so that you can think clearly. A lot of people in the comments are in denial and bargaining. You sound like you're at depression... almost out of it! But things will continue to happen. Some people take years to get out of denial or anger. In this period, they do really dumb things. Things will get worse. Which causes more grief. Catch yourself. Let the emotions flow, but be aware of the process. Maybe you choose to fight it, but try to get into the Acceptance phase first, where your anger can strike like a hammer, instead of a river. A lot of the pro-AI people have been there too. Kent Beck wrote a nice article on his experience: https://tidyfirst.substack.com/p/90-of-my-skills-are-now-worth-0

Maybe you're right. Obviously, if this advice helps people, then I should just back off. It's true that removing code is better than adding it, and that code is a liability. And I admit that I needed to hear that early in my career. But the article acknowledges that "over-adherence to [that] dogma can be counter productive". Great--so how can I tell if I've gone too far? How do I know if I should write more code or less code? How do I know if my code is "dumb" enough? The article does not help with that. Saying that "code is a liability" is not actionable advice. Edit: In contrast, I found this article full of actionable advice: https://tidyfirst.substack.com/p/mastering-programming

>One test. A really truly automated test, with setup & invocation & assertions (protip: trying working backwards from the assertions some time). It’s in the writing of this test that you’ll begin making design decisions, but they are primarily interface decisions. Some implementation decisions may leak through, but you’ll get better at avoiding this over time. If you're truly doing interface decisions without leaking implementation decisions then your test is probably doing something like using playwright to follow a user story or calling a REST API and seeing what comes back. In which case, it probably isn't providing software design feedback, as described in the previous blog post: https://tidyfirst.substack.com/p/tdd-isnt-design Both blog posts desperately need some examples.

> Tortoise and the Hare… the urge to hurry up and burn hard the first two weeks (low hanging fruit, visible wins, MVP!), resulting in ever decreasing momentum due to immature design and in-dev maintenance needs is befuddling to me. Well said. In Kent Beck’s Tidy First, it explores the slow process that can be summarized by this except from his substack [0] “Valuable” lives on 2 axes: Features—what the code does now. Futures—what we can get the code to do once we learn the lessons of this set of features. While there might be a component of time to get features out, it’s rarely urgent enough to forget about being flexible and having a somewhat constant velocity. [0]: https://tidyfirst.substack.com/p/genie-tarpit

Relevant post by Kent Beck from 12th Dec 2025: The Bet On Juniors Just Got Better https://tidyfirst.substack.com/p/the-bet-on-juniors-just-got-better > The juniors working this way compress their ramp dramatically. Tasks that used to take days take hours. Not because the AI does the work, but because the AI collapses the search space. Instead of spending three hours figuring out which API to use, they spend twenty minutes evaluating options the AI surfaced. The time freed this way isn’t invested in another unprofitable feature, though, it’s invested in learning. [...] > If you’re an engineering manager thinking about hiring: The junior bet has gotten better. Not because juniors have changed, but because the genie, used well, accelerates learning.

> Software engineering has got - in my opinion, often needlessly - complicated, with people rushing to very labour intensive patterns such as TDD, microservices, super complex React frontends and Kubernetes. TDD as defined by Kent Beck (https://tidyfirst.substack.com/p/canon-tdd ) doesn't belong in that list. Beck's TDD is a way to order work you'd do anyway: slice the requirement, automate checks to confirm behavior and catch regressions, and refactor to keep the code healthy. It's not a bloated workflow, and it generalizes well to practices like property-based testing and design-by-contract.

Aka 'bitemporal' - https://tidyfirst.substack.com/p/eventual-business-consistency

https://tidyfirst.substack.com/p/canon-tdd isn't particularly new; Beck has been consistent about "write tests before the code, one test at a time" for about 25 years now. Same idea, different spelling: do you really think TDD should get credit for your good results, when you aren't actually shackling yourself to the practices that the thought leaders in that community promote?

Time to actually read Test-Driven Development By Example, my friend. Or if you can't stomach reading a whole book, read this: https://tidyfirst.substack.com/p/canon-tdd TL;DR - If you're writing more than one failing test at a time, you are not doing Test-Driven Development.

If you like this model you may also enjoy “paint drip people” https://tidyfirst.substack.com/p/paint-drip-people

"Coding in the Debugger" KENT BECK 2007 https://tidyfirst.substack.com/p/coding-in-the-debugger

I mean I think it's fair to assume that TEST-Driven-Development has something to do with testing. That being said, Kent Beck recently (https://tidyfirst.substack.com/p/tdd-outcomes) raised a point saying TDD doesn't have to be just an X technique, which I wholeheartedly agree with.

It's not that simple though. His own article "Canon TDD" [0] still involves writing a test before writing the corresponding code. In my experience, the practicalities of all but the most far-removed integration tests (i.e. when receiving this request, server ultimately returns this response) mean that I would be effectively doubling my workload by having to repeatedly refactor two sets of code as I explore. The TDD steps listed do include refactoring if/when required, but I'm not entirely sure Kent had exploring and comparing half a dozen different approaches in mind for that one. It still seems fundamentally geared towards implementing a solution you've already arrived at. I'm not disputing TDD as an effective strategy—I've seen it work wonders for some of my colleagues and I will still occasionally employ it myself when making additions/changes to well-established bits of code. But, for me personally, I feel I can stay in the flow and get all the same benefits by just doing step 1 ("Write a list of the test scenarios you want to cover"), implementing the code, then actually implementing those tests at the end. [0] https://tidyfirst.substack.com/p/canon-tdd