Focus On High-Leverage Activities
tl;dr: Leverage is impact produced divided by time invested. To increase your leverage, ask yourself the following before any activity: (1) What if this activity was simple? (decrease time cost). (2) What if this activity was huge? (increase value). (3) What else could I be doing? (opportunity cost).
featured in #370
Questions For A New Leader
tl;dr: A set of questions to guide these initial conversations, relevant for a new leader in any situation: (1) What are the things you are hoping I don't change? (2) What are the things you secretly hope I do change? (3) What are the good things about this organization we should build on? (4) If you were me, what would you do first? (5) Why isn't the organization doing better? And more.
featured in #368
The World Is Run By People No Smarter Than You
tl;dr: "My overwhelming lesson from the past few weeks is that even these heroes of tech are just mortals as well who make very very dumb mistakes. And if they can make those mistakes, so can you." The author elaborates on this viewpoint amongst recent examples.
featured in #368
Get Straight To The Point
tl;dr: "In a world of continual context-switching and distraction, if you’re able to make it as easy as possible for others to understand what you want, what the next steps are, and whether or not you have a strong preference, then you’ll find that your interactions are far, far better." James digs into this with examples and the following framework: (1) Make it clear up front what you want. (2) Make the next steps obvious. (3) If you have a recommendation, say it up front.
featured in #364
7 Estimation Anti-Patterns
tl;dr: (1) Estimates because “we have to.” (2) Neglecting different estimation opinions. (3) One estimator to rule them all. (4) Estimating takes forever. (5) Estimates need to be “correct.” (6) Estimates are turned into commitments. (7) Others do the estimation.
featured in #364
How To Build Software like an SRE
tl;dr: "My goal here isn’t “what is 100% the most reliability-oriented way we can build things”, it’s more like “what is the 80% of reliability we can get for 20% of the effort while still enabling devs to go fast“, which gets you ultimately a system that looks pretty different. But it’s a line worth walking – if you do it well, working with production is fun, instead of miserably-safe or frighteningly-dangerous."
featured in #363
When Life Gives You Lemons, Write Better Error Messages
tl;dr: Jenni covers what makes both good and bad error messages. For bad error messages, she gives cites: inappropriate tone, technical jargon, passing the blame and generic messages that have no reason. Good messages say what happened and why, provide reassurance, are empathetic, help the user fix the issues if possible and provide a "way out" e.g. a contact number.
featured in #361
Know Your Carrying Capacity
tl;dr: "I like to think of the collection of things that someone can reasonably maintain as their "carrying capacity", to borrow the ecology term. If you take on more than your carrying capacity, something has to die. With modern software being so garbage, I think one big reason is that there are too many software professionals out there who don't know their carrying capacity."
featured in #359
Mike Acton’s Expectations Of Professional Software Engineers
tl;dr: "Games industry veteran rattles off a sample of 50 things he expects of developers he works with:" (1) Can articulate precisely the problem trying to be solved. (2) Someone else can articulate the problem trying to be solved. (3) Can articulate why the problem is important to solve. (4) Can articulate how much my problem is worth solving. (5) Have a Plan B in case the solution to my current problem doesn’t work. And More.
featured in #358