“I like the idea of using this data to explore the why rather than focusing on the overall number… There are some types of people that see that number and it's a confirmation bias. Like, of course, everything is terrible. But that's not the reason to ask about this and to quantify it. The reason to ask and quantify it is to find out why and to do something with that information.”

This week, Dev Interrupted dives into the 2024 Stack Overflow Developer Survey, revealing a surprising statistic: only 1 in 5 developers are happy in their jobs. 

Stack Overflow's Senior Analyst of Market Research and Insights, Erin Yepis, joins host Ben Lloyd Pearson to discuss the survey's findings and explore the reasons behind this widespread dissatisfaction. From salary woes and workplace settings to the ever-present burden of technical debt, they dissect the factors impacting developer happiness.

Later, Dan Lines offers his perspective, drawing on LinearB's data to pinpoint three key challenges to developer satisfaction. He also shares valuable strategies for tackling technical debt, a growing concern as more companies transform into software-driven businesses.

Show notes:

Transcript

Ben Lloyd Pearson: 0:09

Hey everyone. I'm your host, Ben Lloyd Pearson, director of developer experience here at LinearB. And today I'm excited to be joined by Erin Yepis senior analyst of market research and insights at Stack Overflow. So Erin, thank you for joining us today.

Erin Yepis: 0:24

Thank you for having me. And, I wanted to make a quick mention. I love the name of this podcast and I have listened to a couple of episodes and I like the content of this podcast too.

Ben Lloyd Pearson: 0:37

Wonderful. I always love getting a compliment at the start of my day. So thank you for that. so I wanted to bring you on because, Stack Overflow has this developer survey that comes out every year. And we'll have a link to that in our show notes for our audience. But I heard you actually on another podcast discussing this survey and just felt like we had to get you on because it's such a relevant topic to our audience. In particular, like we think about, developer productivity, developer experience, like those really come to mind a lot. And I think there were some like pretty fascinating and maybe even alarming takeaways about developer happiness and job satisfaction I was really looking at like the professional developers section of the survey. Cause you know, a lot of our audience are people who do software development professionally. And the thing that really stood out to me was the, Alright, one of the findings that said that only about 1 in 5 professional developers are currently happy with their job. can you break that down for us? What does this tell you and what does that number mean?

Erin Yepis: 1:41

Definitely. And, I'm happy to talk about this because this is a new question this year for the 2024 survey. Part of my job, looking at the survey responses is to figure out the why behind the numbers. And so this new question gave us an opportunity to. We also look at our community, which we also, our community is mostly professional developers as well. And then ask them how they feel about work. We have, we've run surveys in the past where we ask directly, developers how their jobs are going. We ask them, some questions about what do you look for when you're searching for a new job? What are some of the reasons why you might leave your current job? But this would be the first time we're asking just blanket statement, umbrella statement. Are you happy with your current job? So I definitely thought it was really cool. And so also we know in the background, of a lot of the research we've been doing too, that there's been disruptions in the industry. So it was top of mind as far as like the satisfaction goes, job satisfaction. For this question in particular, we used a NPS style scale for, which means users could select from zero to 10, happy, unhappy, 10 being happy. The NPS style I thought was a good. I'm not sure if there's another option for this question, because unlike the Likert scale, which is five options, the NPS, relies a little bit more on the normal distribution, assuming that a lot of people are going to be picking something closer to the middle. That way, if you are categorized as a promoter or happy developer in this scenario, you selected nine or 10. And I also like this too, because so for anyone that was maybe a little wishy washy on the fans. It's like saying, if you're not a hell yes, you're a no. I thought it was, yeah, sometimes the surveys with a qualitative approach, you have to be a little bit tricky in order to get the real scoop.

Ben Lloyd Pearson: 3:45

