Developer Productivity Will Decline in 2025 | Predictions from LinearB’s Ori Keren

0:07Hey, everyone. I'm your host, Ben Lloyd Pearson. And today I am delighted to be joined by Ori Karin, co-founder and CEO at Linear B. Thanks for joining us today, Ori. Hi, Ben. It's great to be here. Thanks for having me. Ori, as always, it's really great to have you on our show. And Andrew, I want to welcome you to your first ever episode of Dev Interrupted. Thank you, Ben. I'm really excited to be here. We've actually dedicated some time next week to introduce yourself to our audience. So definitely want everyone to tune in next week to wrap up our season with us and get to learn about who Andrew is and what role he's going to play.

0:42And Dev interrupted moving forward. But today I want to focus on what we've come here to talk to Ori about, and that is predictions for the year 2025. We're rapidly approaching the end of the year. And, you know, as we reflect back on all the things that have happened here in 2024, or figured this would be a good time to start thinking about what we think software engineering is going to look like in 2025. So just at a high level, Ori, like tell us, what do you think are some of the biggest trends that you see shaping software engineering in 2025? Yeah, sure. So I'm going to surprise you and start with AI, which I think is like the biggest trend that everybody's trying to wrap their head around how will it look.

1:26I think in two kind of separate tracks, there's one where, you know, all the IDEs and the place where you get assistance, where it's not still like agentic, it's not an agent. I think these technologies will mature. We can speak later on like who's more benefiting from them and like has a better match to utilize them. but you know as we spoke to leaders this year it was hard for them still to quantify they get productivity gain from this and what is it exactly and it seems like it's in early adoption i predicted 2025 these technologies will mature and and and it will become more ingrained into like the day-to-day of a lot of the developers by the way i think mainly junior developers but not only and then you have the other side of all the agentic AI and AI agents that can pop in and take a Jira ticket and issue a pull request based on Jira ticket.

2:25I think this it's almost like in phase before. This will be experimentation year for these type of things. There's a lot of like obstacles still like to overcome in order to embed this thing. So my prediction is that it's going to be an interesting year with AI agents in SDLC, but it's still be more of experimentation this year. Yeah, you know, honestly, I don't think we can get through an episode anymore without talking about AI because I mean, it truly is like dramatically changing everything we know about how, you know, and it's not just software developers that are feeling this impact. I feel like it's all people who do informational work.

3:03You know, we're all being impacted by this. Just like software developers seem to be one of the first big waves that it's really becoming mainstream and taking off. that's probably going to have a big impact on engineering organizations in this next year. Do you think today is when they're going to start seeing like those huge impacts, or do you still think there are other tools out there that engineering teams should be looking to adopt over the next year? You're asking if there are more technologies and more trends that will be like impactful in 2025 or are you still talking specifically about AI?

3:36Like what tools are going to have the biggest impact over the next year? Is it AI or is it going to be AI's impact on the other tools they use? Or are there still other tools out there that we should be thinking about so that we're not completely focused on this one? There's other things that are going to happen, other predictions that I have, like, you know, in other areas. But just to put AI, like, to bed for a second, I think it's about how you integrate this thing into your existing tool chain. Everybody talks about, hey, will it repeat? What it will replace? What it won't replace? I think it will still take time to understand how do you orchestrate all of this?

4:09How do you embed these technologies? When do you apply the human resource? When are you letting agents go and do their thing? So in terms of affecting the toolchain, I think it's more about how you combine and how they live side by side. Some other interesting things that I think are going to happen in 2025 or some other trends that are relevant. And like, well, I'm not going to surprise anybody, but cybersecurity is still going to be something huge. I think you can see it from the macro level, like the world is shaking from any angle that you look at it. So it just raises more cyber threats. And so cybersecurity definitely going to still play a major role in everything companies do.

4:55The two that I'm really excited about are developer productivity and developer experience. and what do we do in these areas? But I don't know, I'll let you lead and when do you want to talk about these topics? Yeah, those are definitely some topics that we want to dive into. And I love the cybersecurity example because when I was getting into the profession, I remember script kitties used to be like a term that was used almost in a derogatory way to people that would copy scripts off the internet and use them to maliciously attack organizations. But now, I mean, you could theoretically have like AIs that teach you how to build this stuff, you know, kind of does illustrate, I think, pretty well the impacts that these tools are going to have like across the space.

