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 329: Falling behind and can't get a management job

Download

In this episode, Dave and Jamison answer these questions:

  1. I’m a few months into my first full time job, and the learning curve is immense. I feel like I’m falling behind and not keeping up with my work, as well as not understanding things that should be simple. I often feel I am wasting time on a lot of work that I do. How do I know if this is just an anxious feeling, or if I am legitimately falling behind?

  2. I am currently a staff engineer and have a career goal to move into management. I have been with my current employer for 15+ years and positions to promote into just don’t come up. The tech i work with is not very technical, there is no coding and its incredibly specialized. I have applied and interviewed for manager positions outside of my team/company and i get the same feedback that i am well qualified, but there is someone with previous manager experience that beats me. I see it being forever if not impossible to get a manager position due to people needing to retire etc. If i go to another engineering position i feel like i would need to start over in a junior spot. What other options do i have.

A smiling speech bubble

Episode 328: Fear of sudden firing and reducing the lottery factor

Download

In this episode, Dave and Jamison answer these questions:

  1. I’ve joined a team at a small startup and our team lead has mentioned in passing a few times about a developer they used to have but had to let go. Not in a malicious way but just as a matter of fact when it’s come up organically. Now it’s eating at me because I’m not sure if I’ll ever go down that path and I want to know what they did so I can avoid the same fate. I’ve always been a top performer at other companies but now I’m wondering if this would be the one place where standards are higher than what I’m used to. I really like it here and don’t want to lose my spot. Realistically my fear isn’t that I’d get fired in my first six months but more that I would fail to respond to constructive feedback over the course of a year and end up getting let go in the same manner. Do you have any advice?

  2. Hello! Long time lurker, first time question server.

    I am an intermediate software engineer and I work on a team that has a really tenured senior engineer. His attention is often required for a lot of things and the team can sometimes get blocked by him being pulled into many different directions.

    As someone that is trying to grow into a senior engineer myself, what are some ways to take some of the load off of him and improve the bus factor?

A smiling speech bubble

Episode 327: Remote with onsite team and undercover refactor

Download

In this episode, Dave and Jamison answer these questions:

  1. I have recently joined a team as a fully remote member, with majority of my team mates located in one city and meet in office every week. My manager wants me to work on earn trust and drive consensus, to keep me in track for promotion. Being remote, I am unable to get through my team mates effectively, when compared to my previous work settings where it was all on-site. Any tips for me?

  2. Hi Jamison and Dave!

    I’m a long time listener and I really enjoy the podcast. I have a small question for you two:

    My coworker recently asked for my opinion on how to write some code and then implemented it a different way. They knew I wasn’t a fan of their implementation and even went out of their way to not get it reviewed by me. Now we’re left with this shared code that stinks.

    Their code works but it’s clunkier then it should be and it’s bothering me. Should I fix it when they’re on leave and guise it as a refactoring that “needed to be done” or should I leave it alone and try to learn some lesson from this.

    The other option is to quit my job but other this small hiccup - it’s been going ok here.

Show Notes

This episode is sponsored by the Compiler podcast, from Red Hat: https://link.chtbl.com/compiler?sid=podcast.softskillsengineering