Now is the time to rethink engineering productivity

0:05Welcome to Dev Interrupted. I'm your host, Andrew Ziegler. And I'm your host, Ben Lloyd Pearson.

0:39AI is changing everything. It's changed the Linear B brand too. No, I joke. We've been using the same designs for quite a while. And I imagine long-time listeners and Substack subscribers out there have probably noticed, like you mentioned, the new icon. We've got a new color scheme on our Substack. Just a whole bunch of updated visuals for everything that we publish. But don't worry. This is mostly a visual refresh. We just felt it was time to give a facelift to Dev Interrupted and just make it a little sharper a little more 2025 i guess for lack of a better way to describe it i'm not a designer yes no we we did we did not design it we entrusted it to the skills of a talented designer who made it and we're excited it has a lot of black and white themes and actually i just realized today i'm totally twinning with our new branding because i'm wearing black and white so definitely check it out and listen what you think yeah yeah and absolutely and you actually don't want me designing this either because it would be the absolute worst designs but you know we talk about engineering news.

1:39We don't design podcast-free brands. Yeah. But I want to point out that, you know, Dev Interrupted, Linear B, we have this very close relationship. You know, Linear B has like this wealth of data and research within the organization that we love tapping into. Whereas on the others, on the Dev Interrupted side, we have this incredible community of engineering leaders. And, you know, what we're really trying to do, like sort of behind the scenes, you know, as this visual refresh is happening, is really to leverage both sides of that equation a little bit better. So be on the lookout for new types of content from us, from deeper content that gets really deep into research and into the opinions of our experts.

2:16You know, I think a really great example of this, and we'll mention this a little bit later, but we've got this really cool workshop coming out tomorrow about how organizations are moving beyond co-pilot style AI tools to do more AI driven software development. We've got some incredible research from Linear B, but then also some really fantastic past guests from Dev Interrupted that are going to join us to share their expertise on it. So, you know, moving forward, the brand is updated. We're still going to be the same. The content is mostly going to follow the same structure we've always followed.

2:48But just keep an eye out for additional new content opportunities, new research and new types of material coming out of us. So there is a little bit of changing on the back end, but for now, it's mostly just a visual refresh. And we hope you all like it. Let us know what you think on LinkedIn. Yeah. And with that out of the way, let's move on to some of this week's industry news because we have a really cool roundup of some interesting topics people were talking about this week in software engineering. One of them is a recent agentic AI primer doc that dropped from an expert in the field who we've also covered in the past.

3:19We have an update on how he's thinking about agentic coding. We have an article about why pen and paper is still a developer's best friend. And to round things out, we're looking at some of the modern forms that shadow IT is taking. So Ben, what do you want to dive into first? Well, it's a little refreshing to have AI content being in the minority this week, because that has happened in quite a while. So maybe we just get that out of the way. Let's start there. Okay, well then let's dive into this really cool article from Pete Hodgson about why your AI coding assistant keeps doing things wrong and ultimately how to fix it.

3:52This is a primer that outlines some of the type of tasks that folks are using agentic tools in the coding environment to work on software, right? And using an LLM in your IDE can take a lot of different forms. And the questions that you can ask it really vary depending on your own expertise level and what you're trying to accomplish and how complex your code base is. So this article, it offers a nuanced perspective on some of the more polarized discussions around using AI-assisted coding in this way. Is it good? Is it bad? And ultimately, what it boils down to is it's good at certain things and it's bad at other things.

4:28You know, this is asking your LLM to spell strawberry all over again. It's important that you're using your tools in a way that they're best set up to give you success. So he introduced this idea called a constraint content context matrix categorizes tasks on axes. If you've been following our content, we love mapping things out on graphs and axes in terms of adoption. So we're going to include some links on this coverage. I myself been talking a bit with Pete. We'd love to probably have him on the podcast in the future. So stay tuned because we're going to really dive into the evolution of agentic coding space.

