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 152: How to pair program as an introvert and being mistreated as a contractor?

Download

In this episode, Dave and Jamison answer these questions:

  1. Hi guys! Big fan of the show. Here’s a question: What to do if I hate working in pairs?

    I’m in a tricky situation. I work on a great project in a team of great people We try to implement all the good programming practices. Retrospectives, cross-review, working in pairs..

    I hate working in pairs. I am a typical introvert-programmer and the thing I like the most about programming is that you can sit all day digging around the code and NOT communicate with the people. Or at least not all day. But how can I say that to my teammates? “Hey, I would rather work alone than talk to you guys.. By the way, love y’all!”

    It seems impossible to communicate that to my co-workers without hurting them. And moreover, this is a good practice. Which makes me feel horrible because I feel super-tired after whole day of talking to people. Plus I also feel like somehow I take up their worst qualities: if the person is slower, I become slow too, or start making mistakes. Help!!

  2. Hey guys, big fan of the show here. Thanks for your advice and time.

    The company that I work for provides “tech teams” for hire. In other words, American companies that want to outsource part or all of their tech team to a cheaper location can hire us and get developers and PMs at a fraction of what it costs in the US.

    I ended up working with an established fitness company based in NY. Their management insists that we are “regular” engineers in their tech team and we should participate in their technical discussions, agile meetings and so on. However, their engineers seem to be on a completely different page and treat us like monkeys that can write some code.

    For the most part, I can deal with their condescending treatment and everything else they might throw my way. The problem is that the company is currently in a very intense project and they are all “stressed” which seem to provide them license to be extra rude BUT ONLY TO CONTRACTORS. Their managers brush everything under the excuse of stress but I’m sure that wouldn’t fly if we were “regular” team members.

    How would you handle this situation? Any advice before I lose my temper? I’m also afraid that getting rid of a contractor is much much easier than firing an actual employee.

A smiling speech bubble

Episode 151: Where are all the old developers and Do I not ask enough questions?

Download

In this episode, Dave and Jamison answer these questions:

  1. I have a lot of software developer colleagues who are 20 - 35 years old but none 50+. At what age does a software engineer’s career end?

  2. Hi Dave and Jamison, thanks for the great podcast.

    I recently started a new position on a small remote team.

    The co-founders are increasingly dismayed by my lack of Slack-question-asking, although I have reassured them that I’m not too shy and I will ask when I’m stuck. I have daily one-on-one meetings with one co-founder, where I do ask questions about the code base, story requirements, potential side effects of my solutions etc. It’s an open-source project with comprehensive and Googable developer docs, so between those and my debugger I can figure everything else out with a bit of research.

    A co-founder told me that he expects to see me asking one or two questions per hour, and strongly implied that I need to do this if I want to survive my probation period. I was actually let go from my last job at the end of my probation period due to “brisk communication style” and “not asking enough questions”, so I’m freaking out now.

    I don’t want to annoy my colleagues with a constant stream of inane RTFM-style questions, but I’m stumped on how else to hit my question target! Can you help me come up with ideas? Is there some big picture reason for this obsession with question-asking that I’m missing?

A smiling speech bubble

Episode 150: How to fight imposter syndrome as a technical lead and Getting in to meetups

Download

In this episode, Dave and Jamison answer these questions:

  1. I worked for four years doing web development for a company while I got my degree, and loved it. I eventually became the lead developer because I had been on the team the longest.

    I thought it was really cool. I worked with the team to make organizational tech decisions, trained new hires, held regular meetings to discuss projects. After about 6 months, though, imposter syndrome started sneaking in and I felt like I was making things worse, not better. I figured the team needed someone who actually had senior level experience, and the pressure was getting to me. So I bailed.

    I’ve since had a few people approach me and say they want me to join their early-stage startup in a technical leadership position. I haven’t outright declined, but I’m nervous about being put in a position where the stakes are even higher.

    My question is if the pressure of being responsible for everything ever lessens. Is it something that gets better as you get more experience? Is everyone in technical leadership feeling this pressure and doing a good job to hide it? What can I do to gain the confidence to eventually lead another team?

  2. How do you step into the meetup scene? I have not attended one before, but the idea of them is interesting. However, there is this feeling that I would not fit in due to inexperience.