Yeah. Interesting. it's surprising to me seeing that, I think that same number was about almost a third of developers were unhappy with their work. So there's a, there definitely seems like there's this large. Volume that's in the middle, I think the word you used in the survey to describe it was complacent with their jobs. It's just surprising to see that 80 percent of developers basically are really not engaged with their work. And to me that, that goes against my perception of the field, cause I know it is but, at the same time it's a pretty good job to have, being a software developer. So you would I personally expect it to be very different, not necessarily like developers all being super excited about their job, but, seeing only one in five, like really engaged, another interesting aspect of this was that, their managers actually weren't, Even much happier because I think that number was a little bit closer to one in four managers are happy with their work. It seems like they're similar, but still a little different. Do you think there's anything to that?

Erin Yepis: 4:42

Yes, I do. So I think that, and as far as just to go back to your comment about the expectations, Gallup also put out a similar poll, not just for software developers. But a global poll on engagement at work, and it was also pretty low. So I definitely, the number seems believable to me. It is a little rough. I've seen a couple of Reddit threads where people go into. into depth of how they really feel about work and specifically about this, the staff from the developer survey. I was able to, I can tell you that I looked at, I wanted to look at the, the numbers in relation to salary. As a hypothesis might be that salary had something to do with job satisfaction. So I was able to see that expectedly salary is correlated with satisfaction across, globally, not just in the United States. But this relationship was. More or less strong in certain countries. when I looked at the top 10 countries that responded to the developer survey, I saw that most happy developers are definitely in above the 50, 50th percentile for salary. And, developers in the Netherlands in particular, regardless of whatever percentile salary they were in, their job satisfaction scores stayed consistent. So they were less swayed by higher or lower salaries. However, those developers that were in Brazil or France, were definitely more swayed by higher salaries. I also looked at, as far as countries and the effect of workplace setting, interestingly enough, Germany, India, and the UK, we saw their job satisfaction scores were more affected if they had, were in a lower salary percentile and also In person work setting. And then just going back to you, also your comment about the managers, the people managers, engineering managers, as far as the role goes, had some of the highest job satisfaction scores of all of the roles that we asked about in the survey. So regardless of their pay, their job satisfaction scores didn't really move that much. The same goes for non people managers. Data Engineers, Desktop Developers, and Embedded Developers. Their job satisfaction scores stayed pretty consistent regardless of their pay.

Ben Lloyd Pearson: 7:26

Interesting. There's almost like a anthropological study to be done here on the differences of all these cultures and how they view happiness and Within the microcosm of the software developer universe.

Erin Yepis: 7:39

Yeah, you've heard about, I think Germany takes their time off very seriously. I would expect the Netherlands does too. Also, the Netherlands, I'm sure when you go into the office, it's like a nice place. It's, maybe there's water nearby. And you brought your bike to work. Yeah, I think there's something there. www.

Ben Lloyd Pearson: 7:58

yeah. I definitely, my sense of working with a lot of companies in the Netherlands is that, they definitely are more like office centric, like everyone bikes into work to the same place. They, the, there's a lot of benefits that Dutch citizens get, so I think it does make a lot of sense And you mentioned that there, there aren't previous, this is the first time you've asked this question. So there aren't previous years to compare this to, but I wonder if there are any other, data points that you've measured in the past that we can maybe see if there is some sort of trend happening. Is this a post pandemic thing? Is it something that's always been consistent? Do you have any sort of indication like that?

Erin Yepis: 8:36

Definitely. The closest thing I have, like I mentioned, were the job surveys that we've done, for Stack Overflow. We have specifically the ones that we did in 2022 and 2023. We ask developers to tell us, of all of these facets of work, what are the most important ones to you? in both 2022 and 2023, flexibility, Ranked higher. It ranked absolutely the highest in 2023, over salary. So salary is up there. Salary has always been important. The flexibility was up there. And then rounding out the top three, learning opportunities always comes up pretty high too. So I definitely expected salary to be as anyone would salary makes a difference as far as if you're happy with your work, but because of COVID, I thought. The workplace setting and flexibility, being able to pick up your kids, taking time off if you're sick, that, that was more important too. So we can see in the developer survey that there are, it's a slight shift away from fully remote positions to hybrid positions, which we would expect. Not a big jump in person, work settings for developers, but we do know that there is a big difference. Year over year for salary globally. And I think that is our job survey results combined with what we see in the salary trends. Is what makes me think that's the biggest thing we have to compare.

