Causes of Application Developer Burnout with SingleStore’s Akmal Chaudhri

This is Textron tv. Hey guys, thanks for the throw. We're here with Akmal Chaudhri, who's developer advocate for single store, and we're talking about the causes of developer burnout and what might be done about that.

Akmal, welcome to the show. Thank you very much, Mike. Uh, thank you for inviting me, and, uh, great to, to be here and an opportunity to talk to you and, uh, and your audience.

There are no end of theories about what causes developer burnout. So, um, but you're an advocate. What's your perception of what's going on here?

And it feels like we're seeing a lot more of it, and I wonder if it's not contagious. Uh, I think my take on it, Mike, is that essentially the pace of change of technology today is just very, very fast. We are really being asked as developers to deliver stuff faster.

Uh, you know, and, uh, in, in terms of where the business needs are. I mean, the time to market is critical. Um, you don't offer a product or service, your competitor's gonna do it.

So the pressures on developers to deliver faster and learn new stuff much more quickly. I think these will put lots of pressures on, on, on people. And that's the thing.

I've, I've noticed going back to the early days when I started my career, it, it was, and it felt like a much more sort of gentle pace kind of environment. You know, there weren't quite the, the pressures and challenges that I see today, yes, of course there are still deliverables, there are time timescales, you know, project deadlines, but it felt that you could achieve those. Okay.

And, and you could do so in a manageable way. That's the big change that I've noticed over this kind of past 25, nearly 30 years, I would say. We also seem to have, over the years, shifted more responsibility left towards developers, and they're required to know a lot more about infrastructure and various things like that.

Is that contributing to the challenge? Because it doesn't seem to me that all that time is actually spent thinking and writing about code. Um, I think a, again, yes, it's a case of having to know much more simply because, uh, the, the working parts are so much more, you know, there's a lot to think about, uh, uh, in, in terms of the role, in terms of where you fit in and the other things that you have to think about as part of what you're building.

Uh, so you may have to learn, like you said, you know, on, on the left, on the right, there's other technologies that you may integrate with. It's you, it's a, you know, clear that there's a, an understanding that you have to know how your tech and your part works well with these, uh, as well. So it, it's really, you know, quite challenging.

Again, in terms of the, um, both the, the knowledge that's required, um, the effort, the timescales, everything is pressurized, uh, upon the, upon the poor developer. Uh, so she is really, you know, very challenged today in terms of deliverables, I would say. They say it takes a village to do anything worthwhile, um, in our village, in it, there's all these IT operations folks, DevOp folks, software engineers.

What is it that we should be asking them to do to kind of reduce the load on the developers themselves? And, and you know what, because no one seems to know exactly where the friction is. Yeah, I think that's a great question.

Uh, I, I don't have a great answer for that. I mean, that, that's one of these things that I think that I, I, I've thought a little bit about, um, adjacent to that. Um, but I think it's a group effort.

Uh, we all have to kind of look at the issues together. Um, as individuals, you know, we can take regular breaks, there can be, you know, better work life balance, you know, our employers can assist with that. Um, but I think, again, because of the challenges we face today in terms of faster time to market, faster deliverables, I think these all impose considerable headaches as well.

Not only in time in terms of figuring out how we navigate our way through this, uh, but, uh, overall in terms of the, the wellbeing of the people that work for us, I mean, because they're our greatest asset, uh, in, in an organization are the people. Uh, and we have to take care of them. We have to look after them.

Um, I think people need to be much more, um, cognizant as well, and they need to be more aware, uh, of, uh, uh, things that are important to them. You know, the work-life balance, as I mentioned before, that's very important. There are rules and laws, I think, in some European countries now, which prevent people from being contacted at weekends, for example.

You know, that's, that's a, a good first step. So relieving them of some of these pressures, and, uh, I, I think that's the way to go. One of the things you will hear from the folks who run those platforms on behalf of developers is that the developers themselves, uh, want to be able to use whatever tool they wanted to use at any given point.

And their perspective on that is, well, that just makes the overall IT environment more complicated and harder to manage and adds additional levels of friction. So is there a balance to be struck between, you know, developer freedom and what's good for the organization as a whole and by extension, the developers themselves? Yes.

Um, that's a great point, Mike. So I think what I've seen, again, is a shift in power, if I can put it that way, politely. Uh, so today, the developer, he or she's in a very powerful position simply because of the choice that they have available.

