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 346: Changing jobs with no raise and wrangling a cowboy coder

Download

In this episode, Dave and Jamison answer these questions:

  1. I recently applied for a job for a great company. The interview went well until we talked compensation. I said I expected to get a pay raise for changing jobs, but it seems that they can only offer me as much as I already have. I have never negotiated salary before. With my current job (which was my first) I happily accepted what they offered and we have had regular bumps without negotiations.

    Although I am really interested in the job, I feel like it is a defeat not to get a pay raise when I’m changing jobs for the first time in my career. The benefits are also not as good.

    Do you have any advice? Should I lower my expectations for a non-consulting position and switch despite not getting a raise? Should I negotiate harder? Wait for something better?

  2. Hi Dave & Jamison,

    we recently started a new project with a new team of devs that never worked together before. The team consists of two experienced backend devs, two junior backend devs and a couple of frontend devs. One of the junior backend devs has a mindset of just jumping into tasks, doing things without any previous analysis, just writing code for the first thing that comes into his mind. I like him being proactive, but this is causing big trouble: bugs, technical debt and often absolutely useless code. We had several discussions in the team pointing out some of the problems, but he is not interesested in changing his behaviour. During the last discussion he didn’t react to any of our arguments, just insisted on doing things his way. After that discussion we realized he even made some commits on an issue that has not been in the sprint nor has been refined yet _while we were talking to him_.

    Our team has no dedicated lead nor a scrum master and we work remote only. The next organization level is our CEO. I love the company, i love the team, i love the project, i even like this dev on a personal level. If we talk to the CEO i suspect it might have a bad ending for the junior dev since he is still in probation period. I know that we must talk to our CEO if things do not change.

    Do you have any advice? How can we reach him?

    Thank you for your great show!

A smiling speech bubble

Episode 345: Head of Engineering vs writing code and Voluntary Severance

Download

In this episode, Dave and Jamison answer these questions:

  1. I have around 14 years of experience and was recently promoted to a Head of Engineering role. I am now leading an engineering department of around 75 people. I’ve become increasingly ‘hands off’ with coding, and it’s been at least 2-3 years since I wrote code regularly. My role is completely hands off technically.

    I’m questioning whether this is the right role for me. I want be more hands on, but I worry my skills are now so rusty that I’d have to start over and spend all my spare time learning to code again.

    Do you think it’s realistic to get back to a hands on engineer role at this point? Have you seen it done successfully before? Does walking away from this leadership role make it harder to potentially take on other leadership roles like CTO in the future?

  2. Hypothetically speaking, let’s say that you were pretty sure layoffs were coming to your company even though they say they are cutting costs everywhere else that they can in order to avoid layoffs. Now let’s say that, hypothetically, in anticipation of this you took some interviews and received an offer from a company that you believe will ride out the upcoming economic downturn fairly well, and, hypothetically, you accepted the offer. Would you go to your manager and offer to take a voluntary severance, and in doing so, would you let them know you had something else lined up or would you leave that out and present it as just taking your chances while your severance checks were coming in?

    Thanks for doing what you do.

Show Notes

A smiling speech bubble

Episode 344: Showing impact without hiring and over over over engineering

Download

In this episode, Dave and Jamison answer these questions:

  1. I’m a senior front end engineer at a medium sized tech company.

    During the good times of limitless tech growth, a common way for engineers to grow our “impact” (an important criteria at many companies for promotion) was to find ways to lead/manage more people, whether this was becoming a manager and having more direct reports, or becoming a tech lead and mentoring more people, especially interns and junior engineers.

    Now, with many companies doing layoffs and hiring freezes (mine included), teams simply aren’t growing and there just aren’t as many people to “impact”. What are some other ways to have more “impact” and grow my leadership skills? Both for hitting promotion criteria, but also for my own growth as an engineer that would like to be a manager or staff engineer someday.

  2. I am a very senior engineer at my company. There is an engineer on the team less senior than me, but not under me on the management tree. This person is well regarded in the organization, but has a strong tendency to over-engineer things. Normally I don’t mind a little over-complexity if it means that the person leading the project is taking ownership/accountability of the feature. But with this individual, they tend to be put in a place to make sweeping decisions that broadly impact systems when it’s clear that they don’t really have a full picture of what’s going on. To make matters worse… when I raise these points directly, the person will usually offer to accommodate my concerns by further over-complicating their solution/architecture rather than stepping back and picking an approach more appropriate for the problem.

Show Notes

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