Ben Lloyd Pearson: 10:09

Yeah, interesting. And I wonder if, COVID pandemic may have made that type of flexibility more commonplace. So now it's just assumed that it's a part of, opportunity, like new jobs a developer might take. To them that, may still be very important, but they just don't think about it versus salary, particularly given that, we are in a bit of an inflationary environment, does mimic some like macro trends in a way. Is there any other insights that you think that we're getting from this into why developer satisfaction might be so low?

Erin Yepis: 10:42

I think going back the roles, the salary percentiles and the country trends we saw among the happy and unhappy developers, We know that our, at least I was able to see that amongst engineering managers, like I said, who generally had a higher job satisfaction than any other role. And it wasn't swayed as much by salary or country, that they overwhelmingly indicate that compared to other job roles, that driving strategy is a factor in what they like about their job, which again, yeah, separately, With the job satisfaction question, we asked what factors contribute to your being satisfied at work. So overwhelmingly, we know that most developers, indicated that improving quality code was what they most found enjoyable about their work. But yeah, so driving strategy for those engineering managers. And then, they also indicated overwhelmingly that Being a power user was less important to them. So I think that, and then, so to go along that with those roles, embedded developers, they highly rate improving code quality higher than the average developer, I think the desktop developers also, they highly rate contributing to open source code. I think what that shows is that certain people get into the game for a reason. They find their niche. And then if they're able to really play around in that area, that thing that makes them happy, improving quality code, driving strategy, Oh, embedded developers. Also really liked working with high quality hardware. Makes sense, right? So we actually have numbers to go with that with something that intuitively makes sense. But there's some of these questions that, we don't get a chance to directly ask, especially to an audience this big, and now we have data to back that up.

Ben Lloyd Pearson: 12:42

Yeah, I like the insight about engineering leaders or the managers wanting to be more focused on driving strategy. And I think it actually makes a lot of sense why that would be such a big focus area right now. Because, you think about the last year. Again, coming out of the pandemic, we have all these companies that overhired that, we're building up business during low interest rates and low interest rate environment. And now they're. We're hearing this from company after company where engineering teams are either doing the same with less or being expected to do more with the same rather than increasing head count to hit their goals. And I think that's, that's, that makes it really difficult to drive strategy, like when you're in that kind of environment, because you're more focused on just keeping things operating rather than. Being strategic, getting a little more into these factors that contribute to job satisfaction. you broke down a lot of things by, like things that contribute to happy points, complacent points, unhappy points. So what are the major takeaways that you've seen from that section of the analysis?

Erin Yepis: 13:48

I think the improving quality code overall just came up as the top factor for job satisfaction. And. I definitely, that makes sense. And we love to see that. And again, so seeing that driving strategy actually made no difference to a lot of the developer roles. Makes sense. So there are people that kind of want to focus on improving quality code. I don't want to drive strategy. I want to do this thing. I like to see that. I like to see that difference amongst the different groups. What was the other thing too? I saw, because again, the Netherlands just kept coming up. The Netherlands. So regardless of your, of the salary or your job satisfaction score, again, very consistent. Netherlands developers highly rate, designing architecture and environments. Again, it makes sense. I think. There's definitely a bigger story here. It has something to do with why you decided that this is what you're going to do for a job. So there's so many different things to go dig into about that. I like the idea of using this data to explore reasons, why you're going to For the why rather than focusing on the overall number, like doom and gloom. This is terrible again, going back to some of those Reddit threads that I saw about these results, the one in five, there are some types of people that are like. They see that number and it's a confirmation bias. Of course, everything is terrible. Of course it's like this. But that's not the reason to ask about this and to quantify it. The reason to ask and quantify it is to find out why and to do something with that information.

Ben Lloyd Pearson: 15:32

