featured in #313
The Untapped Potential Of Less
- Leidy Klotz tl;dr: "No one argues that, when trying to improve something, we don’t often subtract. We pile on “to-dos” when we really need “to-stops,” or create incentives for good behavior … but don’t get rid of obstacles to it." People think first about adding and, as a result, systematically overlook subtractive changes.featured in #312
Ditch Your To-Do List and Use These Docs To Make More Impact
- Brie Wolfson tl;dr: Specifically for engineering directors, Will provides book recommendations and answers the following: "how do you foster execution on teams you indirectly manage?" Will cites 3 interesting pieces to consider: (1) Understand what’s happening on indirectly managed teams. (2) Adding things necessary for execution. (3) Remove things getting in the way of execution.featured in #310
featured in #309
featured in #308
Help Your Teammates Navigate Moments Of Self-Doubt
- Lara Hogan tl;dr: "If you have a teammate coming to you questioning their worth and effectiveness, I want to equip you with a framework that will help this teammate recognize their successes and impact." Lara discusses the BICEPS framework that covers: Improvement, Choice, Equality / Fairness, Predictability and Significance. As well as some questions you can ask your teammate e.g. In the last year, where have you created more clarity or predictability for people?featured in #306
Maybe You Should Do Less 'Work'
- John Whiles tl;dr: "Working in tech, I've observed developers who work as hard as possible when they don't need to. I'm here today to tell you that it's a bad idea and you shouldn't do it." By this, John means someone who has "no real sense of how much work is expected of them and then drives themself at an unsustainable pace trying to meet a standard." He advises us on a different approach.featured in #304
featured in #303
My Guiding Principles After 20 Years Of Programming
- Alex Ewerlöf tl;dr: (1) Don’t fight the tools: libraries, language, platform, etc. Use as much native constructs as possible. (2) You don’t write the code for the machines, you write it for your colleagues and your future self. (3) Deprecate yourself. Don’t be the go-to person for the code. (4) Any significant and rewarding piece of software is the result of collaboration. And more.featured in #302
featured in #301