tl;dr:“That initial dip is the price you inevitably pay for improvement. If you built a factory you’d expect to pay first, see widgets later. How much you pay & when, how many widgets you see & when, those are the parameters that determine whether you’ve made a good investment. So with software design — how much you pay & when & how many features you see & when, those are the parameters that determine whether you’ve made a good software design investment.”
tl;dr:“In the end, write the docs you want to write. If no one reads them, or if readers find they are out of date, then consider not writing them next time. But don’t let anyone shame you into wasting time. The question is not, “Do you have documentation?” but rather, “Do you communicate clearly?””
tl;dr:“I had fun today debugging an infinite loop. Some of the techniques we used build on things I've talked about recently so I thought I'd reflect on the experience a bit. There's no happy ending to my story, though: the defect remained at the end of the session. Still, the techniques are worth thinking about because infinite loops in object programs can be difficult to debug. I wish you better luck with yours.”
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.