Fostering Developer Creativity and Preventing Burnout – Trisha Gee, Gradle Enterprise

This is Techstrong tv. Hey guys, thanks for the throw. We're here with Tricia G, who's lead developer evangelist for Gradle, and we're talking about generative AI and its impact on the developer experience.

Tricia, welcome the show. Thank You. Having me.

We've all seen GitHub co-pilot, which you know, is an interesting usage of generative ai, but it amounts to kind of a spell checker for coding. Um, so the question I have for you is, you know, what seems like we're at the tip of the proverbial iceberg here. Where do we go from here?

How do you think this will impact the developer experience and what should we expect down the road? Yeah, that's not too big a question at all. I think you're absolutely right.

It, it is the tip of the iceberg. I think that this is, uh, like, um, just the beginning of a, of a lot of different opportunities for, for developers. And it, I think it's right to be asking a lot of questions about, uh, what does it mean and what should we do and where should we go with those sorts of things.

I'm trying to figure out where to go next, really, which, which, which bit to attack first. Um, let's talk about how I see generative, um, AI working like positively for, for the developer and the developer experience. Um, so, or even track further back than that, let's start by saying that originally I was extremely skeptical about the role of AI in, in the developer experience in coding.

Um, I have been a developer for about 20 years. Um, I actually studied computer science and ar artificial intelligence back, um, at the, in the naughties. And, um, and so when a lot of people were talking about, um, AI to help us as developers, I was a bit like, I don't think it can do that yet, and I certainly don't think it can replace developers.

Um, and there was a lot of sort of fear and confusion I think around, you know, can these tools do our job? And, um, the more I've been thinking about it over the last sort of year or so and playing with some of these technologies and kind of using them, the more I sort of think, I think this is my personal opinion, is it's a, it's a great new tool or set of tools that we can use to actually be more effective as developers. What we are used to doing as developers is using tools like our ides, like our search engines, um, to actually help kind of expand our knowledge to have some of the stuff that used to all be in our minds all the time back in the beginning.

Put that stuff a little bit out there outside of our brains and use tools to access that knowledge. Um, ides for example, have been able to generate code for quite a long time now, and that code generation gets more and more, uh, complex and more, um, advanced. Um, when we're trying to, when we are trying to troubleshoot problems, we have, uh, been able to go to Google and stack overflow in places like that to kind of, um, not just have to try and sit down and debug our problems ourselves.

We can use other tools to kind of come to those, uh, come to the answers that we want. Um, and I'm starting to see the use of, uh, a generative AI to kind of like enhance some of those things as well, particularly around, I mean the simplest case is obviously co-generation. Instead of using your IDE to generate two or three lines of code, you can use it to kind of generate a working application.

And I can see why some people might think that that is potentially a bad thing for developers. Cuz isn't that what we do? But that's not what we do at all.

What we do is we listen to people figure out what the, our code should be doing, what should the computer be doing for us, what are the business use cases, where are we going? Um, what is the technology supposed to enable? And then come up with some sort of technical solution using tools like higher level languages and ides and other people's libraries and frameworks and putting together a solution using those tools that meets the business need.

And I think AI and machine learning and those kinds of technologies are another set of tools that we can use in order to achieve the goal of solving a business problem or filling a niche that wasn't previously filled. Do you think the overall quality of the code will improve? Because I would say it's no secret that, you know, we've had some, uh, vulnerabilities in code, we've had a lot of code that might be deemed sloppy.

Um, so will we get to a point where the machines at least will, um, even all that out a little bit? That's a really excellent question. I kind of wanna answer that.

I wanna answer in both directions. I wanna say that developers write better code and that machines write better code. It, it depends a lot on the models, of course.

Like if you put a lot of not terribly well-written code into your model, then the AI is just gonna spit out code with security holes and vulnerabilities and, um, you know, difficult to understand, difficult to debug code. So, you know, garbage in and garbage out. The machine is not automatically going to know what good code looks like.

And in order to create good code, you need really good developers to create good code that works properly, that is secure, that has been checked by the other barriers tools to, to make sure that it, it is secure. So again, I sort of see this as a bit of a, you, you might argue it's a bit of an arms race, but I see it more as a, a partnership need great developers who can critique code and, um, improve code and, and harden it and make it better, um, in order for the, the machines to be able to learn from that code and to continue creating good quality code, whatever that looks like for, for the developers who are using these tools to, to generate code. Um, I would also argue that, uh, yeah, I mean it's the same problem.

