tl;dr:As a system scales, whether it is a manufacturing plant or a service like ours, the enemy is complexity. If you don't confront complexity in some way, it will eat you. However, complexity isn't a blob monster, it has four distinct heads: (1) States: When there are many elements in the system and each can be in one of a large number of states, then figuring out what is going on and what you should do about it grows impossible. (2) Interdependencies: When each element in the system can affect each other element in unpredictable ways, it's easy to induce harmonics and other non-linear responses, driving the system out of control. (3) Uncertainty: When outside stresses on the system are unpredictable, the system never settles down to an equilibrium. (4) Irreversibility: When the effects of decisions can't be predicted and they can't be easily undone, decisions grow prohibitively expensive.
tl;dr:On Monday morning the whole team i.e. engineering, product, customers, testers, designers, etc... asks and answers the same question: “What is most important for us to accomplish this week?” Then ask, “What can we actually accomplish this week?” On Friday afternoon get together & say, “How did we do? How did we react to surprises? Customers, how are you feeling? Engineers, how did the work flow? Product, how are customers acting in aggregate? Designers, how did your work flow & how are customers reacting?" Kent argues that this process creates energy amongst the team, a better sense of scope, collaboration, alignment and adaptation.
tl;dr:Kent discusses the nuances of code refactoring, emphasizing the difference between "horizontal" and "vertical" refactorings. "Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around – eliminating risk quickly and exploiting proven opportunities efficiently." Kent also introduces the concept of "Succession," which deals with breaking down the refactoring process into manageable, efficient steps.
tl;dr:“We wrote this article for software developers and engineering leaders, and anybody who cares about nurturing high-performing software development teams. By “high performing” we mean teams where developers satisfy their customers, feel good about coming to work, and don’t feel like they’re constantly measured on senseless metrics which work against building software that solves customers’ problems. Our goal is to help hands-on leaders to make suggestions for measuring without causing harm, and to help software developers become more productive.”
tl;dr:Kent shares a personal journey of understanding emotions using an established framework. He views emotions as envelopes containing important messages, encouraging readers to decode these messages instead of suppressing emotions, giving a "cheat sheet" that defines what kind of message each emotion brings, e.g., Fear as a call to focus, Anger as a call to enforce boundaries, and Guilt as a call to change. This self-understanding helps navigate life's challenges and fosters personal growth.
tl;dr:“How do you balance risk, novelty, production, growth, short-term certainty, and long-term viability? I learned a simple rule that has been useful to me and is often cited by my students as a key lesson from coaching: (1) 80% of your time goes to low-risk / reasonable-reward work, (2) 15% of your time goes to related high-risk / high-reward work and (3) 5% of your time goes to satisfying your own curiosity with no thought of reward.
tl;dr:Kent explains what Snapshot Testing is and how it scores on the test desiderata - a list of 12 desirable properties of tests. This list is a useful framework for evaluating different types of tests.
tl;dr:“Easy-to-test software is "controllable". Testers can cheaply and accurately simulate the contexts in which the software needs to run. Two contradictory patterns help achieve controllability: making parameters more concrete and more abstract. This apparent contradiction resolves when looked at from a broader perspective.”
tl;dr:“In fact, I believe that our skills as software developers are more valuable than ever before. While AI tools like ChatGPT can certainly automate routine tasks and help us be more efficient, they can never replace the human creativity and expertise that is essential to delivering high-quality software products.” Kent expands on this.
tl;dr:Blame is the opposite of responsibility — it’s someone with power pushing consequences away from themselves & onto someone with less power. The word “accountable” is often used as a proxy for “blame” - it’s not a relationship building strategy but used as a “relationship decaying” strategy. Kent discusses how this shows up amongst management.