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 323: Shopping offers and returning equipment

Download

In this episode, Dave and Jamison answer these questions:

  1. I’m planning to leave my job purely because of low compensation. I like my growth in my current company - but low compensation than what market is offering is quite a mental hiccup in my regular work (yep! I’m slowly becoming one of the quiet quitters). I’m thinking of going to my manager with my new offer and ask him to match it. Do retention offers actually work? As mangers yourselves, how would you want me to approach a retention discussion? I don’t want my manager to make my life hell under the pretense of “Oh he’ll leave in a year” if I do decide to stay after taking the matching offer. Love the show - pretty much my single source of wisdom for all my behavioural interviews xD

  2. I was recently let go from a company. They said they would send me a shipping label so that I could return the hardware. I didn’t hear back from them for a week. A few days later a label came in for the laptop, but not for the dock or the two monitors they also sent.

    I did not enjoy my experience there and I’m feeling resentful at having to pester them so that I can get what I need to send them back their hardware.

    What is my due diligence on the score? I don’t even like the monitors.

A smiling speech bubble

Episode 322: Cover blown and no one cares

Download

In this episode, Dave and Jamison answer these questions:

  1. Listener Olexander asks,

    I was a tech lead on some relatively known project since the beginning for more than a year. I made several trade-offs with technologies and wrong decisions. I participate in some generic Slack organisations and met several users of my product. I haven’t told them that I was connected to implementing the project but sometimes shared some insights on how the product is tested and asked opinions about some of features of the product in comparison to the competitors. Now there is a person who continuously critiques the product. Sometimes the criticism is valid but sometimes is’s just a rant. How can I influence that person without blowing my cover?

  2. Listener Kieran asks,

    Hi guys! Loving the podcast from down under. I’m working part time as a dev while I complete my software engineering degree. It’s been fun, but there are almost no processes in place for development and not many other devs seem to care about improvement.

    Although I am the most inexperienced here I feel some of the devs do not care about the quality of the work as I often have to refactor some of their code due to it being buggy, slow and undocumented (still using var in javascript).

    I’ve talked to management about improving our standards. However, they brushed me off saying yeah some of the developers are stubborn. They are not brushing me off because I lack technicality as Ive been given an end user app as a solo project. How should I go about encouraging the team to improve our processes?

A smiling speech bubble

Episode 321: Politely, no and participation at scale

Download

In this episode, Dave and Jamison answer these questions:

  1. How do you politely tell a reviewer politely, “Your suggestion is stupid. I will not do it” when you get stupid review comments. If you don’t do it then the pull request can’t move forward because of unresolved issues. If you do it, then you’re compromising your design you’ve worked weeks on for some fly-by random comment.

  2. A few months back, I volunteered as co-facilitator for my department’s NodeJS Guild meeting. At first, it was a struggle to get people to present. But I tried to lower the bar more and more until it was easy. I asked for 10-15m presentations, and eventually I realized people are happier “Kicking off a discussion” than they are “giving a presentation”. All the listeners are more engaged too, at least after the first 2 meetings doing this.

    Now I want people to share half-baked code, or problems they are struggling with, as part of our discussions. I want people to be able to be vulnerable. If we don’t collaborate on common problems until we feel they’re polished and won’t reflect badly on us, then we will all waste time solving the same problems.

    I also want this to scale across 15-25 small scrum teams. I think success could be my demise–if we have good discussions, then more people will come, but people won’t want to be as vulnerable with a larger group.

    In general, I think my own scrum team is very open and vulnerable to each other, but the remote work in the deparment has created distance. I want to help create more collaboration on similar problems and solutions.

    What would you do to keep this going, and improve it?