Sloppy code is written by developers who are being rushed or have not had the correct training. And if we're not willing to train our human developers who cost us a lot of money, then who's to say that we're adequately able to con to train these AI models that, um, you know, they're not necessarily gonna fix our problem if the problem is good, good training, good mentoring, good quality code to learn off, that affects both human developers and the computers. There's a lot of talk about how this will lower the barrier for entry for developers.

Do you think I don't need to be a rocket scientist anymore to write great code? Or what do you think's gonna happen in terms of how quickly can we bring somebody on board? I think that generally speaking, technology is a good way to, to, it should be a good way to lower that barrier to entry.

Not just in terms of um, the stuff that we're talking about in terms of ai, but what the, what the area I'm working at the moment is developer productivity engineering, which is about, um, the automation of stupid stuff that developers traditionally had to spend a lot of time on, which includes things like, um, build times and test times and, and those kinds of things. But also in my mind includes a lot of things like onboarding. So how easy is it to set up your developer environment?

How easy is it to get the dependencies you need to get your application running? I've worked in plenty of environments where onboarding is just difficult and complicated and requires people to have ridiculously senior levels of knowledge just to get your environment working. And automation in terms of developer productivity, engineering in terms of potentially ai, which can help get you started with perhaps some, the code that you're writing.

I think these are all good things to make it easier for, for developers to be effective. But it does mean that you, you need to be working in a team and an environment which really embraces those sorts of things and really values, um, easing those, uh, pain points and kind of lowering those blockages to a developer being effective. And that sometimes is why people get a bit stuck or organizations get a bit stuck cuz they're like, well, I don't really wanna pay money for this tool, or I don't really wanna invest time in setting up this tooling because that seems kind of expensive.

So, you know, these developers are smart people, they can kind of just get on with it. But the, at the end of the day, your developers are smart people, but they're also paid a decent hourly wage and if they're kind of waiting around for or stumbling around trying to get started, that's a lot of money going down the drain when a bit of investment in automated tooling can actually really help the organization save money in the long run. Mm-hmm.

We also hear a lot about citizen developers. Will this make citizen developers a more viable option? Because, you know, the knock has always been that it's great to have them involved, but they tend to create applications that perhaps are not very attractive.

They have security issues and they certainly can scale the way a developer would build it. So what will be the role of a citizen developer in the, in the age of ai? That's a great question that I haven't really thought about.

I mean, I've, I've worked in a lot of places where various technologies have been touted as the way to get normal people to do development type activities. Traditionally things like DSLs for writing test scripts or things like, um, when I worked in in banking and finance, there's a lot of things around providing frameworks for quants, et cetera to be able to do their kinds of jobs. Um, I think at this stage, I think my, my personal position is I think we should always be encouraging everyone to be able to use development style skills and write stuff that the computer kind of understands.

I think that's great, but I think there'll always be this kind of separation between full-time developers who kind of really, really want to think about development and the computer and the design and writing bug free code as bug free as possible. Um, and there's, that's sort of one class of people and there's potentially other classes of people who just wanna get something done and there's nothing wrong with that. I think we absolutely should have a class of people who wanna get something done and don't necessarily care about domain-driven design and the best automated testing framework.

Our job, I think, as developers is to try and help other types of people who want to do stuff with computers to do that as effectively as possible. So if that means doing things like code reviews, um, checking full requests or, or providing coaching and training around how other people can use various AI tools to create code, I think that's an opportunity for us to kind of share the stuff that we really love that we're really good at and make it open to the world. And I, I don't see that as being a bad thing.

Mm-hmm. What do you think the impact will be on productivity? I mean, I'm sure every boss out there thinks that because of ai we're gonna see more code written faster that'll be moving through those pipelines at lightning speed.

What's the reality? I think there's definitely, it definitely has the potential to, to generate more code. Is that the same as being productive?

Maybe not. It depends on how we measure productivity. In the past we used to measure productivity as lines of code.

We realized that, you know, developers are smart people and can kind of gain these kinds of metrics and that lines of code does not necessarily equal features for the users or fewer bugs or whatever. Um, I think the, the, the simple answer is yes, if we have tools that help us to do our job as a developer, yes, of course we can be more effective and more productive. We can write more features, we can create, um, we can, we can add more to our application if we're using things like generative AI to create some of the features for us without us having to do all the typing and create everything.