5:03Ben, what did you think? Yeah, I've been learning a lot from reading his content. So it'd be wonderful to bring him on. So one of the things Pete said in this article was he asked or said that the question of whether or not AI can write good code or not is actually just a false dichotomy. He does a really good job in this article of breaking down how to modify tasks to bring them into what he's calling like the AI sweet spot. You mentioned this matrix. It actually looks very similar to a matrix we published recently on the Dev Interrupted Substack where we, you know, again, looking at AI driven software development.

5:36So yeah, I think it's a really great way to just sort of like think about challenges like this. And I think the whole point really is that AI can write good code, but only when it's given clear constraints and adequate context for the problem that you're trying to solve. He had this really awesome comparison. It was, he compared AI to an engineer with the coding ability of a senior level engineer, but the decision-making skills of a junior developer. And in all situations, the AI agents are basically like an engineer that's spending their first hour ever working on your code base. Every time you open up a new discussion, it's like you just hired a new developer that's really great at writing code, but not so great at making decisions.

6:19and some of the recommendations he have like really just resonate with my experience you know my favorite approach that he he outlines in this is when i'm having a really hard time solving a problem with ai is i like to break that problem down into much smaller chunks that require less context to solve and can be more constrained so i can give it all the information it needs because it's a smaller problem to solve and i can tell it to solve it in a way that is much more controlled and constrained in a predictable environment. And he mentions that the danger zone for AI is when you have too much implied context and too open-ended of solutions.

6:56Like if you're counting on a model to figure out the context on its own and choose from a whole wealth of solutions to the problem, then that's where things really start to fall off the rails. I agree. So we'll include the link to the article so folks can check it out and share what you think as well about how you're using these tools. What's our next story, Andrew? Yeah, our next one is diving back into the world of pen and paper and why that's important for developers. I love pen and paper. Yeah, I know you do. That's why we made sure it was in here. I knew that you had lots of good feedback on how to use pen and paper successfully as a developer, as an engineer, as a product-minded person.

7:34I saw a lot of myself in this article as I was reading it. This comes from Yohamati Santala on his website, reflecting on his experiences as a developer. There's things that really stood out to him about being a developer that I resonated with. Like when you go to write code and you open your IDE, it just feels like all of the creative energy and the thoughts that you had about what you were going to write just fly out of your brain, right? And you're now in, you're in produce mode, you're in write mode. And the trick with pen and paper is being able to capture those long form creative thoughts in places where they pop up that aren't necessarily when you're sitting in front of an editor.

8:10It's about having a guerrilla note-taking style, being unafraid to take notes anywhere, everywhere when they come up and when your best ideas strike you. I very much work this way. You know, Ben, I know you're a big pen and paper person and we're going to get your scoop on how you use that or why it's important to you, but I'm a digital note-taker. Before all of my notes were in things like Trello cards and Notions and Apple Notes and things across all my devices. In the last three years, I've consolidated into an Obsidian Vault where I keep daily notes and write topical notes on things that interest me, things that we cover on this show.

8:44So many of those discussions grow out of reflections that I put into that note journal because I think the most important thing that you can do as a developer and you're working and expanding how you think about the things you build and the creative outputs that you have is to keep your notes in a flat and future-compatible way. Markdown sits at this perfect intersection, in my mind, of human readable and machine readable. And it's really good to help augment for new tools that come out too. I've been able to take things from my Zettelkasten from my notebook and just plug my Markdown stuff into AI, for example, and it's context ready to go.

9:22What about you, Ben? Yeah, instead of Markdown, I prefer my chicken scratches that are only readable by me. No one else can read them. But seriously, I do all of my weekly planning and meeting note-taking and much of my planning and design decisions all happen with, you know, I say pen and paper, but today it's now a digital writing device. Like I have a tablet that's specifically for handwriting. And I, you know, honestly, I think it's just, it's much better for long-term knowledge retention. And that's something that is just really hard to come by in this day and age. Like we've all, I think we all struggle with attention spans these days, partly because of the social media era, but now we're in the AI era.

