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 438: Software job after prison and working 60 hours per week at age 20 and feeling unfulfilled

Download

In this episode, Dave and Jamison answer these questions:

  1. I am a first time caller and full time listener of your show.

    I was released from prison a year ago and I coded for 18 years straight on all sorts of stacks as part of my job requirements in the pen. Imagine the irony when I discovered what codepen was.

    A dev told me about an opening for full remote/full stack web dev at their company. I’ve used the tech stack before but I have a non-traditional background to say the least. I’m not worried about being qualified but I have never worked in a team and I have always been responsible for production.

    I work for a large retailer in a non-coding role. I’m also doing some freelancing on upwork/fiverr, but the pay is low and the jobs are not fulfilling. I was self-employed before I was incarcerated and I know how to beat the pavement and get small time work, but this is an opportunity to work at a real software house. I don’t even care if it’s a feature factory, I just have loved coding since I was 14.

    What do I do? I am confident in my skills and ability to deliver under pressure (in a place that has pressures you can’t imagine). I have a cover letter, but a bad resume and no open source projects from this millennium. I do have a reference - a Captain I worked for said he was willing. However, the opportunity was unexpected and I have not prepared anything.

    The dev who brought me the offer was a casual friend in IRC and he told me that my resume was mentioned in some meeting. I know you have suggested in previous shows that having someone get your foot in the door is the best way but I really think that feels gross to me.

    Anyways, longtime listener of your show and first time caller. In fact, when I was in prison, a few years before I was released we finally got tablets with an incredibly limited amount of content. Your show was one of a few on coding but I really enjoy your take on the soft skills because even though I worked in a non-traditional environment, teamwork was always the focus and I listened to everything from square one (took me a long time to get there).

    So thank you for your podcast you don’t know how many times I could sit in my cell listening to your show and disappear from my cage.

    Sincerely, Names have been change to protect the guilty

  2. Second time caller from NYC! I previously wrote in as an 18-year-old CS graduate (Episode 332).

    I’ve focused intensely on work for the past 4 years, consistently working 60+ hours per week.

    I always assumed that this approach to life would eventually bear fruit, but a couple months into turning 20, I’m realizing that I haven’t really done anything memorable besides work (which is a scary realization at 20).

    While I like working hard and want to ensure the success of the company I work for, I also want to feel like I am living. How have you struck the balance between work and non-work in your lives, and how has that related to the culture of the company you were working for at the time? I should also mention the company I work for (early stage, well funded) does have a culture where it’s expected to work everyday, and 60 hours is approximately the minimum expected.

A smiling speech bubble

Episode 437: My company canceled all one-on-ones and moving to a single backlog

Download

In this episode, Dave and Jamison answer these questions:

  1. My company recently eliminated 1:1 meetings between managers and their direct reports. Previously, most people had these meetings every other week, and they were an opportunity to talk about career growth among other engineering things besides current work. They’re claiming the recurring meetings can be replaced with quick, more spontaneous calls when necessary. Although wiping meetings from the calendar does clear up more time to code, as a more junior team member, I’m concerned that this will negatively impact my career growth. It feels like career progression just got a little bit harder. What’s the read here? Is this a red flag? Should I start looking elsewhere? How can I navigate this changing environment and still make sure that I am able to progress my career?

  2. A listener named Matt says,

    I’d really like to move to a single team-dedicated backlog, where we use kanban and have work in progress limits, rather that the heavy release planning fixed-scope current model. I feel we would be more effective as a team that way (I’m one of many team leads in the company). Currently we operate in an agile-ish fashion but ultimately inside a waterfall process, driven from outside the technology team. Although I believe it would be a good thing, I’ve not actually worked in that way. Is it all it’s cracked up to be? Are there any issues of going to that model that I’m not seeing?

A smiling speech bubble

Episode 436: Paralyzed by checkboxes and I'm on a "must keep happy" list

Download

In this episode, Dave and Jamison answer these questions:

  1. Marcus Zackerberg asks,

    I work at a megacorp whose recent focus has been on reliability. The company already has mature SLO coverage outage response standards, but my org has taken it to the extreme this year. For example…

    There is now a dashboard of “service health” that is reviewed by engineering leadership. In it, services are marked “unhealthy” permanently upon a failing check (think HTTP /health). To return to a “healthy” state, one must manually explain the failure with an entry in a spreadsheet, which must be reviewed and signed off.

    Increasingly I feel this has the opposite effect, discouraging nuanced work to improve reliability and instead becoming “checkbox driven development”, as well as impacting our ability to ship on our existing roadmap items. Additionally, our tech lead is fairly junior and frequently fails to communicate the org’s expectations to the team, leading to us being under the gun of the reliability dashboard often.

    Any advice on how to make the best of this situation?

  2. Hi Guys! I’m a senior engineer at a mid sized software company. The company has had a couple of high level departures recently, and during that process I’ve come into the knowledge that my name is one of a handful on a list of “engineers to keep happy”. I feel like this information should be of use to me, but I’m unsure on how I should leverage it.

    On one hand it’s nice to know I’m valued, but I think I’d rather be explicitly told that or better yet, receive dollars in lieu of praise. I’m also at the point in my career where I’m looking for staff roles, and the topic of promotion has come up several times with my manager. He supports me (and I believe him), but we agree that it would be difficult to make the case to the business.

    What do I do with this new knowledge, and is there a way to benefit from it without accidentally triggering a preemptive search for my own replacement?