tl;dr:“At it’s best, a compliment is a warm fuzzy. Receiving or giving a compliment blesses the day. At it’s worst, a compliment is a naked power play, an assertion of dominance. Giving and receiving compliments are not natural skills. This article summarizes what I’ve learned about giving and receiving compliments so far.” Kent provides specific and actionable advice around the semantics of human connection.
tl;dr:For over 20 years, Kent has asked why are so many programmers musicians? He’s finally able to answer this: “talent for music and programming occur together because accomplishment in each relies on enjoying seeing patterns. See a pattern, feel good, look for more patterns.” He believes his chaotic early life left him with a brain wired to crave moments of order... and the innate ability to see patterns led him to activities where he got frequent mental rewards, and this is what drives his desire to program.
tl;dr:“From years of watching master programmers, I have observed certain common patterns in their workflows. From years of coaching skilled journeyman programmers, I have observed the absence of those patterns. I have seen what a difference introducing the patterns can make. Here are ways effective programmers get the most out of their precious 3e9 seconds on the planet. The theme here is scaling your brain.”
tl;dr:Test-driven development (TDD) is a programming method where new features are added without disrupting existing functions. It ensures new and old features work correctly, readies the system for future updates, and builds programmer confidence. The flow is as follows: (1) Write a list of the test scenarios you want to cover. (2) Turn exactly one item on the list into an actual, concrete, runnable test. (3) Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them). (4) Optionally refactor to improve the implementation design. (5) Until the list is empty, go back to #2.
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.