10:04And I feel like it's almost compounding the challenges that we face, just focusing on things that aren't on a screen in front of us. But I also, I also love it because I like any activity that kind of forces you into like a single threaded mindset. Like when you're sitting at a computer, there's so many different things in front of you that you could immediately like attach to and do something with. And it's really easy for your attention to sort of get fragmented across like multiple tasks or multiple components of a problem that you're working on or conversations or things that you're reading.

10:38And this author also mentioned like that he likes taking the notebook and pen on walks with them. Yeah. And I think that's a great idea. My personal choice is I love trail running for a very similar manner, you know, getting out in the woods and just being away from everything for a moment, even in the middle of the day. So obviously I can't bring my notebook for that. But I think the critical thing is that you need these regular breaks from the high-functioning knowledge work. If all you're doing is trying to do like this really high-functioning effort or high-functioning work, you're not giving your mind the space that it needs to break out of the minutia of completing those tasks to think about the bigger picture.

11:19And I think this article is just in general, it's just a great reminder to think about practices that improve mental functioning, mental clarity, you know, and even mental health. You know, there's a lot of ways to accomplish this, but I think practices like this are a really great way to just sort of break you out of that mindset that you get stuck in when you're busy producing. Yeah, I agree. And so we want to hear from y 'all, our listeners, about what are the mindful practices that you do to help yourself focus and protect that creative energy. Maybe you can settle the virtual note versus physical note debate between us because I know we're both firmly in our own camps.

11:56Yeah, yeah. It blows my mind that my handwriting is so bad with how much I actually like to do it. Yeah, well, let's round things out with our last story here. So this is an article on Lead Dev by Kelly Korducky. I really loved this piece. I had to pick it up and include it in here for y 'all. And it talks about a form that shadow IT takes that maybe is not talked about as much as traditional shadow IT. And just to back up for a second, shadow IT, as we know it is, it's when, you know, you work for a company or you're on a team and you're using a tool or a software that's not sanctioned by your company or maybe it's outside of budget or outside of scope.

12:29Those could be from financial reasons, for security reasons. It could be for any number of reasons, really. And shadow IT happens when folks use those tools anyways. We saw this really take a new form when AI came on the scene. You had shadow AI, where folks were using AI or LLMs outside of their company's sanctioned methods, or maybe their company was forbidding it because many did that at the time. And so people were using these tools without supervision or approval from those above them. And shadow IT is another format that this article covers is about folks using unsanctioned workflows or working in different toolings or processes outside of what's established.

13:11So this kind of veers into a more nebulous realm. Maybe they are using a tool that's not approved or established, or maybe they're using a tool that's approved, but they're using it in an unintended way to short circuit a process that maybe adds a lot of baggage to them or makes their day to day work really hard. And systems like this pop up when you have disconnects between leaders and the doers, right? So that was a really interesting angle that this article dived into. I know, Ben, you've experienced some of this before in past roles. What do you think about this perspective? Yeah, I can relate very well to this article because back in a past life when I worked in platform engineering, one of my responsibilities was maintaining shadow dev tools, funnily enough.

13:56That's funny. Some of them did eventually become officially sanctioned, but many of them were either unofficially sanctioned or not sanctioned. Oh, so you were like the keeper of the forbidden tools. You were kind of like the guy with the trench coat that had the software in it. I was the one with the credentials that our centralized IT department didn't know about. You know, we laugh, but this is actually a real thing that happens in so many organizations, I'm sure. Many folks agree. And I mean, the reason this happened is because in our case, it was either we roll our own tools or there were aspects of our jobs within our development workflows that would just be literally impossible for us to complete.

14:34like one really great example i worked with a bunch of open source engineers like people who contribute to open source projects and you know if you're sending code to your collaborators out in the open source space through email and that email has like a little footer at the bottom that says everything in this email is the intellectual property of the company that that developer works for like that's just not compatible with the community that you're working in so what do you do, you spin up your own email server that doesn't have those footers. And, you know, and I think like the lesson that I want to just take away from this is that engineering leaders kind of have this choice.