Yeah, exactly. And I think the improving code quality, that comes up without like in our world a lot as well. And I think it's part of this challenge that, virtually every single engineering team has, like they want to do things like reduce tech debt, improve developer experience reduce like toil and maintenance and all of that. And, but the problem is there's the rest of the business that has all these priorities that are constantly. Pressuring the engineering organization to deliver on, it's like building new features, enhancing things, building stuff for new enterprise, large clients or whatever. And a lot of engineering leaders, I think actually struggle to push back against the rest of the business to say, we can dedicate, a certain percentage of our resources to solving. To building the stuff that the business needs, but we still need to have some portion of that dedicated to improving the things that make our developers lives better. And I think because that conversation is so difficult for engineering leaders to have sometimes that a lot of times things like code quality get deprioritized within the organization. So were there any surprises or things that you weren't expecting about the stuff that contributes to happiness?

Erin Yepis: 16:44

So I'll go back to the Salary correlation. I know salary is important from other research that we've done. Again, my mind was that in the space that developers, at least in 2023, valued flexibility more than salary. So I know that, yeah, inflation, economic headwinds. And then seeing the numbers that people were reporting for at least a 10K, if not more, USD decrease in annual salaries for all roles, most roles, I was thinking, At first, that maybe had more to do with developers because they prioritized that flexibility, that remote setting or hybrid setting that they were choosing to stay in those roles. But I think we saw with the job satisfaction and then just yeah, running that analysis on workplace setting and salary. Nope, salary is much more correlated. Workplace setting. So that was surprising to me. But again, after you think about it, it, does make sense.

Ben Lloyd Pearson: 18:00

Yeah. I want to take a moment just to talk about some of the frustrations, the common frustrations that you brought up as well. And I think we touched on this a little bit already, but, the top frustration that was surfaced in this is technical debt with, over 63 percent of respondents, saying that contributed to their frustration. So what are your findings around technical debt? Is there anything deeper into that, that you can share insights on?

Erin Yepis: 18:27

Yeah, this is a good one. I think my main finding, and to be very transparent, is that because it was so highly ranked amongst all the choices for frustrations, that my main finding is that tech debt is just too broad of a term to be using for it. That type of question. So that's fine. You live and you learn. I definitely expected there was going to be more parody amongst those frustrations because, is frustrating sometimes. Especially if your work is very complex. But tech debt, I think is too much of a buzzword at this point to actually mean anything, specific. So I think I, for the next developer survey, need to tease that out a little bit more to find out. Interestingly enough, we had a really great episode of, on the Stack Overflow podcast about tech debt mindset that came out after the Annual developer survey released. So I got to listen to that and it started making more sense. The phrase tech debt, technical debt is its own microcosm. And, it has to be, you have to be more specific. I know that now. So I think, yeah, I think the. to make that question better, the idea is going to be to reformat it to ask about causes of tech debt in the terms of frustrations at work instead of just blanket tech debt.

Ben Lloyd Pearson: 20:00

Yeah. So you're thinking like almost get more tactical. Is it outdated dependencies or lack of tests or something like that's contributing to it?

Erin Yepis: 20:09

Honestly, I'm going to have to do more research of what people consider That might be its own little mini survey. Like it's so complicated,

Ben Lloyd Pearson: 20:19

and I also loved, I feel like this always shows up, but I think like some of the top ranked stuff also included like frustration with build and Deployment Systems, which, I'm still here wondering why in 2024, haven't has no one figured out CICD, like we're still struggling with those things.

Erin Yepis: 20:37

I feel like I'm still figuring it out

Ben Lloyd Pearson: 20:39

Yeah. So yeah thank you for breaking all of that down for us. So let's start talking a little bit about what organizations can do with this information. If you have an engineering manager, director of engineering or any sort of engineering leader. Reading this survey, like what would you hope that they could take away from this to help improve developer satisfaction?

Erin Yepis: 21:00

I would start with, Read the developer survey, go visit our developer survey site. That's a great place to start. Knowing that this is the largest developer survey in the world and it's a global audience, so you're getting a lot of perspectives. But besides that, I think we saw salary is a real problem. That is, it's just correlated to that unhappiness score. I think that some of these things, again, like I mentioned before, seem intuitive, maybe a little obvious, but there's numbers to back it up now. Besides that, I think with the, as I mentioned before, with those, factors for job satisfaction, going back to. There is a connection between your role and the things that you do at work. So if this is, if you're a job, a people manager, an engineering manager, I think checking in on what it is that you like to do is always a good idea. Regardless of the numbers in this survey, but what we're seeing is with certain roles there is a relationship between so much for joining us. And

