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 123: Salary Promise Fail and Slacker Coworkers

Download

In this episode, Dave and Jamison answer these questions:

  1. Great podcast! Love what you guys are doing and very happy that you are doing this for such a long time! Here’s the question.

    I started to work in a Startup a year ago. When we were negotiating the salary we agreed on amount X, and CTO promised that after a year it will be increased. He did say the exact sum. So, the year has passed, I followed up CTO about the salary raise, and he delegated the task to the manager, who decided not to give me a raise. When I asked ‘why?’ he said that I am good at negotiating my salary and I’m getting what the market is offering. I don’t feel bad about not getting more money, but the fact that the CTO break his word concerns me. I don’t think I can trust this company when they are promising anything and I started to care less about what I’m doing here. Am I delusional that a programmers salary has to increase even by 2% on a yearly basis and how to find a way to trust company in the future? Or just drop this and take the default SSE case - look for another job?

    Thank you for your answer.

  2. Hi Dave and Jamison, Absolutely love the show.

    I share an office with a peer who works on my team. We are both early in our career and are lucky to work under a very hands off manager. However, I feel my peer is taking advantage of the situation and is slacking off. He is rarely in his office and often states that he is ““working”” from home. When he graces us with his appearance in the office, he asks the most basic questions. Granted, those questions are internal and specific (not easily Google-able), but still, I feel he should have known the answers after a year on the job.

    He intentionally exploits our monolith’s slow builds by running full builds all the time and complain that it is slow. Then plays video games in the office until the build is complete (about 4 hours). Then makes a minor change in his feature code and kicks off a full build again, even though he could build incrementally (about 2-3 minutes).

    What do you recommend me to do? Should I spend time and energy to answer his lifeless questions? Should I confront him?

A smiling speech bubble

Episode 122: Too Much Process and Negotiating Salaries with Multiple Companies

Download

In this episode, Dave and Jamison answer these questions:

  1. Is it just me or does systems like Jira and TFS get managers to go crazy on processes? We have TFS and management has created a convoluted mess of processes that takes forever to learn and gets changed on a whim to be replaced by an even more convoluted process. Every time I finish a large feature and need to merge it in, I have to run around asking ten people on what process changed since there are all sorts of permission denied and other strange error messages. In my previous job, same with Jira and Jenkins. As an engineer, do managers really need these crazy processes that get in the way or am I naive engineer who doesn’t really understand the value of these processes?

  2. Just wanted to preface by saying that I absolutely love your podcast. It’s definitely helped me mold into a better developer and team player!

    My company is having a tough time raising our next round. In light of this, I am actively looking for my next position. Financial stability and growth is my biggest concern as I am planning to get married, buy our own place, and have kids. My goal is to interview at multiple companies and get competing offers. From a hiring perspective, I can definitely see how companies and see this in a negative light. How do I navigate salary negotiations so that I can get the best deal (financially) without being stereotyped?

A smiling speech bubble

Episode 121: Working Remotely Without Hating It and Managing Rotating Engineers

Download

In this episode, Dave and Jamison answer these questions:

  1. I used to work totally remote, but found myself absolutely hating it. The lack of office culture and human interaction.

    The problem is that in my area there are few local development jobs that match my skill set. I work in a large but heathcare heavy town, and their tech does not blend with my skill set.

    All to say. When it comes time to find my next job I’ll probably be looking for remote again. How can I come to love remote jobs, or at least survive?

    Maybe my previous companies remote culture was terrible. Is there any advice you can give when evaluating a remote culture at a company?

  2. Love the show! I had a question on how to effectively manage of team of engineers who have only partial allocation to my project. I am a project & technical lead for a team of ““8 FTE””, which is composed of a rotating cast of engineers who are allocated to my project in small percentages (most commonly between 30-80% of their time).

    This has a lot of challenges which you can imagine, but the one I am most interested in your thoughts on is the struggle with other projects about ““whose deliverable for a given engineer has priority””.

    As an example an engineer with 50% time on my project and 50% on another project will give me feedback that his immediate tasking between projects is unclear, he knows he has to do both workloads but feels they are uneven, or he is under more pressure from one project than the other. My company stack ranks during performance reviews and competition between leaders of matrix organizations (such as myself) in particular is fierce, so discussions between projects on how to effectively tackle this problem does not yield constructive agreements (in my experience). I’m at times guilty of trying to ““squeeze”” more than my designated allocation out of engineers to deliver on agreements for timing, scope, etc.

    Any thoughts are appreciated!