It takes more than great code
to be a great engineer.

Soft Skills Engineering is a weekly advice podcast for software developers.

The show's hosts are experienced developers who answer your questions about topics like:

  • pay raises
  • hiring and firing developers
  • technical leadership
  • learning new technologies
  • quitting your job
  • getting promoted
  • code review etiquette
  • and much more...

Soft Skills Engineering is made possible through generous donations from listeners. A heart with a striped shadowSupport us on Patreon

A speech bubble

Why should you listen?

Here's what listeners say:

Recent Episodes

Latest Episode

Episode 476: How much help is too much help and guarding against slop

Download

In this episode, Dave and Jamison answer these questions:

  1. Two junior engineers recently joined my team, and I’ve been tasked with onboarding them. This is the first time I’ve been responsible for junior devs, and I’m struggling with how to coach them up. For context, we’re a small engineering team where self-sufficiency is highly valued; processes/overhead is minimal, and we have a real bias for action. As such, when they ask me for help, my intuition is often to respond “Keep looking, figure it out!”; in my mind, walking them to the answer would be anthithetical to our culture and set the wrong expectation for how they should go about solving problems. This is especially the case when they throw their hands up and say “Help, I’m stuck, what do I do”. Though, I don’t want to be so unhelpful that it frustrates them or legitimately impedes their progress. I’ve also noticed them sometimes going “behind” me to ask others engineers for help, which makes me think that I am being too unhelpful. The number one question I ask myself is: How much help should I be giving them? How do I find the right balance here?

  2. I’m seeing more and more AI slop in my org’s code base that I fear will have meaningful impact on the integrity and maintainability of the application we deliver to customers. Everyone talks the talk of “Ultimately, it’s the implementer’s responsibility to audit and understand the code they ship,” but few seem to walk the walk. How can I best work with my team to address this, especially in a context where leadership is prioritizing velocity?

A smiling speech bubble

Episode 475: Am I too loyal to my big tech job and politely preserving time

Download

In this episode, Dave and Jamison answer these questions:

  1. Hi!

    I’m currently working for a big tech company and I’ve just accepted an internal transfer to another team. At the same time, an external company reached out, offering me a job for a role I’m interested in and twice my current compensation.

    I’m not sure what to do. The offer from the new company is very interesting and I wouldn’t think twice at accepting it if I still was in my old team. But now that I’ve accepted the internal transfer, I don’t know what’s best for my career: stay with my current company and lose out on a great offer, or go with the new company but likely burn bridges with my current manager, possibly closing off future opportunities to return to my current company (something that I’m open to in the future)?

  2. How do I politely but firmly stop a project manager colleague, who has vast open plains in their calendar compared to my Tetris-stacked week as a senior software engineer, from parking themselves at my desk for 45-minute vent sessions about everything that’s frustrating them about our project? It’s never just the weather; it’s a full-blown TED Talk on their annoyances, which makes me feel defensive and frustrated in return. I’ve tried the headphones-on-and-look-intently-at-the-screen-approach, and sitting on the other side of the office, booking a smaller meeting room to hide, and carrying on working as they tell me about their troubles with both leadership and members of my team. Nothing seems to work. They find me every time. Is there a way to escape without faking my own death or staging an office fire drill? Thanks!

A smiling speech bubble

Episode 474: I hate the idea of firing a low performer and cheaper context switching

Download

In this episode, Dave and Jamison answer these questions:

  1. Hi Dave & Jamison,

    Long time listener, first time google-form filler outer!

    I work in a hybrid role as a lead developer and manager of a small team (less than 5). I’m new to management and most of ny experience so far has been with smart, motivated engineers. . .

    UNTIL! My new recruit is driving me crazy, they are clearly very capable, but just do not do the work. They are frequently late for work, frequently sign off early, and constantly evasive when I ask for updates. I have spoken to them about these issues a bunch, and everytime they are apologetic and say they “have some personal issues but are working on it” - and nothing changes. Urgh!

    I am pretty sure I will have to fire them, but I feel terrible about it! I know I can’t keep them on and pay them to do nothing, but what’s the best way to let somebody go? How do I break the news to the rest of the team? How do I avoid feeling bad for the rest of my life?

    Yours guiltily,

    Anon

  2. A listener named “erm what the sigma” asks,

    Do you have any advice on how to reduce the ramp-up time when context switching? I’ve always felt like context switching comes at a high cost for me—it just takes so long for me to mentally shift between tasks. This wasn’t much of a problem before, but I’ve recently become a tech lead and now my calendar is cluttered with meetings (why did I ask for this again??). I’m struggling to complete my coding stories because just as I hit my stride, I get pinged by someone on my team to help them or have to jump into yet another meeting. pls send help