So, so yes, I think that we can definitely do more. I think one of the things that I think the value that we bring as developers once we start generating this kind of code is to make sure it's correct, make sure it's tested, make sure it's secure, um, make sure it's doing what we, we we thought it was doing. And that will include, I believe, um, making sure that the automated tests around that are, are correct and doing the right kinds of things too.

Mm-hmm. Um, yes, I was gonna go somewhere else with that, but now I can't remember what it was. What do you think might be the impact on DevOps pipelines then?

It seems like a lot of the automation is all for the developer, but on the back end of this, is their receiving end of this is the DevOps team and are they gonna have to cope with more code moving through pipelines at a faster rate? Is that what's gonna happen? I I think that's a definite possibility.

I think that if we are generating more code and able to free ourselves from the typing and doing more of sort of critique of the code and then submit it and push it to CI or whatever, um, of course that has the potential to, to create a lot more code going to the DevOps teams or, um, going through the CI pipelines or whatever. Um, and uh, I think that that's where things like, um, the tools, for example, greater enterprise, the tool that I do a, a lot of developer advocacy for is, um, designed to help decrease build and test times. So obviously the more code that you have and the more tests that you have, the more time it could potentially take to run the tests over that code to ensure that your code is correct for the developer to get feedback on whether things are going in the right direction.

And tools like d p E tools which allow us to shorten those build times and shorten those test times are gonna be absolutely essential. Otherwise, we're just gonna have a growing and growing code base with hopefully growing numbers of tests which take potentially more time to run, potentially more time to troubleshoot and debug. We're gonna need tools like Gradle Enterprise and other tools in that kind of space to help shrink those build times back down to run only the tests that need to be run to provide troubleshooting tools for developers to be able to look and, um, look at the tests as they fail, perhaps on a CI environment that maybe they don't own.

And to ease the burden of perhaps some of these DevOps teams because they don't wanna be wading through loads of modes of errors, um, when it's not necessarily their team that has contributed those errors. Do you think as all this comes to fruition that there's gonna be some security issues here? We have these general purpose, um, AI engines that don't seem to differentiate too much about where they're pulling code for.

So do we really need to move to like the next generation where we're gonna have more narrowly focused, uh, large language models that really drive in on application development versus just something that is, you know, essentially brute force? I think that I think we're gonna have to be considering, I mean, yes, um, I think it's a good idea if the, if the tools that we're using are focused on, on the job that we're doing. For example, my background is working with, with IDs and IDs specifically the ID that I'm most keen on using is a Java specific IDE that gives me Java specific help and context and support.

And that's much more productive for me to use than a text editor or, or a word processor. So a a a tool that's focused on what you do and understands how you do what you do is going to be more productive for you as, as a developer. But I think there's the, we also have to assume that that's not always going to be the case.

The code is not always going to have been generated by a smart focused tool. It's not always going to have been checked by, um, I don't know the, the best tools for checking security or the best developer on the team. So I think we need to be considering the, the, the checks and balances of what, of the code that we've created and, and the code that goes into production.

So we are going to need to make sure that we are checking our dependencies are don't, aren't full of security holes and that we haven't, um, used that the, or we or the machines haven't used patterns which are commonly associated with security holes. So yes, I think we should use better tools for, create the best tools we can for creating our code, but I also think we can never relax our, our vigilance around is this code the correct code? Does it do what it's supposed to do?

Are we introducing security problems? Is it unreliable and flaky? Has it been tested properly?

And that is a combination of other tools. For example, there are plenty of tools which check security, um, tools like the, the greater enterprise, which will allow us to make sure we are running the test on it as frequently as possible because we've produced that test timeline and also human developers. And this is why I, I'm not worried about AI replacing human developers because at the end of the day there has to be someone to go, yes, this seems reasonable, or no, this is a, a massive anti-pain and we definitely shouldn't have this in our code base.

What's that one thing that we're not paying enough attention to, do you think in this conversation? And what do you look at and say, you know, folks, we need to take a minute and look a little further down the road than we are at the moment. I think something that we haven't, we haven't covered in this conversation here, but I think is a, an interesting topic, maybe it's a like a, a very selfish topic for me is around developer happiness.

Um, and can, can tooling like ai, like um, d p E tools, can they not only make us more productive, but make us happy? One of the things I worry about when we talk about productivity is burnout. Like burnout is a real thing in, in our environment.

And if you're gonna be piling more code on more code and you know, you're so productive cause you're creating all this code, but you're also thinking all the time about is it doing the right stuff and trying to keep up with the pace of change that could potentially be be a problem for burnout. Um, and burnout is already a big problem in our industry anyway. I think that one of the things that we, one of the factors we can be considering when we're considering the tools that we use is does it make our developers happier?