5:40How do you think all of this is going to impact the role of software engineer in 2025? So I think, you know, historically, you think about a software engineer, there's somebody who is responsible for building things and coming up with novel and creative solutions to very concrete examples how is that going to change as generative ai changes the ecosystem it's really interesting because i remember when i was like a young developer there's this park of ideas that you have that is sometimes coming top down hey i have an idea and i'm going to work on it i'm going to implement it you start somewhere you write something and then ideas you know come to your head as creative ideas as you oh i build this this probably means i can build something that does this thing and I can build an entire application.

6:28I have concerns that, you know, how with like when iPhones were introduced and we saved all our contacts, we just forgot all the phone numbers and then navigation systems, they were introduced. And then a lot of people just can't navigate if they don't have like Google Maps or Waze or something. I think it's very important for developers to not be fully dependent on these codices, et cetera. They're very important to increase the productivity, but people still should learn languages through an entire potential so we don't lose this big big creativity spark that we that we have so this is like a first comment that i have like uh regarding the roles i think it's more maybe on leaders or the industry to think how do we preserve this creativity that's again sometimes it's a fire that clicks from like bottom up but when i think about the roles of like developers and how the roles of developers will change i kind of like divide it into two i think junior developers that will know how to utilize this like you know ide boosters whether you use copilot cursor whatever you use like there's going to be a gap each you know how to use it it will increase your your productivity dramatically and if you don't know how to use it You're just going to stay behind.

7:46That's kind of what I think about, you know, people who are starting, you know, the first, you know, two, three years in development. I think the senior developers are very interesting because these folks, if they are able to leverage the entire potential that AI has to offer here, they could become small teams. because they could say something like, okay, I'm going to deploy my energy only on these specific reviews. I'm going to have one agent that does basic code reviews. I'm going to have one that just sits and looks for, I don't know, what's wrong with my development pipeline. What's broken?

8:28Where do I have maybe flaky tests that I can come in and fix? Where do I have long build times? And people that can leverage this technology, they can become almost like full teams with a lot of potential. So again, I started and I said, it's still going to take time because I think these technologies are in experimentation. But that's the direction that I think the industry will go. You're highlighting a really prevalent thing that we've seen a lot and the difference between how junior developers versus senior developers are leveraging these tools. You think about a junior developer, they may see efficiency gains from like adding endpoints to like a standardized API, right?

9:10Like something that's repeatable and just takes like a little bit of, for lack of a better term, intelligence to figure out how to replicate it. Versus like a senior engineer, like they seem to benefit more when you have the ability to like ask, have like a conversational interface into a complex code base because then they can decipher things that are maybe outside of their expertise a lot more rapidly, you know? Yeah, so so far we've covered topics that I know are top of mind for a lot of engineering leaders, for a lot of people that work in software. Things like how AI will impact their work and how it could change their role.

9:44And cybersecurity is a topic that we're going to continue talking more about. But I'm curious, what is maybe a challenge that you think engineering leaders are underestimating or not noticing going into next year? The first one is maybe one I spoke about. How do you maintain like this creativity, spark and ability to build innovative products and innovative ideas again sometimes they come top down but a lot of the times like the best companies in the world were started by developers started with the ideas that people set and like teach stuff with their hands and then the ideas like propagate from there so i think people need to leaders need to maintain it i think there's two other aspects of a small trend that I see that there's convergence of technologies and they're becoming more homogeneous, if it makes sense.

10:38And then in the side, you got to maintain like a diverse like skill set. There's languages that people paying less attention and all of a sudden they're saying things are ramping up again. It's not always easy like to find your next job. but there are languages that I know that people are looking and it's hard to find talent there. So I think as leaders need to pay attention that they still have well diverse skills in their teams, etc. The last thing is like humans. Don't forget you're working with people. So easy to forget like this framework. When I was an engineering leader and I spoke to my managers they say like all those things like people process product and people is like We're working with people, you got to pay attention that they're in a risk of a burnout.

11:28What are you asking them to do? They're feeling threatened right now, by the way, by technology, there's a resistance. So if this role, by the way, I think engineering leader is the toughest role that exists out there. I was an engineering leader. I once said that being an engineering leader is harder than being a CEO. Still think about it, if it's still right every now and then, but it is a very hard role. So I think those are like the things that leaders have to pay attention to. We've been hearing things about like, we have a round of layoffs that happened at a lot of organizations early this year.

