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 410: Guaranteed cost-of-living raises and my manager doesn't like me


In this episode, Dave and Jamison answer these questions:

  1. Hi Soft Skills!

    I’m writing to you as I look forlornly at my paycheck, unchanged for the last year and a half, and wonder if I’ll ever see market rate again. While I prepare my leetcoding skills for the trek that is your classic Soft Skills Adventure (quitting), I think about future interviews and wonder: how common is it to have something like a COLA clause in your employment agreement? Something like “Oliver will receive a raise of no less than the current CPI% per year”. Are there other ways to mitigate this, other than joining a company with more people and less greed? I don’t think I should have to beg for COLA-s with good reviews in hand. In fact I think those reviews call for raises!

    Thanks for bringing more joy to my life :),

    Mr Twist

    P.S. I am grateful I’m not paid in porridge and any reference to Oliver Twist isn’t to suggest Tech Salaries aren’t livable wages.

  2. Mr. Peanut Butter asks,

    I’m a senior IC at a small startup and I’m struggling to get along with an engineering manager. M has a say in my promotion and has already said no once, which was pretty painful considering the time and energy I’d spent helping their team succeed. I think there are two headwinds to M changing their mind 1) I’m FE-focused, and M’s conception of FE work is dated and simplistic. 2) M can be a bit of a blowhard. Said generously: M is a top-down thinker, quick to make conclusions, process-focused, and loves discussing architecture and design patterns. In contrast, I’m a bottoms-up thinker, pragmatic, plain-spoken, slow to make conclusions. M and I meet regularly to discuss cross-team matters, and it is my least favorite meeting of the week, even weeks that include dentist appointments. M sometimes devolves into lecturing me about software fundamentals (which I know at least a well as they do). I know from experience that there’s an M at nearly every company, so I’m reluctant to order up an SSE Special. How do I leverage this dreaded weekly meeting to turn M from a detractor to a promoter?

A smiling speech bubble

Episode 409: Fancy title to IC and CRUD is crud


In this episode, Dave and Jamison answer these questions:

  1. Listener Shayne asks,

    I’m about to start a new gig after 8+ years at a company. I was an early employee at the current company and have accumulated a lot of responsibility, influence, and a fancy title.

    I’ll be an IC at my new company (also very early stage) but the most senior engineer second only to the CTO.

    What are some tips for this transition? How can I onboard well? How do I live up to my “seniorness” in the midst of learning a new code base, tech stack, and product sector?

    I managed to stay close to the code despite adding managerial responsibilities in my current role, so I’m not worried about the IC work. I really want to make sure that I gel with my new teammates, that I’m able to add valuable contributions ASAP, and that folks learn that they can rely on my judgement when making tradeoffs in the code or the product. Halp!

  2. I got into software development to become a game developer. Once I became a software developer, I found out I really enjoyed the work. My wife and I joined a game jam (lasting 10 days) over the weekend. I very quickly have realized how passionate and excited I get about game development again! But this has led to a problem - I would much rather be doing that. I find myself moving buttons around or making another CRUD end point a means to an end now, thinking about how I much rather be creating exciting experiences. How can I handle this? Quitting my job to pursue a pipe dream just isn’t feasible.

A smiling speech bubble

Episode 408: Terrible retrospectives and "hard to work with"


In this episode, Dave and Jamison answer these questions:

  1. I am an electrical engineer working on and off with software for about 15 years. From mainframe applications with Cobol and PL/1 to plant floor supervisory systems with SCADA and some.Net along the way. 6 years ago my husband got an offer to move to Europe and I came along. Had to reinvent myself amidst the chaos of juggling life with a toddler, learning a new language and a new social tissue. After some time I landed a pretty nice job as a DevOps engineer at a pretty cool company. However, I have never really worked with scrum or agile methodologies before and, oh boy…I found out I HATE retrospectives. Like really hate them. They bring me down every time and I anticipate them with dreadful anxiety. I feel they’re just a way to blame other people for what’s not going so well and I don’t see ownership or any improvements actually being made. Action items are frequently just finger pointing and generally about people that are not even present in the retros. In order to improve engagement my boss said every team member is now responsible for the moderation of this dreadful thing and, surprise, surprise : I am next. How can I moderate something I just don’t believe in? I believe in improvement and learning from mistakes and I genuinely believe that we shouldn’t focus on people but processes. I also have to say my colleagues don’t feel the same way as they seem to love retros (yikes!). I think I’m too old/too skeptical for this. Please help!!! Ps.: I love your show and the episode on “that guy” changed my life. I’m forever grateful for the question asker and your answer.

  2. The Letter J:

    Can you please talk about the PIE theory (performance, image, exposure) and its importance, especially in highly political orgs? I lost my leadership role at a large GSI due to what I believe was a poor image. I felt I could not achieve targets without some level of collaboration (which became conflict once others didnt want to actually collaborate) We hit out targets, but unfortunately, by the time I realized I was labeled “hard to work with”, it was too late. Also, I hereby declare that Jamison is the Norm MacDonald of podcast, which is my highest compliment. Dave is some other comedian, also good. Seriously thank you both for all the humor and advice over the years, it’s been helpful and validating.