15:13Either you can institutionalize the tools that your developers need to standardize their adoption and usage, or you're going to have your developers adopt those tools on their own and potentially without your knowledge. So if you have a platform engineering function or DevOps or DevX team or engineering enablement. These are the types of people that should be finding where tooling isn't matching the needs and the expectations of your developers and making it match those needs and expectations. So Ben, what's coming up next? Yeah, so this week I am sitting down with Dan Lyons and we're going to discuss the future of developer productivity, developer experience, and get a little bit into AI as well.

15:57This is actually a bigger discussion. It was a very long discussion that he and I had that we ended up breaking into two episodes. This first half is going to focus more on the developer productivity, developer experience, and we'll transition into the AI stuff for next week. So stay tuned after the break. It's a great discussion. Okay, quick interruption because I'm hosting a workshop tomorrow. That's right, beyond Copilot. What's next for AI and software development is going down June 4th, and yours truly will be hosting it live. We have an absolutely stacked 35-minute panel with past guests from the pod, like Adnan Ejaz from Amazon Q and Brigitta Boeckler from ThoughtWorks, along with Suzy Prince from Atlassian.

16:40We're digging into how top teams are pushing past Copilot, testing out agentic AI, measuring real-world impact, and actually improving their developer experience. And don't worry if you can't make it live. Everyone who registers gets the full recording, plus access to it, the accompanying guide. It has tools, prompts, insights, basically everything you need from our recent 2025 AI impact report. So what are you waiting for? Check out that link in the show notes and let's hang out tomorrow. I'll see you there. Hey, everyone. Welcome back to the show. Today, we're talking about a major shift in the way that engineering organizations think about productivity.

17:20And I've got the perfect guest to dig into it. You all already know and love him. Joining me today is Dan Lines, founder of Linear B and fellow host here at Dev Interrupted. Dan, it's really great to be across the mic from you once again. What's up, Ben? Yeah, it's awesome to be on here with you. Yeah, so if you've been following the evolution of developer tooling and engineering intelligence, You probably know that Linear B, the company that Dan founded and that I work for, have really been at the center of it. But things are changing everywhere when you look around. AI is taking over software pipelines.

17:57And with those changes, we've made some shifts to how Linear B approaches the challenges that engineering teams are facing today. So Dan, we've got a lot to talk about today. I want to unpack what's changing at Linear B for the Dev Interrupted audience and explain what's been happening behind the scenes. So let's just start with the big picture. What has been changing around this space of software engineering intelligence and developer productivity? Yeah, there is a lot to unpack here. And I think in order to understand some of the great changes that are happening with Linear B, maybe we start with some of the changes that are happening in the world.

18:37You mentioned AI. I don't know if you mentioned productivity, but these two things tied together? How are we going to be more productive? What's happening with AI? And also what's happening for our customers. So let me start with what I'm seeing. For our customer base, for developer experience teams, for CTOs, for VPs, and for CEOs, we are now entered into this urgency period to produce productivity. That's what I'm hearing out there. So when I go and talk to a CTO or a VP of engineering or like a director of developer experience, what they're saying back to me is, hey, Dan, we have this extreme urgency coming from our business onto us.

19:22And they're saying to us, you need to be more productive. You need to produce more. And we can get into what productive actually means, but that's the urgency that's coming onto them. And specifically, I hear three questions that are being asked to our customer base, and I'll say what they are. The first question that they're being asked is, what is your strategy to deploy AI in terms of productivity gain? Not just deploy it anywhere, but how does it actually help us be more efficient or improve our quality or whatever it is? That's the first question. The second question that they're being asked is, okay, assuming that you have a strategy for AI and you're deploying, how are you measuring the impact of it?

20:11So they're on the hook for that. And then the third thing, it comes back to either cost or, hey, what are you doing differently with the workforce? If you have this strategy right now to deploy a bunch of AI or we bought a ton of co-pilot licenses, let's say, how does that impact our workforce? And so I think that's the biggest shift that we're seeing right now in the industry. And with us being, you know, CTOs, VPs, DevEx leaders, that's what the business is being asked of us now. I love the idea of this urgency to be productive. You know, I think everyone is feeling this pressure that particularly with the advent of AI driven tools and software development, there's this pressure that like, and a lot of hype, right?

