Interesting learning resources - August 2025
These resources span from practical case studies in team scaling to theoretical frameworks for understanding programming languages, unified by a common thread: how we structure our thinking to solve hard problems. Whether examining ProTime’s journey from feature teams to domain-owned teams, exploring different approaches to teaching programming concepts, or critically evaluating the models that shape our decision-making, each resource helps navigating the experience of building software.
Scaling Teams with Ownership: A ProTime case study
A great example of using DDD. ProTime faced scaling challenges in 2023 as they grew across 40 countries. Their initial “feature teams” model—where small teams worked on single features for 4-6 months before moving to different features—began showing stress with unpredictable delivery times, spread-thin domain knowledge, and a “everyone owns everything” mentality that devolved into “no one owns anything.” This transformation involved cross-organizational workshops to redefine team responsibilities and ensure teams were involved earlier in the design process. Six months later, teams with stronger domain ownership showed improved delivery predictability, clearer capacity insights, and better alignment between team capabilities and business goals.
Operational and Denotational Strategies by Noel Welsh
Noel is deliberate when it comes to semantics, and this post really shows it. In this post Noel explores operational and denotational approaches to understanding and exploring programming language concepts. Operational explanations describe how a program executes step-by-step (like walking through function parameter substitution), while denotational explanations focus on what features mean to programmers at a higher conceptual level (like describing functions as ways to generalize expressions with changeable parts). He demonstrates this with examples ranging from basic functions to advanced concepts like type classes, showing how both types of explanations say the same thing but at different levels of abstraction. Might help both when teaching others, and in self-assessment of one’s own understanding.
All posts by John Cutler
There is no suitable summary to this. I’ve been visiting this landing page and randomly visiting pages and I learned something every.single.time.
Architecting the uncertain - Getting started with Agile Software Architecture Iteration Zero, C4, Event Storming by Johannes Seitz
This post advocates for Iteration Zero approaches, avoiding the trap of traditional upfront design. Software development is fundamentally a learning process and the author recommends incremental, iterative architecture work with the whole team participating rather than dividing work into independent packages. Key activities include understanding system context using C4 diagrams, identifying and rating risks through Risk Storming, understanding business processes via Event Storming workshops, setting up testing infrastructure early, defining quality attributes through scenarios, conducting one-on-one interviews with team members, preparing initial product backlogs through User Story Mapping, building walking skeletons for end-to-end functionality, and maintaining a learning backlog for new technologies and practices. The emphasis throughout is on structured learning rather than big design up front, with the goal of making informed decisions when they’re actually needed rather than prematurely constraining the project. This post seems related to, but different to a post by Hazel Weakly that I come back to a lot.
The Conflict-Intelligent Leader: In these turbulent times learning how to manage disputes is a must. by Peter T. Coleman
I highlighted some choice parts of the post to give you an idea of what the post should give you. Talking about the Good-Friday agreement, which was such a meaningful and difficult work on peace is the cherry on the top of this article!
Critically Engaging With Models by Rebecca Wirfs-Brock & Mathias Verraes
This needs a post of it’s own! I’m sure I’ll be quoting part of this in the future. To start with a useful definition of model:
“Models, whether for a software system, a development process, diseases, political systems, or otherwise, are a way to look at (a part of) the world. They explain how something behaves and how to modify that behavior. … Models are reductionist; that is, they only show a selection of the subject they’re describing, and lose something in the process. And models are biased: they implicitly reflect the assumptions, constraints, and values of the model’s author.”
Some of the heuristics, like most really important things, seem really obvious except this is the first time I see them all together in one place:
- If there are two ways of looking at something, look for a third
- Compare different models to figure out what one model adds or omits, emphasizes, or downplays
- Understand the underlying belief system that comes with the model
- Determine whether the model confirms my existing belief system and values, or conflicts with them
- Understand whether the model addresses or solves a problem that I’m interested in solving
- Ascertain whether the model points me to problems I might have but haven’t yet considered
Also
the post shows how to apply this ideas with an example. Definitely read and bookmark this.
To read
-
The Three Kinds of Organizational Power by Jacob Kaplan-Moss. I did read this, but given the work I’m doing I need to dive deeper on this, thanks Anja Kunkel for sharing this write up with me.