『Soft Skills Engineering』のカバーアート

Soft Skills Engineering

Soft Skills Engineering

著者: Jamison Dance and Dave Smith
無料で聴く

概要

It takes more than great code to be a great engineer. Soft Skills Engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into being a great software developer.2016 Jamison Dance and Dave Smith
エピソード
  • Episode 499: Should I quit my solo dev job with a sports team and senile seniors
    2026/02/09

    In this episode, Dave and Jamison answer these questions:

    1. I’m a new listener to the podcast and work as the sole developer for a sports team, which is the only company I’ve worked for since graduating from university 8 years ago. I listened to episode 493 while clenching my teeth as you told a listener to absolutely not take the job with the European football club as a solo developer. Yikes! While I feel I have continued to grow my skillset in my role, I’m now feeling vulnerable about having no professional experience working alongside other developers or on large-scale applications.

      I feel very conflicted about leaving my current company. I have a respectable developer salary for the (non-American) low cost of living area I’m in, have a great manager, and have built up a ton of good will and trust within the organization. I get all the freedom I could ask for to make design decisions, implement devops practices, try out new technologies, and make mistakes. I also find the work interesting and there’s always something else to do! I’m a little scared of the horror stories that I hear about the real dev world and don’t want to take my current situation for granted.

      I would really appreciate guidance on what you think I should do. I have clear skill deficits in certain areas, but would have to give up a lot of liberties with a role change.

    2. Listener Brian asks,

      My job is mostly okay, but could be better because of the people in it. I joined a greenfield project a few years ago as my first software engineer role after transitioning from other data work. I grew up with the project and improved my engineering skills. A year ago we hired two new people. They had relevant experience and seemed to know what they were talking about in the interview, and had five & ten years of experience (aka, more than me).

      Onboarding the first few months was whatever, BUT they’ve never really improved afterwards. They turn in work that has clearly not been tested or does not meet the ticket’s requirements, barely review PRs and have never (!) left any comments/feedback, and despite their level (senior+). I don’t really trust them to work on anything more than the smallest, simplest stories.

      I’ve provided specific feedback in PRs and in performance reviews (sometimes very low-level and specific, and sometimes very high-level about guiding questions or principles), but nothing’s changed. I’ve felt frustrated, drained, and confused - why is it such a struggle to get someone with an entire decade of development experience to turn in a straightforward PR? One other teammate has admitted (privately) that some work was sloppily done, which is consoling but otherwise I’m not sure if it’s bothering others as much as it does me.

      They’re offshore so maybe it’s just a communication thing? The rest of the team has been on the project since the beginning so maybe we’re poorly set up for new devs. I have high standards for myself and others and I’ve always been the most junior developer on the team and am new to the senior role.

      Am I just being a perfectionistic jerk? Is that a bad match for (essentially) junior teammates? Should I just reset my expectations and accept that their level and years of experience don’t translate into high performance? Thanks for any insights.

    続きを読む 一部表示
    33 分
  • Episode 498: Testing in big corporations and how to get my first management job
    2026/02/02

    In this episode, Dave and Jamison answer these questions:

    1. Hi Dave and Jamison,

      Internal dev asker from the second half of Episode 441 checking back in. Your “ask what scared the previous dev” advice in particular has paid off handsomely; I now carry around a little book of eldritch warnings and, somehow, people keep bringing me their unknowable monsters to interpret. It’s almost as though the previous dev knew these sorts of things would happen! I didn’t set out to acquire Lovecraftian knowledge, but here we are, still in one piece.

      Today’s puzzle: getting busy humans to test our stuff early, while feedback can still make it into production. We’re trying to build a culture where people will poke at a rough prototype now, instead of filing a Very Concerned Ticket three hours before release. How do we get people to test and provide feedback earlier? Do we stay disarmingly warm, promise tiny time boxes, and make a public show of “you said / we changed” until participation feels like the default? Or do we wave our terminal windows around threateningly on a screen share and promise doom (and minor annoyances) until they comply?

      Thanks for lending sanity to the abyss, —An increasingly arcane internal apps dev

    2. I have been listening to your podcast regularly and am inspired by how the podcast and the community have grown.

      I am a developer with over 10 years of experience and have moved to Sweden from a country outside Europe, with the ambition to build my long-term life and career here.

      For several years, I have tried to take that step myself, but often encounter the same obstacle: I am told I need experience as an engineering manager — but without the role, I can’t get the experience, and without the experience, I can’t get the role.

      I have invested a lot of time and energy in developing myself: learning about leadership, coaching, communication, and team dynamics.

      Despite this, I find it difficult to see a clear path forward. With everything happening in tech right now, I sometimes feel stuck and uncertain how to break this cycle.

      My question is: how did you take your first step? How can one realistically enter an engineering manager role when the door seems closed without prior experience?

      Thank you for creating such an honest and inspiring podcast. It already means a lot to me — and to many others, I am sure.

    続きを読む 一部表示
    32 分
  • Episode 497: Patronizing perf reviews and can't get anything done as a tech lead
    2026/01/26

    In this episode, Dave and Jamison answer these questions:

    1. I’m a relatively new people manager and I really struggle when it comes time for performance reviews, or even regular praise or critical feedback in one-on-ones, because I can’t help feeling like an adult “talking down” to another adult, regardless of whether the feedback is generally positive or critical and instructive. Something about it all seems so patronizing to me. How can I approach this stuff with a different mindset?

    2. Hello D & J! Quick one from your biggest fan!! This week (Tuesday 6th Jan 2k26) I was promoted to Tech Lead of our team. In my new role, I have done no work *cries*, I’ve spent all my time assisting team members, unblocking QA, dealing with ad hoc requests from product/stakeholders…. I asked the previous tech lead is this what they did? They did! And they said spent their personal time to complete stories assigned to them.

      Is this really what a tech lead does?!?!! Helpppp

    続きを読む 一部表示
    28 分
まだレビューはありません