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 190: Disorganized startup and leveling up the team

Download

In this episode, Dave and Jamison answer these questions:

  1. My company is a startup and they’re super unorganized. I’m a junior-mid level engineer, and when I was onboarded, there was no documentation for how to run anything. I wrote a bunch of documentation and also made some PR templates to try and organize PRs. I’m super annoyed because things are constantly being messed with in our schema, and I don’t realize what we’ve changed until it correlates to a different issue that I’m trying to fix and then have to redo the fix because there’s this new change. What can I do to help my company?

  2. I’m a lead engineer at a small but growing startup. I work primarily on skunkworks projects. My teammate and I are feeling constantly underwhelmed by the performance of the rest of the engineering team, who are working on the core app. Their work causes limitation for us, makes the engineering team look ill-equipped, and we cant seem to make old dogs learn new tricks. How do we make it more apparent to the team, and the rest of the company, that it’s time to “level up” the engineering domain as a whole.

A smiling speech bubble

Episode 189: Building relationships and handling negative feedback with speical guest Jeff Leiken

Download

In this episode, Dave and Jamison answer these questions:

  1. Hi, I’m a software engineer who’s recently been promoted to a technical lead. I accomplished this mainly through work ethic, dedication to improving my skillset, a couple of large/notable projects, and some minor internal networking. After going through the promotion process, it’s become apparent how valuable it is to establish strong relationships with peers and seniors in your field.

    What advice or recommendations do you have for establishing these relationships within a company and how would you go about seeking a more senior engineer or leader to mentor you? Also, thanks for all your hard work - been listening to your episodes for the past 6 months and finding them very enlightening!

  2. I just got my annual performance review at work. The overall rating was “meets expectations”, but I worked really hard this year and thought I did great work. I was hoping for a higher rating than that. Maybe worse, this means I got a smaller raise than I expected. The review contained some suggestions for improvement. I feel pretty demotivated by the whole situation. How do I get out of this funk?

You can get in touch with Jeff Leiken at https://www.evolutionmentoring.com/.

A smiling speech bubble

Episode 188: Drama overload and agile ouroboroses

Download

In this episode, Dave and Jamison answer these questions:

  1. I work in a charity as an iOS developer and there is so much drama in the office about anything. I am so scared to talk with my backend engineer about work that we created a non-company slack workspace. This is how we communicate, even though we sit right next to each other. Please send help.

  2. I work in a company that’s around 10 years old with 1800 employees that started implementing agile methodologies a few years ago. It was great and improved the work, but now all the agile coaches are pushing to have physical boards and doing things apparently just to justify their own existence. I agree we all should try new methodologies but shouldn’t it always be based on a problem we are trying to solve? And shouldn’t all the team be on board with the change instead of just doing it because the agile coach wants to?