Ben Lloyd Pearson: 22:17

Awesome. And then to flip that, what about an individual contributor? Is there something from this that you think they could surface to their leadership?

Erin Yepis: 22:35

That most developers do not feel threatened by AI, that we had 70 percent of professional developers indicated they didn't believe AI was a threat to their job. So given that There is maybe some uncertainty with like job security or uncertainty with how roles are going to be affected in tech orgs. In any industry with AI, but if it's something you don't feel threatened about, then talking to your managers about how can we use this? How can I use this tool? How can I get ahead of, what these tools can bring, how they can improve? I want to be using them. If it's not a threat, then I think having direct conversations about it. Yeah.

Ben Lloyd Pearson: 23:26

Awesome. And I want to maybe pick your brain on, what's coming next year as much as we can. I, I think ways that I would love to to learn more about some of these insights you gained is, one of my favorite parts of the course. The developer survey is always the most loved versus like most wanted tools. I would love to see like correlations between that and like people who are happy with their job, are they using the tools that everyone wants? That's my idea, but do you have any, you mentioned breaking out tech data a little more, do you have any other plans for how you might be able to expand on this like professional developer portion of the survey for next year?

Erin Yepis: 24:05

And I do think that's a good idea. The one problem with that is there's so many technologies that we ask developers about. And so there's a lot of noise there, but I do like that. I think there is some way you've got my wheel spinning now, so I'm going to, I will take that back. And obviously that's our favorite part. of the developer survey to see, seeing the results of who's using what did they want to use? so I guess for next year, we go through this process, where we source. The technology selections that will show up on the dev survey. And so one of the differences, one of the new things we did this year we always go to, it's a combination of looking at some, our internal data sources. So we have tags on stackoverflow. com that we can see trends in. We have external data sources, such as GitHub and Google search to see What are some of the technologies that are out there that people are, that are popular in those spaces. And then we also ask our meta community for feedback. Hey, these are the technologies we're thinking about asking, our users this year. What do you guys think? And they always give great feedback. They love to correct spelling. First of all, that's always important. And, but this year, some of the feedback that they gave was, Hey, you have. A lot of, you're missing some of these embedded technologies, embedded developers. Accounted for 3 percent of the roles that we asked for this year, which is not a small number when you think about all of the roles that respond to the developer survey. So we, I went ahead and created a whole new technology subsection just for embedded tech. So I think there's possibility we could see more stuff like that. I think it just makes, it depends on some of the feedback, what we're seeing as far as like those data sources go. Like sometimes we have to take some of those technologies out of the list too. Hey, this has been slowly dropping out of people's. Usage and they don't love it. They're not using it. They don't want to use it. Hate to say it, my, one of my first languages, my most loved language is falling down that path as well. I hope that turns around, but it's not up to me. For the professional developer series, I think for questions, I think probably not too many changes just because we like to see that like history that, that linear. Time series of how these answers are progressing over the years. But we are definitely attuned to what is going on with AI? What is going on with changes in the workplace and how are those being reflected because we want to specifically ask those either new, newly professional or seasoned professionals. How is work going for you? What does work look like? So we'll see. I think it just, it remains to be determined what else is in store for us. What new progressive technological expansion is in knocking on the door of 2025.

Ben Lloyd Pearson: 27:23

I think in particular, there's a lot to be learned about the impact of AI on different types of developers. I think we, with a lot of the tools that are coming out, it's like we've like as a whole, just view it collectively as all developers are now using Copilot, so they must all have a similar experience with it. But I think we may be learning the reality is that like a senior developer has a very different experience with a tool like that than a junior developer. Yeah. And they both could potentially see massive improvements from it, but you may have to deploy it in a very different way depending on the person. So yeah, I think, yeah any, everyone's talking about AI for a good reason, but I think it is very relevant that we need to understand how it's going to change, not just the whole software development industry, but each individual role within the organization.