20:59Like there's this hype that we're going to be enabling these like 10x productivity workflows, right? And so I think there really is sort of a lot of confusion in the space around like what it's going to take to be more productive in this environment. Yeah, absolutely. Yeah. So in one of the big things that has sort of been central to Linear B's existence really from the very start is engineering intelligence, like this idea that you need to be able to measure the productivity of your organization, measure the developer experience, show how engineering impacts the business bottom line. But let's talk for a moment about why you and us here at Linear B have, you know, view that as not being enough anymore.

21:44Yeah, exactly. So, yeah, I mean, six years ago, five years ago, just having software engineering intelligence, meaning having a bunch of metrics, having a bunch of surveys, having a bunch of information coming to you being the CTO or like the head of DevEx, that used to be enough, but that's no longer the case. And the reason that it's no longer the case, I kind of think about it as, think about like the smartest person you know. And someone that has, you know, and there are some folks out there like this, like the smartest person I know kind of knows everything, but doesn't necessarily mean that they are capitalizing on that knowledge.

22:24Meaning they're super, super smart, but they might be a little bit lazy. They're not applying their knowledge. And so I think about it the same way for software engineering intelligence. It's amazing to have all of this information, again, whether it's a bunch of metrics or a bunch of survey results, that's okay and an okay start. but the difference is we now need to take that information and we need to apply immediate actions. And for linear B, that's going to be our AI automations. That's going to be our GitStream technology, all of that. We can get into it, but I need to take all of that information and I need to apply it in a way that I can show my organization is being more productive right now.

23:10And I think that's the difference from, you know, five years ago to the urgency that there is today. We are not, at least at Linear B, just stopping with metrics saying, hey, here's all the metrics in the world that you could possibly have. No, we're not stopping there. We're now saying, of course, you get all of the metrics and all of the survey results, but here are the next steps that you're going to deploy into your SDLC to actually capture productivity gain. That's the difference. And we've been throwing this word productivity around quite a bit. And it's a very complicated term for sure.

23:47And it brings out a lot of different opinions about what it means and what you should value when you think about developer or engineering productivity. So let's think about where, you know, here we are in 2025, like we have engineering organizations that are adapting to this modern AI driven way. What does productivity actually mean in that environment? Yeah, you're right. It is nuanced. It needs to be described. So let's try to break it down. And I think the best way that we can break it down is by role. What productivity means to a CTO or a VP of engineering, I think is a little bit different than what productivity means to a developer or a developer experience team.

24:34So when I hear a CEO or a CTO or a VPE or someone in the C-suite talk about productivity, what they're looking at is how much value can I output versus how much does it cost me? So value to cost. Now, for an engineering organization, their job typically is to produce value through a product back to the business and to the organization. And they have a workforce and they also have tooling and they also have everything else. And they have a cost that's associated to that value. And what they're being asked to do typically is, hey, maintain the cost that you have today. we're not going to increase your budget and we're probably not going to increase your workforce, but I need to see more value coming out from the engineering organization.

25:32And you could say the value is, we have a bunch of ways to measure this within linear B, but you can measure new value. You can measure value enhancements. You can measure story delivered. You can measure pull requests that have been delivered. But at the end of the day, It's I need more value per cost. That's the way that a VP or a CTO is looking at this. Now, the way that that translates then for the developer experience team and for developers, developer experience team is on the hook to now figure out how to actually be hands on and deliver more value. Tough job. So they're serving developers.

26:11And the way that I look at it there is, okay, I cannot ask my developers to work any harder. They're already working a ton. We're not going to get more value there. If I came back to you, Ben, and say, hey, you're already working eight to 11 hours days, Ben, I'm going to need you to work the weekend. That's not going to work. No, not going to work. So the way that value or productivity is provided then for developers is taking some job off of their plate that they're doing and probably usually doing manually without sacrificing any quality. So you used to be doing, for example, Ben, you used to have to do X amount of code reviews per week.