12:04There's been a return to office mandates like all over the place. There's a general sense, I think, in the engineering space that it's hard to know where professional growth, like how does that happen? And, you know, so it really does feel like there's a lot of things that are putting like a downward pressure on DevX. And I think that leads into like really the core of what we wanted to ask you about today. And that's, you know, really developer experience and how it connects to overall developer productivity, which I know you have some issues with that phrase that we'll get into a little bit.

12:36But in terms of developer experience, so DevX, so what are some emerging tools or practices that you're seeing out there in the engineering space that gets you excited? The term that I have a challenge is developer productivity. We'll get to it later, hopefully. But developer experience is really interesting. I think it's kind of, you know, it reached like this interesting crossroad right now because I think two challenges. First of all, it has like a passive part of what do you measure? It's a lot about what do you measure? And also there's even arguments of how do you measure? First of all, I think it's time for developer experience to move from in the how do you measure?

13:19And then we'll talk about active part. How do you measure to move from just relying on these like almost semi-academic research surveys and to get them to the next level where it's a combination of measuring qualitative and quantitative things. Because, and in qualitative, I think it has to be much more embedded into the day-to-day of developers. Again, it's really hard. I remember myself as a developer to sit and answer this, again, almost semi-academic thing that asks me now questions. But ask me one second after I just completed my task about what was my problem, et cetera. And you'll get a lot of insight.

14:02So I think developer experience has to solve this measure problem and to get to an understanding that you've got to measure these qualitative things, but combine them with quantitative things. There are things you should be measuring. You should be measuring your build times. You should be measuring your stability of your CI and how much, you know, deterministic it is. Like the most irritating thing as a developer is like you run a test, it fails, you run it again with the same condition and it succeeds. Now you know, okay, next time you won't trust your test suite. So fixing those type of things, measuring how much you have them, test environments, adoption of like AI tools and the impact of them.

14:47So again, I was starting with the measure part. I think we got to jump to the next level where you combine qual and quant. and then I think the biggest challenge and the biggest and the biggest potential of like innovation and and things like to develop in developer experience is okay now that we got to some concerns on what we should be measuring and how there's a huge opportunity to fix these things and there's always thirst like to platforms that you know fix these things for me and it's not that complex I think all the problems all the challenge all the things that we just mentioned like again if i see if the build time is too long we can again deploy very interesting technologies now like to shorten them yeah uh if my tests are not stable we can deploy agents like to fix this bug so i think like um what what excites me i think there are good frameworks inside the developer experience there is sci the sci space software engineering intelligence there's IDPs, there's surveys, there's all these avenues that you can get the understanding about developer experience.

16:01We believe and I believe in not just showing you where the problem is, giving you tools to actually go and solve these problems. And I think that's like the leap that the developer experience movement will probably make this year. Yeah, the core of a lot of this problem is a lot of engineering organizations have this constant struggle to like justify investing in developer experience. You know, you've got this business that's always asking to like produce new features and help us close deals and all that stuff. But, you know, developers want to make their lives easier. And, you know, I think some organizations are starting to get pretty good at articulating why we need to push back against business priorities sometimes to invest in developer experience.

16:45And I think this segues nicely into a question that you have, Andrew, about an issue that we're starting to see relatively frequently. We hear a lot when we talk with folks about developer burnout and the experience that they have within their platforms, within working every day, creating the software they do. And something we hear consistently is that it's more about, we're wondering, you know, is it about like the workload or is it about the way the developer's time is spent? And oftentimes you hear anecdotes about particularly frustrating things for them that are specific and maybe like you're referring to are solvable.

17:23And so how do you think leaders can address that imbalance for that experience for them? I think you're touching a good point, like there are people all the time. Again, it's this triangle of like, how do I make sure that I have the right people and I keep them happy and I keep them productive? How do I have the right process in place? And how do I make sure like I'm creating the right product. That's like, I think for engineering leaders to burn out. A lot of time it will be like kind of like together, unfortunately. Like somebody will tell you, hey, I'm like a burning out. And probably, probably they're working too much.

