/Career Advice

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

On Being A Senior Engineer

- John Allspaw tl;dr: 13 characteristics of senior engineers: (1) They seek out constructive criticism of their designs. (2) Understand the non-technical areas of how they are perceived. (3) Do not shy away from making estimates and are always trying to get better at it. (4) Have an innate sense of anticipation, even if they don't know they do. (5) Understand that not all of their projects are filled with rockstar-on-stage work.

featured in #551

On Being A Senior Engineer

- John Allspaw tl;dr: 13 characteristics of senior engineers: (1) They seek out constructive criticism of their designs. (2) Understand the non-technical areas of how they are perceived. (3) Do not shy away from making estimates and are always trying to get better at it. (4) Have an innate sense of anticipation, even if they don't know they do. (5) Understand that not all of their projects are filled with rockstar-on-stage work.

featured in #550

You've Only Added Two Lines - Why Did That Take Two Days!

- Matt Lacey tl;dr: (1) Because the issue was reported with a vague description of how to recreate it. (2) Because the reported issue was related to functionality, I'm not familiar with. (3) Because I took the time to investigate the real cause of the issue, not just looking at the symptoms. (4) Because I investigated if there were other ways of getting to the same problem, not just the reported reproduction steps. 

featured in #550

Good Software Development Habits

tl;dr: “This post is not advice, it's what's working for me. It's easy to pick up bad habits and hard to create good ones. Writing down what's working for me helps me maintain any good habits I've worked hard to develop. Here's an unordered list of 10 things that have helped me increase speed and maintain a respectable level of quality in the product I'm currently developing.”

featured in #550