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 358: Sticky Note Scandal and startup appeal


In this episode, Dave and Jamison answer these questions:

  1. During our next team meeting I jokingly gave a status report on the state of my desk and referenced the note.

    I believe this was the first time someone had publicly acknowledged the note writer, and it invoked a very passionate response from my teammates expressing their own annoyances with the anonymous writer.

    It began to escalate the following week. Copy cat writers began writing their own sarcastic notes, and junior devs were (jokingly) doing handwriting analyses to find the culprit. I participated in none of this.

    However my manager pulled me aside to say he is now forced to address the situation due to someone filing an official complaint that I was “instigating workplace harassment” and that I created a “hostile, unsafe environment”. He informed me we will be having a meeting with HR regarding this incident.

    I have never had a meeting with HR before. I am very afraid of potentially losing my job due to this. I find this whole situation ridiculous and feel very frustrated. Please help me not make this a bigger mess than it already is.

  2. Aaron asks,

    Last week I listened to a show where Jamison announced that he was looking for work, and specifically looking for small to medium startups. I have only worked at larger tech companies, and currently enjoy my position within one of the largest. However, I’ve always wondered what it would be like to work at a startup. What makes startups appealing? Is it still reasonable to expect a good work/life balance, or do you go in expecting a big shift in how you dedicate your time?

A smiling speech bubble

Episode 357: Waiting to be paid and survivor's guilt


In this episode, Dave and Jamison answer these questions:

  1. A listener Steve asks,

    How long is too long to wait to be paid?

    I’ve worked for 4 early stage startups in my career. Two were successful. One failed. My current one is “limping along” but showing signs of taking off.

    At the startup that failed, we stopped getting paid and some of us stuck around for 2-3 months until the CEO closed the business. I ended up unpaid for nearly 3 months of work.

    At my current startup, we are 3 months behind, and it has been this way for 6 months. The CEO is transparent about fund raising and clients slow in paying invoices.

    My question is still how long before I follow your age old advice?

  2. Listener Jess asks,

    How do I get past survivors guilt when my company does mass layoffs, but I am not one of the casualties? I’ve been at the company less than a year, and this is the second time they’ve fired THOUSANDS of people, including from my team; folks I work with at least weekly, and folks who have been at the company significantly longer than I have. I feel guilty that I, “The new guy”, am still employed, but the folks who’ve been there for years aren’t. How can I get past this and keep working to ensure I’m not caught up in the next round of layoffs? My manager says I’m doing good work, and the layoffs included complex inputs, but it that only helps a little bit.

A smiling speech bubble

Episode 356: Ummmmmmmmm and failed spikes


In this episode, Dave and Jamison answer these questions:

  1. I recently started listening to your podcast from the very start of the show! One of the largest differences I noticed (aside from the audio quality, lol), is how often you used filler words like “um”. How on earth did you manage to stop using them? In work presentations and demos, I often end up using the filler words, and listening to the recordings later is painful. The rehearsed parts of the presentation go smoothly, but as soon as I go out of the “script”, I start depending on filler words. How do I get better at this?

  2. How exactly should spikes go? I’ve done some deep dives to understand the scope and steps of an upcoming effort, all with detailed write-ups, only to later realize during the implementation that I got some things wrong or missed out some important details. Isn’t that the point of a spike, to root out any unknowns or surprises? Short of just doing the actual implementation, which I’m pretty sure is also missing the point of a spike, What am I doing wrong and how can I properly present post-spike findings to my team?