Uh, open source is widely available, and I, and i, I, with my developer hat on, I can tell you I like open source. I like free stuff. I like testing it out, trying it out, building stuff.

And if it works, I like it. And, and I tell my friends and colleagues, and then, you know, we share our experiences. So it kind of filters up from the bottom, if you like.

You know, the power is there with the hands of the developers, um, and typically within an organization, having that kind of power and flexibility, in one sense, yes, it's a great thing. On the other hand, as you pointed out, you know, uh, we don't want a free for all. There is, uh, some notion in terms of managing all of the, all, all of the, uh, software, the infrastructure and so on that we have to use.

And, uh, that has to be balanced. And I'll give you a, a quick example. So some years ago, uh, I did a bit of contract work.

So when I finished my graduate studies and, and, uh, I, I did a bit of contracting work. So I worked for a, a major financial institution. And within this financial institution, I was brought in to look at a system that had been developed.

And essentially the developers brought this, uh, technology into this, uh, uh, um, environment. They started using it, they started building it sometime later, management found out that what the system was, they had totally unaware of it, and then they wanted an assessment. You know, is this something that's actually practical or valuable for the organization?

And indeed they found it was, um, but it came as a little bit of a shock to them to find that there was this group of people that were building something that was totally, uh, you know, it was not on the project plan. They didn't know anything about it, but yes, it was delivering value, so decided to keep it, but they needed an assessment in valuation of it. And that's a kind of an extreme case.

I don't think that happens very often today, but it's, again, shows how relevant developers are in terms of the power that they bring with them. So, yes, uh, it's great to experiment, great to test things out, try think new things out, new technologies, particularly today where stuff just moves so quickly. Um, but at the same time, you know, that needs to be managed.

Otherwise it's gonna be chaos within our, our development environment and within organizations generally. Well, I'm not sure that, um, it's not continuing to happen because, you know, with the rise of ai, we're hearing developers pressed on the productivity front are using these tools and, um, sometimes for better and sometimes for worse. And, um, and they don't necessarily care too much about what the mandates are for using those tools.

So what's your sense of what is the impact all these AI tools are gonna have on developers? Okay, um, um, again, share my experiences. So, uh, let me give you, use the example of OpenAI.

I mean, but this is kind of more broad and more general. So when this chat GPT kind of emerged, I ignored it for about three, four months. I thought it is one of these fads, nothing interesting here, you know, um, move on.

Um, but kinda stuck around and I thought, let me take the opportunity to evaluate it myself, you know, what does it offer? And I found that yes, uh, to a point, it's very useful because there's things, and, you know, for example, if I have questions about coding, for example, or I have questions in general that I want some advice, I want someone to act as a kind of an assistant to me, I can ask skid things and it will give me some information. Most of the time I would say it's quite valuable, uh, code-wise, you have to be careful, obviously, because you, you cannot rely on the fact that it's gonna get everything a hundred percent, uh, correct.

Uh, so take it with a pinch of salt, but I, I found overall it's improved my productivity considerably, uh, simply because there's things that it can now help me with that I am, I not think of simply because it's knowledge base is far greater than mine, and my view of the world is rather limited, and it knows far more about the world than I do. So I found that using it as an assistant rather than something to replace everything I do, uh, or as an IDE, for example, which I think is the wrong, wrong way to use it, that's helped and improve my productivity considerably. So I think that these kind of technologies, um, as they get better over time, which they will do, okay, and, uh, we will start to see this being deployed in, you know, a lot of tools that are emerging and will continue to do so, that's gonna improve productivity, that's gonna help us as developers as well.

So there may be things, for example, that take away a lot of the mundane, uh, sort of, uh, you know, tasks that we might have had to do before and let us focus on some of the more interesting kind of business problems. I think that's where I, I see this stuff going. Do you think It will become easier to onboard folks to new projects because of AI capabilities?

It seems like one of the issues that often plagues us is that when we do bring somebody on, it takes some six months to be productive. Yeah, that's a great question. Uh, again, let me, uh, draw some, uh, experience from the past as well.

So one of the companies I used to work for in the past, you know, huge global con conglomerate, if I can say the word. Um, uh, there, there was a gen, I heard a story, okay, internally, there was a gentleman, he'd been with the company about 30 years, and he was set to retire, and he had a huge wealth of knowledge. So what they got him to do for about six months was essentially input all of his knowledge into a system.

