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 477: Four months and I already hate my job and grumpy and fuzzy

Download

In this episode, Dave and Jamison answer these questions:

  1. Hey guys,

    I have been working for four months at my job and I already don’t like it.

    This is my first job out of college and I work as a C# backend engineer for a small B2B SaaS company. I really think this company is a dead end. There is a lot of technical debt and antipatterns and we have no automated testing whatsoever. Most of our time is spent manually debugging but no one wants to refactor.

    I’m already thinking about working somewhere else. However, it took me a while to get this job, and I don’t think the market has gotten any better since. I’m trying to decide whether I should focus on applying to jobs again or if I should work on a bunch of side projects and open source to stand out better. On one hand, I can learn new technologies on my own to make me stand out for my next job, but on the other hand, I feel like as long as I stay at this company I am wasting time, since I’m not learning from my job. I want to switch to more distributed backend engineering in Java anyways, but I’m not sure how to go about it.

  2. Listener Ghani asks,

    “I’m a mid-level software engineer who has trouble communicating with my engineering manager and product manager when there is unclear or missing information about an assignment/story/project.

    They answer with hostile/dismissive tone/non-answer (e.g it’s on the jira-card, epic, etc). They course correct when they have the information later, harshly

    my impressions were

    • they don’t have the information at the time
    • they expect engineers to make decision
    • they expect engineers to know something they don’t (e.g architecture, infrastructure, past decision, plans, etc)

    I really want to look for where we can have a safe exchange of information. How can I do this?

A smiling speech bubble

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!