Erin Yepis: 28:10

Yeah. And also to go along with that, we have, we ask developers now, what part of their development process do they use if they use AI tools that they use it in. So we have tons of options, but similarly to this job frustration and tech debt being overwhelmingly the top one, developers indicate writing code as they're like. overwhelmingly top, way they use AI tools. And I do think that maybe needs to be broken out a little bit too, because it's just a little too broad and, exactly going back to what you're saying with, Junior and senior developers. They're writing code, but very different.

Ben Lloyd Pearson: 28:54

it's this has all been wonderful, Erin, and thank you so much for joining me today. And again, we'll have the survey link in the show notes for all of our listeners. And there's tons of information that we didn't even get to touch on today that I think you'll You know, plenty for people to learn from within there. So I definitely encourage our audience to go check it out for yourself. So Erin, if people want to follow you to learn more about what you're working on, where should they go?

Erin Yepis: 29:19

Yes. Thank you for asking. I would say please check out the Stack Overflow blog because I post my analyses there. We are currently working on a survey for our community members about Knowledge in online communities. So that analysis should be coming up soon. And depending on when this podcast is released, the survey may still be open. If anyone wants to contribute, that would be

Ben Lloyd Pearson: 29:45

Wonderful. Stick around after the break LinearB co-founder of Dan Lines will be joining me to discuss today's episode. Did you know that PR size is the single most significant driver of engineering velocity. Or that automating the toil of project management hygiene correlates directly with faster cycle times. I didn't either until I got my hands on the 20, 25 engineering benchmarks report from LinearB. This report is the most expansive. Study on quantitative data from more than 6 million poll requests at. 3000 organizations worldwide. You Can have this report sent to your email inbox right now. All you. I have to do is go to LinearB. Dot IO. Click the link in the black banner at. The top of the page and sign up for one of the two round table discussions. We're hosting. On Wednesday and Thursday this week, November 20th and 21st. It takes about 10 seconds. In fact, you have time to do it before the end of this. In this round table discussion, you shy. Barry LinearB CTO will host. Rob Hubler CTO at circle CEI. And Tara Hernandez, of developer productivity at Mongo DB. This phenomenal trio. Leo, we'll dive deep into this year's updates. Key findings from the research. And some brand new additions to the benchmark lineup. I'll give you a hint. It has something to. Do with one of the questions I asked at the start of this segment. Yo this round table discussion. And you certainly don't want to pass up the opportunity to get the 2025. Engineering benchmarks report from LinearB. You can have it right now. Head over to LinearB. Dot IO or use the link in the show notes. So Dan, first of all, I just want to get your reaction to this top line number that only 20 percent of developers are happy at work. And so for a context Erin mentions that this number represents professional developers who selected either a nine or a 10 on a 10 point scale. Further 32 percent of developers also indicated they're unhappy at work. An almost majority, about 48 percent are just basically complacent at work. So Dan, why are only 20 percent of developers happy at work?

Dan Lines: 31:53