17:59And probably the reasons that they're working too much is because executing simple tasks is not easy for them because they're waiting for an environment to come up or they're waiting for the CI to complete and then after one hour it failed and they're like oh I need to wait again we've all been there yeah and there and so it's almost like there's a strong connection between those unfortunately that comes together because you asked if it's like more the time spent or the workload unfortunately um it comes together and then people and it's like a bad snowball effect Right. Because we talked about before, like companies need to test more in developer experience.

18:42It's hard for them sometimes to see that it will bring better productivity. So to your question, I always think it's a combination of the both. Like you have committed people, they want to complete their tasks, but it's taking very much. Then they're working, they're just compensating on it with like a lot of hours, and it's like a vicious cycle.

19:11Pardon the interruption, but did you know tomorrow's the big day? On December 11th, Dev Interrupted is taking over the Melody in San Francisco, an evening crafted by us for engineering leaders just like you. We're hosting top minds at CircleCI, MongoDB, Syngenta, and LinearB as they tackle the challenges keeping teams up at night. Quite literally, scaling and driving impact at the enterprise level. Check out the registration link in the show notes and grab your spot before they're gone. We'll see you tomorrow, December 11th at The Melody.

19:47Before we get into our central topic on productivity, I want to ask you about the concept of balancing developer freedoms with more of a standardization and compliance sort of posture. because I think this also plays a big role in developer experience, you know, because you can think about, like, let's just use generative AI as a good example of this. Organizations who are providing more freedom to developers may be seeing more experimentation and new use cases emerging. However, the organizations who actually approach it in a much more structured and standardized, like, rollout approach are actually, like, leveraging bigger benefits from it because everyone sort of understands specific to their organization, like how generative AI can impact it.

20:33You know, when we think about like this balance of freedom versus standardization, like how do you think companies should be like focused on that over the next year? I think companies need to define their philosophy. First of all, like think about it, dedicate time to thinking about it, come up with a strategy and your philosophy and the things that you believe in. When I was a young manager, I always like, I always wanted to like think about how do, you know, after you do the first mistake and you fix a problem for your developers instead of letting them like to learn on their own. So it's the same with the raising kids, you gotta them fall.

21:12So, uh, you gotta choose where you focus on. So I think one of the recommendations I have, I think we touched on it, but all these changes will bring a lot of like compliance requirements. I like to do the analogy to like autonomous cars, maybe the technology there, but there's a lot of the regulations that are not solved. Here where it's like software, I think the technology will come too fast and you'll have to have some orchestration and compliance around what do I allow and what do I don't allow. And then companies have to have like a strategy and a philosophy on okay in these areas, It's okay that we use different technologies and we try different things.

21:56But I don't know, when things go through the development pipeline, at the end of the day, we got to meet some compliance requirements. We got to go through SOC 2 or whatever, like our processes. Then it's okay to have more uniformity in those areas. These are the checks that are being done. This is technology that we're using. to take 10. I think it creates a good balance where like things are moving through the pipeline in CI, CD, et cetera. It's okay to have standardization and rules. And there are some languages that even let you run, write rules and program your pipeline. We know some of them, some great products to do that.

22:34And then over a day, IDEs and, you know, while I'm building my code, etc i would still allow like for uh or freedom because again there's less implications uh then goes for like when you deploy stuff and you at the end of the day you kind of you gotta have uniformity but choose the areas where you allow some innovation and try new new things where it's less risky going back to the example of where to follow when i was a young leader if i saw like a hey a big mistake and they're going to impact us dramatically i wouldn't let it happen this is one out of ten nine out of ten let the mistake happen it's fine like this is how people learn and how they improve yeah i'm pretty sure my kids school calls that a natural consequences for living with natural consequences yeah it's actually a great learning technique let's get into the topic of productivity now or developer productivity or software engineering productivity this is this This is kind of a loaded term because, you know, I think a lot of organizations realize they need to focus on it.

23:42But it also is a term that kind of feels like you're going to start spying on your developers and potentially firing them if they don't have the right numbers. Given that, like what are the big challenges that you think that engineering teams are facing now relative to the concept of developer productivity? Yeah, I would start with just adding something again, like to what you said. It's a loaded term because I think I spoke about it before, but it's like, I don't like, well, it is what it is. This is the term. It's here to stay. But if you do an analogy to sales, for example, and people use sales efficiency.

