tl;dr:"The main reason I would encourage you to try engineering management is a reason that I’m not sure I’ve ever heard someone cite in advance, which is that it can make you better at life and relationships, in a huge and meaningful way. Work is always about two things: what you put out into the world, and who you become while doing it. I want to stop well short of proclaiming that “being a manager will make you a better person!” because skills are skills, and they can be used for good or ill. But it can." Charity discusses how management skills help with personal skills, such as self-awareness, understanding other people, hard conversations, and more.
tl;dr:“Many software engineers are encountering LLMs for the very first time, while many ML engineers are being exposed directly to production systems for the very first time. Both types of engineers are finding themselves plunged into a disorienting new world—one where a particular flavor of production problem they may have encountered occasionally in their careers is now front and center. Namely, that LLMs are black boxes that produce nondeterministic outputs and cannot be debugged or tested using traditional software engineering techniques. Hooking these black boxes up to production introduces reliability and predictability problems that can be terrifying.“ Charity believes that the integration of LLMs will necessitate a shift in development practices, particularly towards Observability-Driven Development, to handle the nondeterministic nature of these models.
tl;dr:Charity emphasizes the importance of small, positive interactions and offers specific tactics to rebuild trust. These include speaking tentatively, sounding friendly, taking time to compose oneself, communicating positive intent, and seeking clarity. The author shares personal experiences and insights, highlighting the need to over-communicate and overcompensate to avoid misinterpretations that can further erode trust. One strategy is the emphasis on engineering positive interactions, even artificially, to maintain a healthy relationship balance.
tl;dr:“The message is simply that it took me years and years to learn that there is more to being a great manager than caring about my team.” Charity discusses 3 rookie mistakes in new managers: (1) Only managing down. (2) Helicopter management - overly identifying with your team instead of considering them in context of the organization, or letting them take risks. (3) Your view of the business is incomplete.
tl;dr:Charity answers two questions: (1) How to drive change when you have no power or influence? (2) How to drive change when you are a tech lead on a new team?
tl;dr:Charity’s core principle is that “only the people responsible for building software systems get to make decisions about how those systems get built.” Effectively, the presence of an architect can make decisions “someone else’s problem,” resulting in weaker engineers and poorer systems. Charity highlights how architects can often be misused by organizations and best practices of how to use them in your organization effectively.
tl;dr:"In the beginning, there were people who wrote and ran software. At some point, we spun away ops skills from dev skills into two different professions, but that turned out to be a ginormous mistake, so along came DevOps to reunify them. Nowadays, ops as an independent profession is in the process of fading out. Companies are spinning down their ops teams left and right. Engineers who formerly identified as sysadmins or operations have turned into DevOps engineers, and soon there will just be “software people” again. This is the way of things."
tl;dr:"One of the classic failure modes of management is the empire-builder — the managers who measure their own status, rank or value by the number of teams and people “under” them." Charity argues the case for the opposite i.e. managing with a small denominator, or set of resources, and delivering outsized results.
tl;dr:"It took two decades, an IPO and a vicious case of burnout before she allowed herself to admit how much she hated her work, and how desperately she envied (guess who??) the software engineers she worked alongside. Turns out, all she ever really wanted to do was write code every day. And now, to her dismay, it felt too late. Why did it take Molly so long to realize what made her happy? I personally blame the fucking hierarchy."
tl;dr:"The thing that grabbed me here is that rituals create a sense of belonging. You show that you belong to the group by participating in the ritual... It seems especially relevant these days when so many of us are atomized and physically separated from our teammates. That ineffable sense of belonging can make all the difference between a job that you do and a role that feeds your soul." Charity provides examples from various teams.