Yeah, Ben, first off, man, when I saw this, that's like a pretty sad number. 20%. I don't know, I saw what you and Erin were discussing. I think you had the same reaction. That feels low and sad to me. Then I started thinking, okay, maybe, What percentage of people are on the entire planet are happy at work? I don't know, maybe it's 20%. But if we're saying, specifically for developers, I think about a few things when it goes back to the experience and that type of stuff. First of all, I remember when I was a developer, you probably remember the same. You gotta be working on an interesting problem. That's like the fir first thing about being a developer, like I wanna work on something interesting. Now, what is interesting? It could be I'm using a cool latest technology. Like maybe that's interesting, but not many developers get to do that. But it also could be like the product itself. I don't know, maybe back in the day, being in the original 30 people at Microsoft, like that was cool. Like working on an operating system. Then I started thinking to myself, okay, it's only 20%, which is a really low number. And that LinearB, we talk about this all the time. Almost every company now is a software company, which means there's more developers on the planet, but there also means, like I was thinking about this, maybe there's not as many interesting opportunities. I don't know if I want to work on an app for Oreos or like Pepsi, you know how everything has an app now? Like maybe that's not that interesting and back in the day, maybe there was less companies They were more tech like really tech companies. I gave like a Microsoft example There's a ton of others, but maybe that could be the reason so that was like the first thing that went to my mind Like am I working on something interesting? Now the second thing that came to my mind when I saw this low number, and we see this from the LinearB data, like the amount of friction standing in between the developer and executing work, like that directly either is positive for a developer or negative for a developer. If it's hard to get my work done, if it takes a long time to get through a PR process, if my coding time is way too long, if my build is way too long, I mean there's a ton of things that go into these friction, I'll just call them like friction producers. And we see, especially with a lot of large organizations that are employing like 5, 000 to 20, 000 developers, like it's pretty rough, like the cycle time. So I think that probably has a big impact on it. I think they talked a lot about like systems that are more complicated now, but I think at the end of the day, it's like friction to get my work done, the LinearB data. I would say supports that we have a lot to do as an industry to improve that. So that's the second thing that came to my mind of that low 20 percent number. And then the third thing, think about like for anyone, I don't think it's just for developers, but I remember developers saying this the most, like your boss or manager, like your team leader. Matters a lot, whether you have a good one or a not so good one, that's really going to impact your experience. And the way that I think about like team leaders and managers, they're like a conduit to the business. They're a conduit to what the business cares about, the business value, are you connected to your work? and they're also a conduit to career growth. And what I would say is there's a lot of team leaders out there. There's a lot of young or new team leaders out there. Maybe new is a better term. And it's hard to have a good manager. Like some of these team leaders honestly have a lot of work to do. It's probably like their first year they're managing eight people. And when I think about things on the team leader side, like think about career growth, am I being evaluated in a fair and data driven way for increasing my competition? Or is it more about who can advocate for themselves the best as a developer? Sometimes that's really hard to do. Then I think about, okay, what are the ceremonies that I'm going through? My daily stand up, the iteration retro, are we actually improving? Are these good ceremonies? Then I think about, are we hitting our iterations on time? Can I understand, am I getting pulled off for production issues? Is my team leader advocating for me? No, Dan needs to stay focused, and So all of that comes into play, and I can just say from the LinearB perspective, Perspective, like I see the team leaders are the area of like management that will affect developers the most But I think it's one of the hardest jobs and they need a lot of help to be better

Ben Lloyd Pearson: 36:34

at a high level, I think what you're describing, it's we talk a lot about how, engineering leaders today, like one of the biggest challenges they face is balancing like this business objectives with operational excellence. And it's at all levels, you want as an organization to know, When you can push back against those business objective side of things to focus more on the things that like your developers care about, it's probably one of the most difficult aspects of this job,

Dan Lines: 36:59

and you got to advocate you got to come with data you got to advocate and then you got to have a solution, right? That's what makes it really hard

Ben Lloyd Pearson: 37:06

Talking about the things that make it hard, technical debt was by far the largest source of frustration. There was over 62 percent of respondents mentioned that. And it was far above the next two things, which were complexity around the build and deploy infrastructure. And we won't get into my theories about how those two things always show up in these surveys. Erin said the one improvement that she wants to make next year, is to break this category of technical debt down into more specific categories, to give more of like a granular understanding of it. So what do you think about. Specifically about this high level of frustration with technical debt. What do you think it means and how do you think something like this should be broken down?

Dan Lines: 37:51

