/Career Advice

How Hard Should Your Employer Work To Retain You?

- Charity Majors tl;dr: Charity discusses employee retention strategies, arguing against excessive efforts to keep employees who want to leave. She emphasizes fair compensation, transparent practices, and proactive career development.

featured in #558

Writing

- Mike Fisher tl;dr: “Writing forces me to structure my thoughts, test my ideas, and refine my arguments. It is a way of holding myself accountable to the discipline of thinking deeply. Writing clarifies the ambiguous, reveals the gaps in logic, and uncovers assumptions that might otherwise go unchallenged. This is particularly important in my role as a leader where decisions have far-reaching consequences. A well-articulated argument not only influences but also educates and inspires. Through writing, I can communicate complex ideas in a digestible format that can be revisited, scrutinized, and built upon.”

featured in #557

Skin-Shedding Code

- Thorsten Ball tl;dr: “Shredding, on the other hand, means to embrace destruction. To go on a shred is to delete five load-bearing functions all at once and recreating them. Deleting a type and its definitions, rebuilding it from the compiler errors. Creating an empty file and building from scratch a better version of what already exists in another file. Shredding is ripping out a page and redoing it.”

featured in #555

Ideas From "A Philosophy Of Software Design"

- Eliran Turgeman tl;dr: Eliran discusses 3 ideas that resonate with him the most from the mentioned book: (1) Zero-tolerance towards complexity. (2) Smaller components are not necessarily better for modularity. (3) Exception handling accounts for a lot of complexity. 

featured in #555

Ideas From "A Philosophy Of Software Design"

- Eliran Turgeman tl;dr: Eliran discusses 3 ideas that resonate with him the most from the mentioned book: (1) Zero-tolerance towards complexity. (2) Smaller components are not necessarily better for modularity. (3) Exception handling accounts for a lot of complexity. 

featured in #554

What I Tell People New To On-Call

- Nicole Tietz-Sokolskaya tl;dr: “The first time I went on call as a software engineer, it was exciting—and ultimately traumatic. Since then, I've had on-call experiences at multiple other jobs and have grown to really appreciate it as part of the role. As I've progressed through my career, I've gotten to help establish on-call processes and run some related trainings. Here is some of what I wish I'd known when I started my first on-call shift, and what I try to tell each engineer before theirs.”

featured in #554

Doing Support Makes You A Better Engineer

- Ian Vanagas tl;dr: Ian covers: (1) Doing support makes you a better engineer. (2) Why engineers do support at PostHog. (3) Creating a support process built for engineers. (4) How to scale engineers doing support.

featured in #553

Stop Learning To Give Feedback. Learn To Receive It.

- Wes Kao tl;dr: “Just because you feel defensive doesn’t mean you should act on your initial impulses. Instead, assume positive intent. Find out more about what caused the person to say what they said. Wes shares a couple of examples of what to initially say and how to respond when receiving negative feedback.” 

featured in #551

The Ruthless Edit

- Jim Nelson tl;dr: So often in design, engineering, or product, you’re faced with this decision: how do we pare down what we have to something that feels like a cohesive whole? “Rick Rubin gives this advice about working in the studio with artists when making an album: Let’s say We’ve recorded twenty-five songs. We think the album is going to have ten. Instead of picking our favorite ten, we limit it to: “What are the five or six we can’t live without?” Then you say: “Ok here are the five or six we can't live without, now what would we add to that which makes it better and not worse?” It puts you in a different frame when you start with building and not removing.” 

featured in #551

The Life-Changing Magic Of Tidying Up Code

- Kent Beck tl;dr: “Tidying up works through a series of small, safe steps. In fact, Rule #1 is If it’s hard, don’t do it. I used to do crossword puzzles at night. If I got stuck and went to sleep, the next night those same clues were often easy. Instead of stressing about the big effects I want to create, I am better off just stopping when I encounter resistance.” Kent shares his approach. 

featured in #551