Interview with Trisha Gee at GOTO Chicago 2015

Hi, it’s Mike with UGtastic. I’m here at GOTO Conf 2015 and I’m sitting here with Trisha G who gave a talk about leveling up your automated tests. Thank you very much for taking the time to speak with me. So, leveling up your automated tests, what is, can you tell us more about that? Sure, so I, it’s a long story I guess, but it was about when I had been working at a financial exchange where we were really anal about testing. We had like tests at every single level , we did test driven development, did our tests first, and I kind of got so used to working that way and I worked that way for about four years, that I assumed that all developers had evolved to work that way as well. And then I moved to a different project where we did automated testing, which is a massive step up from other places I’ve been in the past, but the automated testing was not as comprehensive as I would have liked to have seen. So, the talk is really about the story of trying to go from writing tests to tick the box of , yeah I wrote a test, to writing tests that have value, writing tests that do something useful, but not in a kind of, you must write tests kind of way, in a kind of way where as developers we go, all right this is kind of fulfilling if you like, or satisfying, or fun, or or whatever. So how do we get our mind into a place where tests is not like, oh god I have to write a test, but like, oh cool I get to, I get to experiment now, and this is where I start writing my experimental tests around the code that I’ve written. And it’s interesting because I just interviewed Jay Fields a few minutes ago, and he talked about unselfish tests, and he talked about motivation, you know, what is your motivation for writing the test, and it sounds like that is something along the lines of what you ‘re trying to figure out, is actually like, how do you go about evaluating what your motivation is? Right, exactly. So the talk is really around, I mean it’s a specific journey that we took, and a technical solution that worked for us, but the talk, the lesson really should be the journey that we took in terms of looking at what tests can do, what you think they do, what they can give you, why we weren’t doing the best job we could have done with the tests, and how we tackled each of those problems. And one of the main things is to realize that writing tests is not to check that the code that you wrote works, writing tests is for things like checking, it was to give you maintainability, read ability, documentation. Yeah, does it do what I expect it to do? Right, does it do, yeah, does it, does it document? Does it, does it document what the system should do, and you know, does it, does it handle these edge cases I didn’t really think of, and that sort of thing? Right, and you know, the last time we spoke you were with a different company, but now you’re with JetBrains, and, and they deal with such a wide variety of tools, they provide tools for, you know, Object C, through Java, through .NET, I mean, is that, is that reflected in some of the lessons you’ve learned with, you know, how you approach testing? Did that? I mean, well, so this particular talk was based on my experiences at Mongo, but the thing was that it was quite good, so we were heavy users of IntelliJ IDEA, and when we were using Spock with Groovy, which is a language which was not familiar to us, IntelliJ IDEA really helped us with that stuff, because it kind of helped us, helped guide us towards better Groovy practices, and helped us to write tests which were, which looked right and felt right, and so I guess, I haven’t been at JetBrains long enough to know the impact enough of that company on the testing stuff, but I have to say that using the JetBrains tools at Mongo really helped us write better, faster tests, and it gave us the feedback we wanted from the tests. Yeah, and going from using a tool to working at a company, I can’t think of a better testimony for, for how good the tools are. Right. It’s like, oh, I, I used this tool, it was so good, I want to work there. Right, exactly, and the, the great thing about working for JetBrains and the fact they make IntelliJ. So, I’m kind of looking at the IntelliJ stuff. Yeah. The IntelliJ tool set, plus also a bit of TeamCity and Ups ource, and a lot of these kind of enterprise-type tools that generally Java developers will be using in the real world, but all the stuff that I’ve kind of learned as a Java developer is applicable in this role. Right. Because, you know, I’ve been using this tool for a long time. I know that it’s great for this, and I know shortcuts are good for this, and I know there’s a lot of stuff that I didn’t know, and when I discovered it , I was like, oh, that’s amazing, it makes my life better. Yeah. So, my job now is to take all the stuff where I thought, wow, that’s amazing, and I’m going to put it on videos or on small animated GIFs and show it to everyone and say, look what you can do. Yeah. So, it’s, you’re getting to do a little bit more teaching. Yes. And sharing out. Yeah. So, I just drew a blank. It’s the end of the day at the end of the conference, so, but the role that you’re doing now is, you know, I want to just kind of dovetail into being a developer advocate and going on some conversations. Some conversations I’ve heard that had happened on Twitter that maybe described that the role of developer evangelist and advocate isn’t quite as well understood by the community as it is. Can I ask you some questions about being a developer advocate? Sure. What is it, what is that role? What does that job mean? Okay. So, I will answer it from my point of view. Okay, yeah. And one of the interesting things about developer advocate, developer evangelist is that it depends from job to job and from company to company, so, at MongoDB, what was very important to us was as evangelists, we were proper developers. We worked full-time normally on a code base that was used, for example, in my case, it was the MongoDB Java driver, and we would go out and talk about MongoDB the server and the Java driver. And that’s great, but you end up getting torn in two directions because you sort of have this full-time coding job, which is necessary because you need to have the, what’s the word? Practical. Yeah. I’m thinking in Spanish now. I don’t even know Spanish. You need to be– Practical? No. You need to be reputable and developers need to believe that you understand about development. But to be doing development, proper full-time development and traveling and creating content and writing blog posts and stuff is a lot of work. Right. So, at JetBrains, my role is much more around the, like you say, the educational side of stuff. So, I’m still doing coding. I’m still contributing, actually, to Morphea and to MongoDB . Because they’re open-source projects. Okay. I’m still writing my own projects. So, here I get to write projects which demonstrate something in particular. So, I’ve got a project which demonstrates Java 8, Lambdas, and Streams with, like, tiny, tiny services that you might call micro-sized. I’ve heard that term floating around in this conference. So, I’ve been writing some codes that demonstrate particular things. So, I really like, well, I wanted to see how Java 8 works in real life. Right. So, I needed a real Java 8 project, which I created. And I wanted to see how IntelliVentures works. And I wanted to see how Java 8 works in real life. Right. So, I needed a real Java 8 project, which I created. Right. And I wanted to see how IntelliVentures works in real life. Right. And I wanted to see how IntelliJ helps you write Java 8 code. Okay. So, I created that code for that. So, it kind of lets you drill into a certain sector of a topic. Right. And I can continue to maintain this, but I don’t need to because no one else is using it. It’s kind of fulfilled a goal. And I can now write a bunch of stuff around this. So, I have a talk around it, but I also can write some blog posts or I’ve also used it to create some screencasts to say, “Look, if you want to do some shortcuts in IntelliJ around creating Lambdas, you can do this.” Mm-hmm. It’s a real code that works to demonstrate that. So, a little bit of research and experimentation that might not have been in a job where you’re like, “Oh, I got a deadline and I have to deliver this feature.” Right. So, “Oh, and I also have to write a blog post.” Right. Exactly. It’s more like, “What can I write a blog post about?” Yes. Yeah. Yeah. So, that’s interesting how it kind of flips that on the head. Is that a common thing for developer advocates across… because you said you put the caveat. You’re describing your situation. Right. Right. How does that maybe different… I think some of the companies put… Some of the companies put more focus on content. I mean, content takes quite a long time to come up with. If I’m going to write a blog post about Java 8 features, for example, that could take… I mean, it could take weeks, you know? Right. To put together a good blog post. So, some companies focus more on that sort of content. Some companies, like I say, a bit more like Mongo, you tend to have a proper engineering role where you also have to deliver something engineering- wise. And for some companies, the developer advocate role is a role within marketing, and for some companies, it’s a role within engineering. For JetBrains, it is its own organization, which we talk to the product owners for each of the individual products, because we have to…and even developers for the products. So we have very close ties to the engineering team, but we ‘re also outside of marketing, so we talk to the marketing guys, too. And that’s nice. That allows us to balance…because marketing and engineering are two…have two differing goals, if you like. Yeah. Yeah, slightly. One is to, like, deliver the product, and the other is to tell a story around the product. Yeah. And…but the engineering will get the product done when it ‘s ready. Yeah. Yeah. And marketing deadlines are slightly different. Yeah. And being sat in the middle allows us to kind of balance those things up. But we do have deadlines, as well. Our deadlines aren’t, like, your boss saying, “Deliver this feature by X,” but our deadlines are, for example, there’s going to be a new release of Ups ource next week, so I need to get a screencast of the new features in Upsource done by the end of…by, yeah, Tuesday next week. So you live a little bit closer to product cycles… Yeah. Yeah, definitely. …versus just marketing initiatives. Right. I mean, but it’s still a dovetail. It still dovetails into a marketing initiative. Right. But it’s kind of once the engineering team have done what they’re supposed to do, and we get involved with them earlier on, so I’m using early access versions of, like, most of the software, so I can also…I often end up feeding back, you know, occasional bugs come up. Yeah. Because that’s the point about an early access program, right? Yeah, yeah. You’re pushing the boundaries in some places. Yeah. So I’m, like, trying to figure out how new features work, and I’m, like, saying, “Oh, this doesn’t appear to work,” and often it’s me going, “Oh, I didn’t really get the right angle.” Yeah. …for that feature. Or sometimes it’s, like, “Oh, we haven’t quite thought of that,” or maybe we can replace it this way. Mm-hmm. So I get to feed stuff back in there as well. So that’s quite cool because it’s…well, I mean, it’s more like being a user than a developer, but…so I get to input a little bit into that. Yeah. But also, being a developer, you’re quite sympathetic. You’re not, like, “It doesn’t work. It’s a bug.” Yeah. You’re, like, “Well, I’m trying to document this feature, and I’m not really sure how it works.” Yeah. And then you speak to the developers, and they’re, like, “ Oh, it should be like this.” And you’re, like, “Okay, great.” And then because they can explain to me what it’s supposed to do, and I can think, “How would a developer use this?” Then I can document it or screencast it or whatever in a way which will hopefully make it usable for future users. Okay. Well, thank you very much for taking the time to speak with me. Thank you very much. Thanks.