24:18So two things, like they use the word efficiency and sales is like the action that you do. It's not like the people who do it. So it's about how do we improve the process of sales? and unfortunately here not only we didn't choose the action we choose people and instead of choosing plural because i think development is team sports like you work together everybody does we choose in this term and i say we like the people chose this term single developer so it's kind of a loaded term because when you say developer property oh what do you mean this is the thing that you measure the developers and you stack rank them no so this is why i think people need to see beyond the term, the time developer productivity to me represents how do you increase the efficiency of the development process.

25:06So that's why, again, if we could turn back time and invent a different term, great, but we can't, and it's here to stay with us. I think what the theme that I'm seeing in developer productivity that is really interesting is all these contrasts. I think you spoke about it, like all this, on one hand, you have, hey, we got to apply AI because everybody's talking about the big, big, big promise that it brings. On the other hand, it's like, how do we put controls on it? And how do we not forget about our people and like apply the human factors? That's a big challenge for developer productivity. you talked about you know these two movements of like working hybrid and going back to work from the offices still again two big big contrasts and strong if the world didn't have enough polarity they're bringing us to develop a productivity as well oh five days at the office no hybrid and again like we talked about like your question about uniformity of like hey we're using the same tech stack for everybody that's what we do there's a lot of developer experience team that way we're doing centralized tooling and purchasing like for the entire organization versus like the freedom to choose so i think the biggest challenge the theme is this contrast and i do balance all these contrasts that's i think the biggest challenge of developer productivity and because you have all of that I think you don't have any other leaders, don't have any other choice, but to decide what is important to them and measure it.

26:50Measure it so they can optimize it and they can start improving it. And you don't have to attack all the problems at once, but measure the things that are important to you. Again, like we said, define your philosophy, your strategy. Where are you in all these contrasts? What is your choice? Because not choosing is the worst. like what is your approach in all of this? Then make sure you're measuring like the right things to improve the productivity and also choose frameworks that not just let you look at them and what you measure, but also give you means like to drive improvement with a developer productivity.

27:25So I hope it makes sense. I really like how you framed the discussion as being polarizing. And oftentimes when you go down the list of things that we use to define developer productivity, They're divided into two camps that people find themselves in the whole way down the rubric. And you touched earlier on the human factor of working with other people and communicating. Do you think that that is the real secret sauce here to developer productivity? Is it about finding that common ground between these camps and understanding the shared goals that you have? And how would you recommend someone in either one of those camps, maybe it's someone who's more IC oriented or someone more manager oriented, how would you give them advice to try to find a common perspective?

28:15I think leaders have been living this reality for a long time. Like engineering leaders have seen this almost parallel universe. We call it sometimes the dual Monday for years now. You have like, you turn left and you speak to your engineering organization and it's one language of how do we, I don't know, decrease the time like that we deploy to production, deploy more times. It's, uh, what do we need to improve? Like how do we improve the developer experience, our development pipeline? Like where are we in the cloud, you know, cloud native development, like Kubernetes adopted all fascinating topics.

28:52Then you turn to the other side and you speak to the business and they don't, it's like changing. They have no idea. They have no idea what they need. It's like, yeah. any of it is so i think for leaders for a long time they had to do this trick or connect the dots to it i always like to say hey put some key metrics like some key business metrics and just draw a line between them so uh the business understand but it's an art you gotta be great at this like so i think same goes here it's like at the end of the day that's the human charm like good leaders it doesn't have to be like engineering there's good team leaders tech leads good developers can can bridge between like these these can't find like the path of like what do we take from this even if you look at like i don't know a hybrid versus going back to office maybe there's a middle ground here maybe you work two days from office i'll just throw in an idea yeah i think that's the that's the key another question i had this is related to my own experience, you know, I onboarded for a new role recently.

30:00And something that was really fascinating for me was onboarding and kind of like in the middle of the AI transformation of a lot of tools people are using. That actually helped expedite a lot of things for me. I had almost like a personalized assistant that I could ask questions to for lots of different resources and tools that I was added to. It was quick to jump in on context of things that was going on around me. And I'm wondering now, having gone through that experience and learned at a more rapid pace, maybe what's some advice that you would give to somebody who's maybe finding themselves in like a newly promoted or newly hired like engineering leadership role?