And as they brought on a couple of new hires, those new hires pretty much lived off that system for about a year or so. I mean, and as they brought, sort of came up to speed, there was a lot of information contained in within that. So I think that what we can do is we can try our best to make use of these technologies a, to capture a lot of that experience and expertise and skill that, you know, old guys like me, for example, would have, um, and can bring, and those, these kind of younger generation in terms of developers bringing them up to speed much faster.

And this is, I think, where these AI tools can really help. So onboarding, uh, getting up to speed, uh, having these intelligent, uh, sort of applications agents, really, I think this is gonna be very, very helpful for us, uh, uh, going forward. And I speak that, uh, more broadly in, in terms of developers.

I, I, you know, I, I would speak for them, uh, uh, because I think that's what, what would help me if I were a younger guy, you know, 20, 25 years ago, um, if I had the tools in place, that would've really assisted me, I think. Do you think the bar for becoming a developer at least entry level is starting to be raised? Because the expectation is a lot of that, uh, work that we used to give the junior developers is gonna be increasingly automated.

So for them to get hired, they're just gonna have to know a lot more. Yeah, it's a, that's a great question, Mike. So it, it's a challenge.

I would say, um, again, my observation is that today the, the amount of technology that we have in the marketplace for the poor developer, I mean, he or she, you know, how do you figure out what is the kind of half dozen or dozen tools and technologies that you need to learn that are gonna be useful for you going forward, both in terms of your career development and, uh, uh, other sort of, uh, you know, prospects, uh, in your life? Uh, it's really, really difficult. Um, I, I think AI is gonna help to what, to one degree, but again, for, uh, identifying what's the cool stuff that they should be working on, what they should be learning, that's very difficult to say.

Uh, certainly for now, the flavor of the month is all of these large language models, generative ai, this kind of thing. I think once the dust settles, then this becomes more sort of, uh, mundane if you like, you know, in terms of it's there, we use it and, you know, we don't, perhaps don't think about it so much, then we kind of look to the next, uh, uh, next big challenge. Um, I think currently, uh, because this is very much stuff that's, um, in chaos, I can put it that way, so much stuff coming out so fast.

Uh, it, it is very, very challenging. I don't have a great answer for that. I, I think simply stay on top of it, you know, read what you can observe, watch, uh, and, you know, take whatever training you can and just keep your feet, uh, on the ground, you know, learn, look, uh, talk to your peers, uh, and really skill up as best as you can.

Uh, these are the things that I would recommend, uh, again, simply because, you know, I feel that I'm in that boat as well, and I'm an old timer. What exactly should we be measuring when it comes to developer productivity? Not too long ago, people were obsessing about lines of code and whatever it is, but it seems to me, um, coding is not, uh, a factory job.

It's as much art as anything else. And you need time to have that moment of inspiration. And then you have moments where you code like mad, but then you know, you have downtime.

So how do I think about that if I'm a manager of a development team? Yeah, again, great question. So I think my take on this, and, and again, I'll draw from my experience.

So I often find, um, that I spend a lot of time researching a problem now, rather than just diving into the code, I try to think about it much more on paper. So I try to gauge what, what the, what is the solution that I'm trying to build? How would I approach this problem?

What are the workflows, for example, uh, what's the end result I'm trying, trying to achieve in terms of the result that I want? And then using whatever knowledge and skill that I have in particular, programming languages, for example, start off with a framework that, uh, is fairly broad. Um, sometimes I'll go to Stack Overflow or use tools like chat, GPT, for example.

'cause it's things that I don't know, and, and I want to find out more, and I will look for references and I will look and go and research those read up. And then that helps me in terms of the development process. Um, so I think it, it is much more the case that it, like you said, it's not so much more the lines of code that we worry about anymore.

Um, I think it's the overall process, uh, of building, uh, an application or a system. And that includes everything from the research that's involved to the documentation, the test units, for example, that we, we want to run. There's a whole range of things that we have to be broadly aware of and the kind of, uh, end results that we want to achieve.

Uh, are they, you know, do they align with, uh, what the, the expectation is? You know, are we going to be able to deliver something that meets the requirements? So I think the days when we purely focused on the code, I think are long gone.

Um, it, it's much broader, I would say now, and simply because again, just drawing upon my own experience, certainly over the last couple of years, that's the kind of approach that I tend to use. All right, folks. Well, you heard it here.

At the end of the day, building software is still done by people. A little help from machine these days. And of course, anything involving people comes with its inherent limitations.

So managed accordingly. Thanks for being on the show. Great.

Thank you very much, Mike. Thank you. All right.

And back to you guys in the studio.