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 392: Old code and choosing my annual reviewers

Download

In this episode, Dave and Jamison answer these questions:

  1. We are a team of under 10 people who provide technical services to other departments of our organization. We use a tool that is built by my boss to supplement our work but it is crucial for the team to do actual work. The boss maintains it all by themselves and nobody is familiar with its code.

    The boss is going to retire in a year or two, nobody wants to learn the code of that tool and the team can’t do much without the boss as we are more or less just individual contributors writing standalone code and delivering it to other teams who asked for it. Only the boss attends the leadership meetings and the developers are completely unaware of the remaining processes that happen in the background, i.e., communicating with other departments to bring in work, and all that business stuff. I am afraid the team would break apart once the boss retires because nobody knows anything on how our team operates beyond within team level except for the boss. Shall I just plan for the job switch?

  2. It’s annual review season! When choosing reviewers, do I a) choose the reviewers that will make me look the best or 2) choose the reviewers who might actually give me actionable feedback?

    If it helps, I am on very good terms with my boss and his boss, as well as most of the C-Suite, and there is no way that I get either a promotion or fired in this review cycle. I have been a top performer in previous review cycles, but I expect that I won’t be reviewed so highly this time around.

A smiling speech bubble

Episode 391: Post-staff and direct or a jerk

Download

In this episode, Dave and Jamison answer these questions:

  1. Hey guys! I’m a young engineer in a specialized area of infrastructure. I’m pretty good at what I do, and I’ve been through some leadership development programs, so I’ve advanced to a “Staff” role quickly, just based on observing the age of my peers.

    Tech titles are completely mysterious to me, so I’m wondering - how much “up” is there from where I am? What’s the top of the IC ladder? Do ICs ever become executives? The idea of being a manager and sitting in 1:1s for hours sounds awful to me, so I’m not excited about that side, but I’ve heard, allegedly, that there is room on the IC side for promotion as well.

    I’m a goal setter, and I kinda feel like I’ve hit a ceiling, so I don’t know where to set my target anymore. I don’t even know that I care about titles that much, but I very much like the pay raises that accompany them.

    Thanks!

  2. Johnny Droptbales:

    How do I tell if my manager is a direct communicator or a jerk? Should I trust my gut on this (he’s a jerk)?

    I’ve been working with my manager for a year now. He’s fairly fluent in English, educated, and keeps up with broad knowledge of our team/domain. He often connects different aspects of our work to discover discrepancies, bugs, and interesting ideas.

    I’m trying to wrap my head around his communication style. Here are a few examples that stand out:

    1. I refused to take on a new small project because I was concerned about meeting the deadline on my high-priority solo project. He gave me feedback that I missed an opportunity to demonstrate context-switching skills, which would look good for a promotion. I responded with my own reasoning, but he wasn’t interested and just moved on to the next topic.
    2. He insisted on a new weekly requirement for our on-call pager rotation, which is to come up with one idea to improve the experience. When I asked why asking for help on a problem wouldn’t be enough, he answered that he expected his engineers to have been hired for their critical thinking and leadership skills, and they should be able to demonstrate those.
    3. Recently he’s been leading weekly meetings to improve the on-call experience. He tends to ask very direct questions – we’ll look at a bug ticket, and he asks, “What is the root cause?” “Why do we do this?” “What are your ideas to solve this?” When pressed, he insisted this was a brainstorming sort of conversation, as opposed to a Q&A.
A smiling speech bubble

Episode 390: Fixing typos and Cassandra

Download

In this episode, Dave and Jamison answer these questions:

  1. I’m a backend engineer at a large non-public company. I noticed a bunch of our emails and website riddled with typos. I can not claim that it is metrics impacting or impacting business, so I get that teams always deprioritize, but the overall feel just irks me. Many of these come from a CMS I don’t have access too, so it’s not like I could offer to help with code even if I wanted. When things like this are not in your space, any advice on how to up overall quality?

  2. Possibly Mute Senior Engineer asks,

    I’m currently a senior engineer in a really small startup, and I’ve been here just long enough that I’m deeply familiar with our flagship product in multiple areas - infrastructure, the guts of the business logic, our deployment patterns, our most common failure modes, etc. Unfortunately, I have to be involved in every project and pick the application up off the ground when it dies. As a result, I’ve become spread very thin, and I have to cut corners just to stay afloat (or I am specifically directed to cut corners to meet a deadline). Frequently (because of all the corner cutting), we run into two situations that really tick me off:

    • I see bad thing on the horizon, talk to my team about it, am ignored, then bad thing happens and I get to have a crappy day fixing it
    • I recommend a basic best practice, we don’t use it and do some coat hanger + duct tape thing instead, thing breaks, and I get to have a crappy day fixing it.

    I’m very tired of being on the wrong end of the consequences of our own actions. I pour so much into this job, but I feel like I need to go get my vocal cords inspected, because it’s like my teammates and my manager can’t hear me when I talk about the things we’re doing poorly that lead to bad outcomes.

    Quit my job? Or is there an easy way to deal with this situation that I’m just missing? I feel like I’m screaming into the void every time I have these discussions and get completely blown off with “oh that’s not important right now” or “oh that terrible thing could never happen”. Thanks in advance!