Okay, yeah, so first of all, this one I'm not surprised. I was surprised by only 20 percent of developers are happy. I'm not surprised that one of the biggest complaints is technical debt. I think that's been since the beginning of time. I think that's what the data shows, like on the LinearB side. Not a lot of companies are, let's say, Properly advocating or allocating enough space to reduce technical debt. So all of that makes sense to me. Now, what I will say is when I look at this list, There's a bunch of items on here that I think could also, cause I think the top one actually says amount of technical debt. So 62 percent for amount of technical debt, but the other ones on here are either technical debt influenced or actually technical debt themselves. So if you're looking at things like the CICD complexity, platform reliability, like always usually is like a technical debt problem, dependency management, like security stuff, quality concerns, most of that come comes back to technical debt. Now I will say two things on this and actually I guess I'll relay it back to my first point. What I'm seeing is Every company is a software company now, in some way, shape, or form. Most, let's say. And because of that, and I think this is different from earlier on, maybe 20, 30 years ago. The software that developers are producing now are, is directly driving revenue for companies. So I'll say it again. Think about a bank. Think about like Charles Schwab. Probably back in the day, you go up to the bank teller and you do whatever you do. Give me my money. Or whatever you would say to a bank teller. Here's a check. I don't know. I've never gone to a bank teller. What you do now is you log in right and you manage your bank account online. That's all software. So even a bank is actually like a software company. Now because software is driving revenue forward, I think there's a lot of pressure on developers and on engineering organizations more and more to deliver more features, deliver them on time. Now, if you're always under pressure to deliver more features on time, what happens? Your technical debt is going to build. So I think the world's at a conflict right now as more companies are using software to drive revenues, even companies like you wouldn't think are software companies. I think technical debt takes a hit. so here's some like other stuff that I can see. How is this important or what is the most important point? It's that you need to understand how does this technical debt influence revenue? I think that's the best thing. If you're a manager to be able to explain that, how does technical debt influence revenue? You use a tool like LinearB or other tools out there that you can actually say, look, here's all the bugs coming into our system. Here's all the incidents that we found in production. Now look at our on time software delivery. It's suffering. our planning accuracy is really low. I can show that coming in, all these bugs, our developers are forced to go deal with, code quality issues in prod, and therefore projects aren't delivered on time, and this is our number one issue. Generating a revenue project. I'd like to talk about it with the business so we can do it more. I think that's like the change that the industry needs to make. And the other thing is like the point that I just opened up with where it was like, do you know how much time you are allocating to take down that technical debt? Is it 5%? Is it 10%? Is it proper? Like 15 to 20%? And if you can show and visualize that we do that with our profitable engineering module, when you show that to someone on the business side, they light up, Oh, I get it. These aren't dumb people. They understand now that the software matters. So you've got to make sure that you're allocating time to take it down. Overall, Ben, this one makes total sense to me. I think it's more about how we fix it now.

Ben Lloyd Pearson: 41:46

So before I let you go, I just want to ask is there anything else in the stack overflow developer survey that you would love to see like them explore more deeply next year?

Dan Lines: 41:57

I'll start with your idea, Ben. I think you already talked about it. Everyone wants to see technologies, most technologies used, tools used. I think with AI also, there's so many companies and startups there. It'd be interesting to get some opinions on, which ones Are pleasant to work with, which ones aren't working, all of that.

Ben Lloyd Pearson: 42:15

And do they actually make you happier at work, for

Dan Lines: 42:17

Do they make you happier? But, and where I'm more interested is, do they drive productivity? With LinearB, we're all about productivity. I want to see, developers that are happy because they're productive. And I think it's important because if you do a developer survey and you're looking at developer happiness, and you're looking at developer experience, if you Asked probably the ones that are like in that 20 percent happiness. They probably feel good about getting their work done. They're productive. They feel like feeling productive is a good experience for most people. So I'd like to see them build out that developer productivity section, more stuff on what are the friction impactors or what, what do you need to be more productive? think if they build that out, that's actually the way to increase the happiness. What do we need to do with automations? There's a lot of agentic bot stuff going on. That's what I focus on, like the productivity side.

Ben Lloyd Pearson: 43:12

Thank you for joining us today, Dan.

Dan Lines: 43:14

Yeah, man. Thanks for having me.

Ben Lloyd Pearson: 43:16

And that's it for today's show. We hope you enjoyed it. If you're looking for more insight from engineering leaders, head over to the Dev Interrupted sub stack for weekly articles and deep dives on our favorite episodes. And don't forget to subscribe to our YouTube channel. We put all of our favorite moments from episode. We love to hear from our audience, so find us on Twitter or on LinkedIn at Dev Interrupted. Or leave a comment directly in the Spotify app and let us know what you think of this week's episode. We'll see you next week.