And that sounds a bit like fluffy and slightly hippy, but developers are going to continue to be a very important resource whether we have automated tools to do stuff or not. And as we've already seen, developers are kind of commodities that get swapped between various organizations. What if your organization is the kind of organization that values productivity, tools that help improve the developer experience to a point where the developer is happier because they're able to focus on the stuff that they're interested in, they're able to be creative and innovative and thinking about the interesting business problems and not worrying about generating a ghetto or a setter or, you know, the simple stuff that is kind of manual.

If we have teams which are using productivity tools to enable developers to be more away from the boring stuff and more into the stuff that they're good at, I think that's a very positive thing as well. Not just for developers obviously, but also for the industry. If we're happier and more productive, it's also going to potentially earn our comp a company's more money.

We create applications which are better suited for the users. And it's an all around positive feedback loop. Well, let's go a little bit deeper on that conversation then.

So we've always had this kind of push pull between art and science when it comes to coding and we hear people refer to, you know, software factories and whatnot, but at the end of the day, coding is also art. So what ultimately do you think AI will do? Will it help us have that conversation in a more meaningful way between what actually is the difference between coding as art versus coding as science?

I think that's, I think that's really interesting when I think about, I dunno the specific answer to your question before I start wandering off and, and talking about my own things, but, um, when I'm thinking about AI and what it can do for, for us as developers, I'm often comparing it to what it does for, for me in my writing. So, um, wrote, but last year and, um, I didn't use AI for writing the book, but I've been using it to translate it into different languages and, and that feels a little bit like generating code. And the, the, the interesting thing about that is it allows me to do something I couldn't have done before or certainly without a huge investment of time or money and reach people I couldn't reach before.

Um, and that from, from an artist point of view, if you like, that's kind of great. You get your work out there, um, more readily. However, I can also see the argument there in terms of AI can help replace these types of roles, these writing roles and these creative roles, which I fundamentally do not disagree with because I do not agree with, sorry, my good do, don't quote me out of context.

I fundamentally disagree with replacing creative people with ai. I think that's like the creative innovative thing is the only thing that we can really bring that's unique. So the, the same thing with, with coding, a lot of people misunderstand, our developers misunderstand what the job of a developer is.

A lot of people think that our job is to talk to the computer and that's really not the most difficult bit because the computer follows logic, it follows a set of rules. And as we've been able to see you can generate stuff which can talk to the computer. The, the difficult bit is having all those conversations with all those, those users and business people and your team members who all have very different ideas on what the coach should do, how it should look, where it should be, how to deploy it, and all those things.

And that requires kind of human, I'm gonna use the word instinct. It requires you to filter it through your, your experience and through all the different experiences of everyone on that team. Um, and I, and that's what, to me makes it a very creative process.

All this communication and talking to people and bouncing off each other and having these like, um, innovative ideas, these sparks of ideas that you haven't had before and are not encoded somewhere in, uh, in, in a model, uh, apart from the model that's in your head, that that's an entirely different thing. Um, and so I, I guess it's a long-winded way of saying I've always thought of, uh, developing as being a very creative activity. I've always been very irritated with the simplification of it being an engineering discipline, but worse than an engineering discipline.

A uh, a sort of manual activity where you do the same thing all the time. Like you are, you might be writing an if statement all the time, but you're not writing the same inventory system every time. You're not writing the same new web app that sells, I don't know, monkey shaped hamsters to children, whatever.

Um, you know, these things, these are the things which are, are the creative ideas that come for human beats. Um, so I, I think that one of the things I really like about being a developer is it's art and science. It's creative and engineering.

And it's that combination of the, of, of almost the tension between those things. The fact that the computer will only do what you tell it to do and you have to figure out what to tell it to do, but like what you need it to do is about 10 different things depending on the other circumstances. And that's, this tension I think is really a, a, a fun and interesting thing about being a developer.

And I, I think that AI can help us in this space as well because I think it can, we can use it, we can lean on it on the, in the places where we don't wanna do the boring manual, repeat this, do one of these all the time. We get the AI stuff to do that thing and then we can free ourselves up for having the more creative art kinds of, uh, conversations and, and did the innovation thing. All right folks, you heard it here.

We're about to have the big existential conversation cuz it's not really about the machines, it's more about us. Hey Tricia, thanks for being on the show. Thank you for having me.

All right, back to you guys in the studio.