Trisha Gee is a developer advocate and Java champion with over 20 years of software experience.
Connect with Trisha on LinkedIn and X.
Congrats to user citelao for winning a Famous Question Badge for their question VS Code SSH keeps dropping connections, but I can SSH just fine.
Transcript
[intro music]
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I’m your host, Ryan Donovan, and today we’re going to be talking about the IDE and its place in the AI age. My guest for that is Trisha Gee, who is a Java champion and a developer productivity advocate. So welcome to the show, Trisha.
Trisha Gee: Thank you for having me.
RD: Before we get into the IDE business, give us a little insight into where you came from, how you got into software and technology.
TG: As I get older, this story gets longer. I kind of came through a sort of classic route, if you like. So I’m fairly old. So I started coding when I was about nine, sort of in the 80s, like a lot of my cohort did with BASIC. And then I did a computing A-level when I was like 16 through 18, because I’m from the UK. That’s what we do. And then I did a computer science degree, computer science and artificial intelligence, actually, back in the turn of the century. AI was very different back then.
RD: I took an AI class back then too.
TG: Yeah, it was different. But then there was only two schools of thought, like classic search-based AI and modern neural networks AI. And it was kind of interesting to learn about the two different approaches. Fortunately, I went to the University of Sussex and they taught Java back when it was like Java 1.1 and it was like brand new. So I was really lucky that when I came out of university in the early noughties, I had experience in Java. I’d been working for Ford Motor Company as an undergraduate. So I kind of knew what professional software development looked like and kind of got into web development and java stuff in the early noughties. Spent about 10 years as a classic software engineer, doing java and web stuff, and then I worked at LMAX with Dave Farley when he was writing the Continuous Delivery book and we did a whole bunch of XP, and we did Continuous Delivery, and we did like all the stuff I’d read about for like 10 years and I’ve never seen anyone really do, and I’m like oh this is what software engineering should be all about. I worked there for four years and I loved every minute of it and I had such a good time. Then I learned a lot about using the IDE, and we were pair programming in IntelliJ IDEA, and previously I’d kind of– I’d used an IDE, obviously, and I kind of did some basic stuff with it– this is in like 2012-ish. And then when you’re pair programming with people, every individual you pair with has a set of tricks that they use. And so as a team, you all get much better because you all learn everyone else’s little tricks. So I learned a whole load about the IDE. And I learned a lot about how to work effectively in software and productivity and how XP works in the real world. And I thought, what I want to do is I want to go out there and tell other developers there is hope and everything doesn’t have to be rubbish. All those jobs that you’re doing, which are just kind of your classic software development grind jobs, like it doesn’t have to be that way. There are lots of things you can do on lots of different dimensions to kind of improve your life as a software developer. And that’s kind of how I got into advocacy because I’m like, I want to go to conferences and write blog posts and do videos sort of showing people tricks with IDE and telling people like where the trade-offs are with certain agile techniques or certain design things and sort of talk about the pragmatic implementation of the things you read about in books. And so with that I ended up working at MongoDB, worked at JetBrains doing IntelliJ stuff, and worked at Gradle doing developer productivity advocacy. So that brings us to now where, now with the AI thing, to begin with I’m like, where does my IDE experience and my sort of classic software engineering experience– where does this fit in this new world order? Especially because I’m not hands-on coding stuff, although I did rewrite my website using Claude, of course, because everyone does. But what’s really interesting and what I’m doing now is just trying to figure out what’s still relevant in the age of AI, what is genuine productivity, and what is noise as we travel along the hype curve for AI.
RD: What is the sort of productivity gain of an IDE? We ran an article about IDEs a while back, and the author made a kind of, offhand snide remark about Vim and Emacs and people got super mad about it.
TG: People feel very emotional about their tools, full stop. I’m very emotional about IntelliJ IDEA and one of my reticences for embracing some of the AI programming is because I’m like, I’m faster with my IDE because I know how that works. And I’ve seen the same thing when I’ve worked with people who know Vim and Emacs very well, and I’m like, but you could use the refactoring tools in IntelliJ IDEA. They’re like, yes, but that requires a learning curve. I’m just not willing to pay that price. And I’m perfectly productive enough with the tools. I’ve spent so long using whatever tool it is. My fingers know what to do. The point about understanding a tool very well, no matter what it is, is that it becomes a lot of unconscious competence. So your fingers use the right key bindings. You know, when people say, what’s the shortcut for something in IntelliJ? I’m like– I have to imagine the keyboard and see what my fingers do because I don’t know what the shortcut is, but I know what my fingers want to do, right?
RD: It’s muscle memory, right?
TG: It’s muscle memory. And so once we get familiar with tools, once we find tools that work for our flow they kind of become muscle memory, and they become very integrated, and they become kind of a part of ourselves, and we don’t want people to say IntelliJ sucks because we’re like yep, I use it really effectively, and like if you say IntelliJ sucks it must mean I suck, which is not true at all, you know.
RD: It is interesting that everybody has their tools– everybody has their keystrokes memorized, but with AI it’s disrupting that productivity flow, right? You don’t need the sort of magic words or the keystrokes to navigate. Do you think we’re losing something from the productivity by losing that? Or is it all roses?
TG: I think we don’t know yet. I think we’re still very much in this very fuzzy area where we know AI is definitely going to change everything. And AI is here to stay the same way that higher level programming languages are. NoSQL databases, cloud computing. In the early days of all of those things, there was a lot of like, there’s a lot of hype, there’s a lot of people doing superuser type stuff, you know, and there’s a lot of people resistant to change and the truth is somewhere in the middle in terms of IDEs. And again, I think this is going to depend a little bit. Like if you’ve got an experienced developer who knows the IDE inside out, knows how to use the refactoring tools, knows how to do various things without thinking about it, they’re not going to be spending AI tokens to do that stuff. And why spend AI tokens on that stuff if you can do it quickly, reliably, deterministically inside your IDE? In terms of the folks who don’t have that kind of muscle memory or are not that integrated into their own IDE, I think that’s an interesting question. Like I’ve been thinking about, is there a way to teach developers where the balance lies? I’ve been thinking about like, is there a spending no tokens productivity course? It would be taught with the assumption that of course you’ll use AI for a bunch of other stuff. And of course you’ve got agents doing this stuff. But here the IDE is really good for these things. And I think that’s a great idea, but I think it’s very much going to depend on– that your team and what you’re doing and what your appetite for learning different tools is. So there’ll be some developers who are quite happy to use it for refactoring, the IDE for refactoring, and some developers who really just want to use maybe the IDE’s diff tools so they can do code review more effectively or whatever it is. But I don’t think the IDE is going away, but it’s true that its role is definitely evolving quite quickly.
RD: Yeah, I mean, it almost sounds like there’s a new role for it where some of the IDE shortcuts are skills that are built more deterministically, right?
TG: Yeah. If I ask Claude to refactor something for me, I want it to use IntelliJ’s deterministic refactoring tools. I don’t want it to do something I’m not expecting.
RD: Right. And I think one of the things I’ve seen is that for people who come up on programming with LLMs, it’s very easy to use the LLM for everything, right? I saw something where it’s like somebody asking, what’s a good LLM for converting a PDF? I was like, none of them, right?
TG: None of them or all of them, you know?
RD: Yeah. It’s like, that’s not the right tool. So how, you know, can we sort of revitalize what an IDE is for the folks who think in terms of just prompts?
TG: AI is different to any other kind of tool. Like when Docker came along, for example, I’m using Docker as an example because I found it– it took me years to figure out where it sits in the ecosystem because I hadn’t used it in my previous engineering role. And in my Java advocacy role, I didn’t really need to touch it. So it took me a while to figure out where Docker sits. And then like, and you have to play with it and you have to figure it out. But then you’re like, this is its niche. This is where it fits, right? And this is what it’s good at. And this is what it’s not so great at. AI is very different to that because it spreads all over everywhere.
RD: Right. It can do almost anything, right?
TG: It could do almost anything. And so you can use it for generating code or writing presentations or doing code reviews or debugging or probably writing Docker scripts and running your tests and identifying flaky tests. And I think that’s really cool. But I think that’s also its weakness. If you have very general models and you’re trying to do everything with them, it’s like a jack of all trades. It’s not going to do anything very well. I think each team is going to, each individual even is going to figure out like which AI tools work for them, how it fits into their workflow, how much they’re going to lean on the AI versus using an IDE or using a command line tool. The PDF example is a great example. Like I was generating PDFs with ASCII doctor when I was writing my book, but it took me ages to figure out how to do that because it was more complicated than I wanted it to be. But now I wouldn’t get an LLM to do that for me, but I would get the LLM to describe to me how to set it all up so I could do it myself. And so, yeah, I think it’s all going to be a case of like, finding the niches where it fits for a team and for an individual.
RD: Yeah. And I think we’re running to things where people are sort of realizing the burden of their token spend, right? I was at a conference where I think the Uber CTO said they burned through their whole year’s token spend in five months.
TG: And I think that’s interesting. And especially as some of the AI companies are changing their pricing models and there is a burden on the infrastructure, which we as developers don’t necessarily see, but someone has to pay that cost. To begin with, of course, we’re flinging everything at the AI. We want to see what it can do, what it can’t do. We see that we can delegate a bunch of stuff over here so that we don’t have to care about it. I think this is an interesting time because it’s a good time to start thinking about, to start appreciating the cost. Whether it’s financial or whether it’s environmental, even, or whether it’s cognitive, because there is a cognitive debt that goes on by delegating everything. Figure out where the costs are, which costs you’re willing to pay, and which ones, perhaps there’s alternative approaches that work better.
RD: So what’s the either new tools or old tools that will help out in the new AI workflows?
TG: Well, I actually don’t know the answer to that question. I can tell you that anyone who creates a developer tool is frantically trying to put AI in there somewhere. And there’s several reasons for that. One, people do see productivity improvements by using AI, especially for code generation, for example, but also for troubleshooting, code reviews, things like that. So AI does add improvements. Two, lots of enterprises have an AI budget, but not a tooling budget. So the tools they buy have to have AI in or they won’t get the budget for them. So it’s– I’m not going to say it’s an arms race, because that implies potentially that things are all getting better. There’s a bit of a pile-on at the moment about how all developer tools have to have AI, whether it makes sense or not. We’re still iterating through what makes sense and what doesn’t make sense. And then you have like Anthropic saying that they’re third party tools, they’re changing the way the API works or the pricing works or whatever. So like, tools that have been bolting on AI now might not be in the same position they were in a few months ago. So, yeah, that’s a really long winded way of saying I don’t know how to answer the question for that. I think we’re really in a very interesting time where everyone wants your attention. Everyone has an AI productivity tool. Every dev tool that was already out there has AI in it in one way, shape or form. And again, I think we really need to be– especially for engineering leaders and folks who are looking at purchasing stuff for their teams, we need to be very discerning about what problems do we have? How do we want to solve them? And then does this tool solve that problem? Because as techies, we’re always interested in tools to solve our problem. The IDE is a classic tool that solves a lot of problems, but a tool is not necessarily the thing which is going to automate a practice. By which I mean: you have a Jenkins server. That doesn’t necessarily mean you’re doing continuous integration just because you have a continuous integration server, right? You have an AI agent doing your code reviews. Doesn’t necessarily mean that you have a correct code review process or that you’re looking for the right things or that you even need code review. Like you might not even need it if you’ve got senior engineers.
RD: It sounds like you’re saying like, tools won’t solve culture problems, right?
TG: Exactly. And I think what happens is as techies and engineers, we run to the tools because that sounds comfortable to us, but we do need to step back and go, what is our problem? Where are our friction points? A lot of the AI tools or developer productivity tools are aimed at… a lot of them are aimed at code generation, of course, and some of them are aimed at things like troubleshooting, code review. But if we’re building stuff really fast, but we’re not building the right things, and we’re not, well, if we’re generating code for it, but we’re not able to test, build, deploy it very easily because of the load on our CD pipeline, which we never thought about properly. And if we’re not building the right things, because we just said yes to all these requirements, because we can generate code cheaply, then it doesn’t make sense to throw more tooling at that problem. It makes a lot more sense to step back and say, okay, what problems do we want the tools to solve? And then we can evaluate whether they’re actually solving the problem or not.
RD: I see a lot of folks trying to come up with tools for that. A lot of AI SREs, a lot of folks trying to sort of probably, like you said, make up for existing deficiencies in the CICD pipeline.
TG: I have some thoughts on this area. There are good tools that can help do things like speed up builds, speed up tests, give you observability over your build pipeline. Because a lot of people don’t even look at, you know, we wrote some code and we chucked it into production and we observe it in production, but there’s a big gap between we wrote some code and how did it get into production? So having some observability there is like super important. So yeah, so there’s lots of tools, or at least one tool that I know of, that can solve some of those problems. But I do, I just can’t help but think like– for some of these things, you’re putting a sticking plaster over things. I think a lot about tests, right, because I’m a big fan of automated tests. I love tools that can accelerate tests whether you’re running them in parallel, or whether you use machine learning to figure out which tests are valuable and only run those ones, whether you’re caching the results of tests you don’t need to rerun stuff, all of that stuff is great. But if your development team is writing 99– all your agents are writing 99% integration tests which take two minutes to spin up, run and then spin down again, of course, you need these productivity solutions to fix that problem. But you don’t need 99% of your tests to be like that. You just need the end-to-end test. And you could be running fast unit tests, which are more flexible and much faster and give you faster feedback. And they’re great for the agent as well, because if you’ve got a fast feedback cycle, the agent can write the code, run the test, see it works, and then iterate much more quickly.
RD: Do you have a sort of heuristic or a rule of thumb or way of thinking about to determine whether something is a sort of tool problem or a process problem?
TD: Oh, no, I don’t. But now you’ve said that, I feel like I should have.
RD: I mean, it may be one of those where it’s like either way you are looking at what the actual problem is. Like maybe it doesn’t matter whether it’s a tool or a culture problem. It’s just a problem.
TD: I think what’s interesting about this particular problem is I think this is where humans are really good. So I don’t think you could put, well, maybe you could put all the information into Claude and say, what’s the problem here? Is there a tool that could fix it? Claude could probably give you an answer. In order to prompt Claude correctly, you would need to say, my development team is this, our process flow is that, our stakeholders expect this, we have problems here. You know, it takes a human to be able to kind of look up at all of that stuff and even use their gut feel. The book Frictionless about developer experience and stuff, it talks about doing developer interviews at the beginning to find out whether developer experience is failing or could be improved. And although Frictionless is full of great metrics for developer experience and measuring it, one of the things I took away from that book is that the way developers feel is just as important as the actual metrics of how long the builds are or how long it takes to get to production. Because your developers, your engineering leads will be like, this thing is always painful, right? Or this thing, when I see this pop up, I just know my time is going to disappear, right? And those are human instincts from being on the ground and from experiencing it. So I don’t have a good heuristic. I do think this is where humans are really valuable.
RD: Yeah, I sort of feel like the pre-COVID best way to fix developer experience was the Friday keg because I’ve never gotten more information about the engineering team than like that Friday.
TG: My first 10 years as software engineer was all in London so you would finish work at six on a Friday and then you would go out for drinks. In fact some companies would give you free drinks on a Friday but only from six so that you stay until 6PM right, and you know, you– that’s when you would learn the most about the domain. That’s when you would learn the most about from the management point of view, what they’re worried about, what’s– you’d hear rumors about, what’s coming down the line, or, you know, you would hear from the other team, their problems, so you wouldn’t be like, “oh well, you know, it’s always the other team’s fault”, you’d be like, “oh, how can we perhaps solve some of those problems?” And this human communication thing is just surprisingly important.
RD: And that’s with everybody moving to remote work. I think people are trying to get that back through tooling. Do you have ideas on, on how to, you know, get that sort of back chatter for remote teams?
TG: It’s really important for remote teams to communicate and feel connected and I know I say these words, and it just sounds like it’s just words, right? It’s so difficult to do. I mean, I’ve been remote for 13 years, so I’ve been doing it for a long time, well before COVID. And I’ve been remote as an individual contributor, as a team member, and as a team lead, and as senior management as well. I know what it’s like across all of those things. In more leadership-oriented roles, it was unfortunately important to have way more meetings. It just– it just was. And obviously you have like, team meetings, but you also you need those informal one-on-ones, let’s just hop on a call, like, you know, even if it’s just it’s 9:30 in the morning and I don’t really feel like doing any work, I’m going to call Oliver because I know I can chat to him, and that gives me the connection. We might exchange some context or not, or it might make me feel like doing some work. The kind of thing when I went to Ford we would go upstairs to the coffee place, and sit down and have a coffee, and like you’re not at your desk, but you’re working because you’re exchanging information. So yeah, unfortunately it’s– it is Zoom and it’s Slack and it’s, you know, talking to humans. But it’s also it’s important to get together as well, so at this time of year normally at Gradle we have world meeting and we, I would be on site for a whole week
with a whole company, there’s like, how many people– a couple hundred people. And I’m always like, oh God, it’s like a week away from my family and I don’t really want to do this. And then I go and I’m like, oh no, this is excellent. I’ve got so much done. I learned so much. I met people. I understood more about how people communicate with each other and I can read this person better. In-person stuff is also just surprisingly important.
RD: So it’s sort of the messiness of that in-person conversation that makes it valuable where you’ll start on whatever has your stuff, this, this, this, and then far down the line, you’ll be like, oh. You just identified something we can work on solving.
TG: I do think it’s important as well. I quite like things like your Zoom meeting transcripts. So you don’t necessarily have to go to all of the meetings because you can kind of catch up on that kind of thing. It’s not always a replacement for meetings. It can help avoid some meetings. It can also help you not forget what you decided in those meetings and that kind of thing.
RD: Yeah. What do you think is the biggest… the high value problem for developer experience teams to fix today?
TG: I’m reading a lot of stuff at the moment and I’m getting a lot of the sensation of like, how to rework the software delivery lifecycle as it is for agentic coding. What does it look like? Is it fundamentally different if you’ve got agents instead of humans? Or is it just the same thing, but more of it? And related to that, this balance, maybe this is more of a personal observation. I think we need to get the balance between what the human value is and what the agents can do. I can tell you it’s not great developer experience to not have a job. That’s for sure.
RD: Sure. Yeah.
TG: For years, we were hiring developers, like hiring them a lot. And there’s always talk of like, do we have enough developers yet? And like, no, there will always be more work to do, regardless of how many developers we train and train up and all the rest of it. And so I can’t really see how even if we expanded our development capability by 100x by using agents, I can’t see that we need to get rid of any of our human developers in any way, shape or form. They might need to be redistributed across the company or across different companies, depending on what they’re doing and how they’re working. And we might have to rethink how we onboard people, how we train and mentor people. I think that’s really important. But fundamentally, I’m not just talking about seniors with like, design taste and experience and all that stuff, I’m talking about juniors who can ask brilliant stupid questions, like: why did you do it that way? You know what it– surely that’s– if i don’t understand this code, surely there’s a simpler way to do it. That kind of thing. Like, so, from another part of developer experience like do we still need human developers? Yes, yes we do. We need to figure out what they’re good at.
RD: Yeah and I think to that it seems like a lot of folks are sort of coming around to that view where it’s like, oh, we actually need the developers. But it does seem like we are past the point of the hiring sprees, right? Developers are no longer parrying all the recruiters every day.
TG: Yes. Although I read something today– I’m doing lots of reading because I’m preparing a new talk for next week. So all I do is read stuff right now. I read something today which said several companies are now spending significantly more on AI than on their human developers. And more importantly, not necessarily seeing an ROI on that, which is not to say AI is a waste of time. It’s back to what we’ve been saying. It’s like right tools, right job, which includes humans in the right place, doing the right things, deciding what the right process is, deciding the right way to use the AI. I don’t think you can just fling money at the machines and expect to scale. I don’t think it works that way. But we don’t know what the answer is yet. And I think that’s a really interesting problem I want to get more involved in. What is the developer experience these days? What are the key developer skills? How do we work really effectively with the machines to develop quality software that the users want that’s delivered in a timely way? That’s a problem. It’s not just about writing code. That has never been a problem.
RD: Right. That’s reducing programming to typing, right?
TG: Exactly.
RD: I also hear chatter about the sort of intensification of the developer workday, where it’s like, you are able to do much more, so you end up doing much more.
TG: Even with IDE, it’s a bit like that. I found that the more effective I was with the IDE, the more code I wrote. I didn’t use it to create more space for thinking. I just created more code. And when I worked at JetBrains, I got really efficient with my processes for managing my workload, figuring out deadlines, prioritizing, strategizing. And so I was actually working at probably about 95% capacity instead of like, I should have been working about 80% capacity because you need buffer, right? So I was really efficient. But what happens is if you have a day that you’re sick or your machinery breaks down or the person you need to talk to isn’t there, or you just like have a day, like everything goes to shit, right? And I think AI is the same thing. It’s like, the more tools we have, the more efficient we can be, the more our space gets filled. But what we have never really appreciated is we need the space. We need the freedom. We needed the commute to work to not work on the laptops. But when I used to commute to work many years ago, I would read books, you know? Sometimes it was novels, sometimes it was real books on computing. But you have that space to sit down and you’re like, oh, I know how to solve that problem.
RD: Yeah. And I think people talk about needing that sort of friction that gives space between work. And I think there is a productivity bias, especially in the US, where everybody’s asked to hustle and do more and do more. Is there a way we can build in that sort of friction, that buffer zone into the developer experience?
TG: Almost definitely. I’m reminded that I read Cal Newport’s Slow Productivity last year, or the year before. Um, it’s an excellent book because it talks about how truly productive people like Marie Curie and like Newton and all these people. They didn’t sit down and do a two-week sprint to discover gravity, they spent years sat down, inspecting the problem, they gave themselves time, and they went for walks, and they went on holiday, you know, and all of that kind of thing. Um, Jane Austen, apparently she was granted time to write and she was allowed to not do the household chores, which, for an unmarried woman in those days, like that was unheard of. But she needed that brain space. And it’s not just about sitting down and writing, it’s about thinking and formulating, right? Slow Productivity talks a lot about that and it talks a lot about how we use busyness as a heuristic to figure out whether we can take on more work or not. Stress, actually. So if we’re stressed, as a knowledge worker, then we go: no more work, thank you. And if we’re not stressed, we allow ourselves more work. And that’s why we’re constantly on this weird border of stress. We do need to build in the downtime, the blank space, the time to engage the default mode network. I think If you’ve been working from home, you’ve probably been doing a bit of this because although, you know, you don’t have that commute blank space anymore. I used to do things like when I’m doing the laundry, which I hate doing, by the way, but you’re hanging out laundry and you’re like, oh, there’s a thing, you know, or you go to the coffee shop instead of sitting in front of your desk. But you have to be really strict about that. You have to enforce the downtime the same way you would enforce, I have a deadline for Friday. I’ve got a meeting I need to go to. And that I think is where we who’ve lived through the hustle culture, we’re bad at that because we think we’re not doing anything.
RD: Yeah. And I think there’s sort of two sides to the sort of top down push for this. There’s push for outcomes. And especially now people are thinking about outcome engineering. But there’s also a push for, you know, time tracking and bossware. Is there a way to incentivize the sort of first one where it’s, it’s just like just looking at outcomes?
TG: Yes, however, I’ve seen a lot of organizations use outcomes incorrectly or suboptimally, let’s say. So the outcome is that you will work 40 hours this week. And you’re like no. It’s right and we are generally speaking across the board, not just in our industry, but as humans, pretty bad at thinking about outcomes, even in our industry. So I think we’re better at this in IT than many industries are. So for example, we just built this new house. It’s a beautiful new house. In many ways, it’s difficult to not think about outcomes. What is the outcome? I would like a house. I would like it to have plumbing, heating, a kitchen. I want the plumbing, heating, and kitchen to work. By “work” I mean, I want to turn on the buttons and it doesn’t, you know, you can break all of that down into actual things which, by the way, is not how the construction industry works. The construction industry works by the end user saying, “the button doesn’t work, come and fix it”. In the IT industry we have a much better chance to sort of say up front what the buttons are and what the plumbing means and what the kitchen looks like and… I like things like TDD and spectrum development. I don’t know what spectrum, but specification of automated specifications by which I mean tests to determine like, what an outcome from a development point of view looks like. When we’re talking about outcomes, like, so I’ve just recently been doing much more management of a marketing team. And when, when we’ve been talking about outcomes, it’s like the outcome is we have social posts and you’re like, again, that’s not an outcome. What do you want? Do you want more followers? And even if you have more followers, what does that mean? Does it mean more people are going to go to your white papers? What sort of call to actions are important to you? How does that translate to ROI? And generally speaking, businesses are not great at that because the stuff that’s easy to measure
is not the same stuff that’s actually important.
RD: What gets measured is usually what’s easy to measure.
TG: Developer advocacy is particularly prone to problems in this space because developer advocacy is this kind of weird thing. It’s not really marketing. It’s not sales. It’s not engineering. It’s sort of education. It’s also the kind of function that gets cut in a lot of organizations when the money’s tight because they’re like, we’ve got a group of people doing advocacy. I don’t know what that means. They don’t seem to be making any money. Let’s cut them. And then two years later, you find out why you need advocacy, right?
RD: Your outcomes are kind of vibes, right?
TG: Exactly. It’s things like awareness. It’s things like sentiment. It’s things like, basically how friendly do potential users feel towards your product or service? Right. And so, often that– and that can last for a long time, that can last for like several years after you fire your whole advocacy team up to the point where your existing users no longer have good documentation, people to call out to, good demos. They don’t see your face at the conference anymore so they don’t think you’re relevant anymore, right? So– but measuring that is really difficult. We often get measured on things like number of blog posts read, number of subscribers on the YouTube channel, number of views of the video. They’re okay as proxy measurements, but they’re not outcomes and they’re not the value that you get from having developer advocacy specifically. So this– this is where a lot of my experience is but it applies to almost any function that isn’t basically sales. If you’re not in sales, how do you measure what outcomes really move the needle for the enterprise? Who even knows? If anyone’s interested in IntelliJ IDEA, we did do a lovely documentary on the history of IntelliJ IDEA, which I was on that documentary. But also when I watched it, I’m like, oh, this is really fun. It was cool. It was interesting to see the evolution of a tool that so many developers have used and loved.
RD: That documentary was from the fine folks at Cult Repo. We had them on the podcast a few weeks ago. You should all check it out.
[music]
RD: Well. Folks, it is that time of the show where we shout out somebody who came on to Stack Overflow, dropped some knowledge, shared some curiosity, and earned themselves a badge. Today, we’re shouting out a famous question badge winner. It’s somebody who asked a question that got 10,000 views. And because we started talking about IDEs, got an IDE question. Congrats to Sitalau for asking VS Code SSH keeps dropping connections, but I can SSH just fine. Curious about that? We have the answer for you in the show notes. I’m Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow. If you have questions, topics, concerns, et cetera, et cetera, you could email me at podcast@stackoverflow.com. And if you want to reach me directly, you can find me on LinkedIn.
TG: I’m Trisha Gee, Java champion, developer advocate. Well, you can find me at trishag.com. You can find me on LinkedIn, on X, Mastodon, BlueSky. I’m generally Trisha underscore G. And yeah, reach out to me if you’ve got anything you want to talk to me about.
RD: All right. Thank you for listening, everyone. And we’ll talk to you next time.
[outro music]