#10 - State of Java & Code Review Best Practices - Trisha Gee

Episode Introduction [00:00:42]

Henry Suryawirawan: Hey, hey, hey, welcome back to another episode of the Tech Lead Journal with me your host, Henry Suryawirawan. Time passes by so quick, and I’m extremely happy to reach a new milestone for this show. Today’s episode is Tech Lead Journal episode number 10, which is its first double digit episode! Special thanks to all of the great guests who participated in the show, and I cannot thank you enough for your trust, support and sharing of your knowledge and wisdom with me and all the listeners out there. I have also been genuinely humbled by some of your comments and feedback, either through direct messages or the social media channels, and I would continue to do my best to produce great contents for all of us to learn from. I have some exciting guests for the upcoming episodes. And I’m looking forward to releasing those episodes in the upcoming weeks. If you have been liking the show so far, please consider leaving me your comments and feedback, and I would greatly appreciate it. And if you’d like to pledge your support and make contribution to the show, you can do so through our patron page at techleadjournal.dev/patron.

Our guest for today’s episode is Trisha Gee, a Java Champion, author, and the leader of Java Developer Advocacy team at JetBrains. She has an extensive Java experience with an expertise in Java high performance systems. Trisha is exceptionally passionate about sharing things that help real developers, which includes getting them up to speed with the latest version of Java, teaching them tips and tricks to save time with IntelliJ IDEA, or promoting healthy technical communities across the globe. Trisha is an author of a few books: “What to Look for in a Code Review” and “97 Things Every Java Developer Should Know”. Trisha also produces a monthly newsletter for JetBrains called “Java Annotated Monthly”, which is a great monthly summary for all things happening in the Java world.

In this episode, I had a chat with Trisha about the current state of Java, and how it stands compared to other programming languages. She also gave some good tips on how to transition from old Java version to the latest Java version. As a long time Java developer, I have to admit that my Java knowledge is still stuck in Java 8, while the current Java version is version 15! And looking at the recent surveys, it seems that the majority of us Java developers still use Java 8. So make sure to listen to Trisha’s tips.

Trisha shared about some of the code review best practices and explained why reading code is harder than writing it, and that we should put more effort in making our code more readable. She also suggested why a developer should use an IDE, and how using an IDE could help in increasing your productivity and producing a more readable and idiomatic code. Trisha also shared some of her lessons learned from her recent transition to become a team lead. I hope that you enjoyed this episode and I’m looking forward to hearing your comments and feedback. Let’s get started right after our sponsor message.

Introduction [00:04:27]

Henry Suryawirawan: Hey Trisha, it’s great to have you in the show. So welcome to the Tech Lead Journal.

Trisha Gee: [00:04:31] Well, thank you for having me.

Henry Suryawirawan: [00:04:32] So Trisha, I’ve seen you a lot from my journey in my career. I used Java a lot in the previous jobs. You have been the public figure of the Java world and also JetBrains. I’m also a JetBrains users for a long time. It’s really great to have you in the show and hopefully you can share some of your knowledge and probably the state of the Java world and what are you up to these days?

Trisha Gee: [00:04:51] I would love to share all that stuff. I’m happy to talk about pretty much anything.

Career Journey [00:04:54]

Henry Suryawirawan: [00:04:55] So maybe before we start, can you share your career journey so far, and also highlighting some of the major turning points that you have in your career that probably are interesting for the listeners here to learn about you?

Trisha Gee: [00:05:05] I’ll try to give the abridged version cause I don’t want to give you like the 20 year version. I came from a traditional-ish background for a programmer, in that I did a Computer Science degree, did Computer Science and Artificial Intelligence. I picked that because I was doing computing at between 16 and 18 in high school, and I figured I really liked the programming actually. I was originally going to do physics, astrophysics, but I really liked programming. So I decided to do Computer Science at university. We were the first year to study Java at university, this is like 97, and we were studying Java 1.2 and then I graduated in 2001, kind of just at the dot-com crash. But I had a bit of experience from doing some undergraduate work at Ford Motor company, that was actually using the Microsoft stack. That was fortunate because I had a little bit of experience, so even though I was a new graduate, I managed to get a job fairly easily in London. From then on, I was basically doing Java because I had my Java experience. JSPs and servlets were coming into their own at that time. I was doing web development for five years or so. Then I ended up moving into backend Java stuff and financial markets and working for banks and stuff, cause I was in London and that’s where all the jobs were. I deliberately moved myself to the backend from web development because again, at that time at mid noughties, that’s where you get taken seriously as a Java developer, rather than on the front-end. And then, I spent a bit of time doing consulting, again, Java development for the banks.

Then I worked for a company called LMAX for four years, and that was a financial exchange in London. And that completely changed my career. Because until then I was doing fairly standard Java development stuff, nothing wrong with that, your normal nine to five development doing consulting, working for the banks and things like that. I’ve been reading about agile. I’ve been reading about automation and things like that, but I hadn’t really seen a lot of that stuff done in the real world. And then when I worked at LMAX, I was working with Dave Farley, who was at the time were writing the “Continuous Delivery” book and we were doing Continuous Delivery. I was working with very talented team where we were doing pair programming. So I learned so much in terms of design, in terms of well structured code, in terms of readable code. I’d always commented my code because my memory is terrible. And when I worked at LMAX, and was pairing with people, they helped me write code that didn’t necessarily need comments. They use their tools to refactor stuff if the naming didn’t make sense, and this is where I really leveled up my IntelliJ IDEA knowledge, because when you pair with people and you see them using the tool properly, then you get what it’s for and you get that it’s not just an editor. You understand that you can refactor on the fly and it won’t break anything. You understand how to write tests first and have the tools generate the code for you that will keep things green, and so you work in what I now think of as the correct way, whereas before I wasn’t using the tools to their fullest extent. When I was working there, we were doing a bit of what we now call developer advocacy. I worked there from 2009 to 2012, and so I was doing a bit of developer advocacy for them, because Dave was speaking at conferences on Continuous Delivery and the stuff related to his book. His boss, Martin Thompson, was speaking at conferences about performance in Java because we were writing this low latency financial exchange in Java, which at that time no one did. Everyone did all of that stuff in C and C+, but Martin realized that the power of the JVM is especially with runtime optimizations and stuff, you can actually get very high performance from Java code without having to contort yourself writing high performance code. You just write clean code and the JVM will do the rest for you. So he was speaking at conferences about mechanical sympathy, about high performance Java code. I was tagging along with them and I was blogging about the Disruptor, which is this open source Java framework that we created at LMAX. This basically opened up a whole new world to me in terms of blogging, in terms of conferences, in terms of developer advocacy. After that, I left to join MongoDB so that I could be a developer advocate and that was going to be my role.

I worked for MongoDB for two years, doing open source stuff and big data and NoSQL and things like that. When I was there, I was doing live coding, live demos, again, using IntelliJ IDEA because that’s what I love. And so JetBrains came to me and said, “Why don’t you come and do that for us? Since you seem to actually know the tool really well. We want a developer advocate. This is what you do.” And I was like, “Well, that makes sense.” Cause at that time I was doing 50% engineering and 50% advocacy. It was just impossible because the two sets of deadlines don’t work. You have release deadlines, you have hard deadlines for the engineering side, you have hard deadlines for the conference side, because there’s always a CFPG dates, conference dates. Those two sets of deliverables are not compatible and you can’t plan around each other. So I decided that being a full time advocate, but still doing the engineering, more in terms of smaller projects, learning projects, tutorials, that kind of thing. That’s where I keep my engineering hand in and just do full time developer advocacy. Teaching in the JetBrains way is not to teach IntelliJ IDEA, but to teach programming in IntelliJ IDEA, which again, conforms to what I want to do. I want to help Java developers become more effective Java developers. I don’t need to teach them how to be effective IDE users, that’s not helpful. What you want to do is you want to write code for your organization for your project. You don’t really care about knowing a tool inside out. But if you can learn a tool to do your job better, that’s useful. And so that’s the brand of advocacy that I’ve been doing for about 6 years for JetBrains now.

Team Lead Lessons Learned [00:10:04]

Henry Suryawirawan: [00:10:04] Recently you mentioned to me that you just got promoted to a team lead. Maybe you can share the journey, how you got promoted and maybe what have you learnt throughout this journey?

Trisha Gee: [00:10:14] So that’s really interesting, actually, I kind of always wanted to be a lead. I don’t know if that’s just you always want more responsibility, because you want more money, or you want a better job title, or if it’s because I actually want to do the leading side of stuff. I’ve been a professional for 20 years or so, and one of the things I’ve learned over those 20 years is that the skills you need as a lead are not the same skills you need as a good programmer. So for me, there’s always been a tension between “do I want to leave some of the engineering behind?” Because I know I have the skills for leading, but then I won’t have the engineering. I’ve done some team leading in the past of small teams on small projects, and I’ve always liked that as long as I can stay hands on in terms of being a deliverer as well. But I’ve never really progressed up that whole path, probably because the code keeps pulling me back. I can see the end goal is being CTO or something, I’m not really sure that’s for me.

When I joined JetBrains, there were two developer advocates for IntelliJ IDEA, but the other one Brandon, he left fairly early on. I was the only advocate for IntelliJ IDEA for maybe 4 years or so. We hired Mala at the start of last year. The overall developer advocacy team for JetBrains grew. When I joined, there was maybe 10 or 12 of us. And by the end of last year, there was maybe 20 of us, and my boss was managing all of that. I asked my boss, “Can I manage the team?” Because I think I could do this. And he’s like, no, but what we will do is we’ll split the advocacy team into smaller teams, which makes way more sense because managing 20 people is not feasible for anyone. He split us off into the job advocacy team, which was me and Mala at the start of this year. And then he also tasked me with hiring another person so that we become a proper team rather than just two people doing the same stuff. Technically I was leading Mala, but when there’s only two of you, you’re not really leading so much as mentoring, obviously, because I’ve been at JetBrains for a long time and I’ve been doing developer advocacy for longer.

My focus as lead since January has been much more mentoring, teaching, helping Mala to grow in the direction she wants to go in. She doesn’t have to become a mini Trish. She has her own strengths and I want to help her figure out what they are and leverage them. And then we hired Helen in July. Helen comes from a slightly different background. She’s been in industry for 20 years and she’s worked with a lot of Java development teams. She’s had a bunch of different roles, but she’s come more from a technical writing point of view. And I thought that was really interesting because what I’ve done is I’ve hired a developer advocate with stronger advocacy skills than perhaps recent experience in the engineering side. Whereas what we normally do is you normally hire an experienced engineer and teach them the advocacy side of stuff. One of the things I’m doing as a lead again, it’s all about mentoring and learning and growing for everybody, is I’m trying to help her see the strengths she already has in the advocacy side of stuff, because she doesn’t think of them as advocacy skills, because that’s not the job title she had before, but they are absolutely advocacy skills. We’re talking about writing. We’re talking about teaching. We’re talking about influencing. We’re talking about all of those kinds of things, which is, generally speaking, difficult for engineers to necessarily learn. Gross generalization. Let her see that’s her strengths, that’s what she’s already got and then work a bit on the engineering side. She comes from an engineering background. She’s worked with engineering teams, just modernize those skills cause it’s been a while since she’s done them.

My role as team lead in my mind is very much about, it’s not about being the key deliverer. I do know IntelliJ better. I have more industry experience as a Java programmer than both Helen and Mala, just because I’ve been around for longer. But it’s not up to me to do all the hard stuff. It’s not up to me to do all the key pieces. It’s up to me to step back from that and help level up the two members of my team. Because if I’m doing all of that stuff, they’re not really able to contribute as much. For me, a team leader is first and foremost, a mentor, a teacher, and level-upperer. That’s how you get 10x programmers, that the senior programmers are people who help the 10 developers around them get better. I’m still fairly new to this though and I’m interested to see, this is really a bit of an experiment the way that I want to run the team. The focus very much on mentoring, on teaching each other. I have a lot to learn from Mala and Helen as well. One of the reasons I want to work with them is because they have skills that I don’t have. I don’t see it as I am their boss and I tell them what to do. I see it as I have a bunch of experience in certain areas like working at JetBrains, like IntelliJ IDEA, to some extent the Java industry, but Mala has way deeper knowledge on Java, what’s coming new in Java. I can learn a lot there. She’s a book author, which I’ve never done before, so I can learn a lot about writing from her. Helen has done a lot of industry writing, so she writes very effectively and very quickly. She understands how to identify the user and how to speak to that user, which is a skill that we can all learn from. My goal for the team is for us to all level each other up, and figure out what our strengths are, figure out what our weaknesses are. Some weaknesses is like, well, let’s not do anything which touches the weak area. And some weaknesses are, this is something I’d like to strengthen. So just identify those kinds of things and help us grow.

Henry Suryawirawan: [00:14:44] So I can totally understand your journey because a lot of aspiring software engineers also would want to be leaders at some point in time. But I think the biggest challenge, like what you mentioned, is switching from an individual contributor mindset where you be responsible of what you’re delivering and also the quality and all that you want to do the best. But once you step up to become a lead, that switch, sometimes it’s not natural for many people. Do you have some tips for them?

Trisha Gee: [00:15:07] I think the longer you’ve been an individual contributor, the more difficult it is to let go of that because you’ve been doing it for so long. 20 years of individual contributor, and you are usually very good at what you do, and faster at what you do, and so used to doing that. Often when the team is given a task, you’re like, “Well, I could do that and I’ll just get it done.” You have to think very hard about “is that the right thing to do?”, because by that point probably got 10 tasks that you could do in a day, and your team has one task each, which might take them four days. But, if they don’t learn those things, you’re always going to have 10 tasks that you have to do, and they’re always going to be underutilized. One of the things that I’ve been trying to do is, your team is not going to do that task the same way that you would do it. And that’s the first and most important thing to learn. For example, when Mala first came on board and she’s writing about topics that I often write about, like what’s new in Java. She does it in a different way to me. My initial instinct is, “Well, change this, do that, shorten this.” I want to turn her into me. I want her to do it in my style, and you really have to resist that. You have to sit back and think, “This isn’t a piece that you could have written. This is a piece for the users. Does this give the users some value?” Her style is different. My stuff is for the developer who is senior-ish, has stuff they need to do, and they need to do it now, and they just really need to know only what they need to know to fix that problem. My stuff is generally short, snappy, in your face and it shortcuts a lot of the background, because it’s all about the delta between where you are and where you want to be. Mala’s stuff is much more in-depth. So my instinct is to say cut all of that down. But actually Mala’s audiences is a slightly different audience. She goes more in depth. She goes into stuff which is quite interesting. I don’t need it for my day job, but it’s interesting, and I might need it at some point. I read her stuff, “Okay, I wouldn’t have done it this way.” Does it add value? Is there audience for it? And then when you start to see actually her audience is a slightly different audience to my audience, you realize that your skills are complimentary. I can still carry on doing my thing in my way to my audience and she does her thing in her way to a slightly different audience and we reach more people. But you do need to step back. It’s not your piece. It’s not to be done your way. It’s to be done the team’s way, leverage the team’s ability. In an engineering team, if they’ve used a different design pattern, but it still works and it’s a recognizable design pattern, go with that. That’s absolutely fine. They don’t have to do it the way that you would have done it. If the rest of the team understands it, that is good enough.

Henry Suryawirawan: [00:17:27] That’s really great tips there. So I hope all the listeners who are switching to a lead role, could also switch your mindset in terms of, you don’t have to be the one who takes all responsibility, or for everyone to do your own way. Sometimes stepping back and also allowing the team to explore what they’re good at is also something that is great.

State of Java [00:17:44]

Henry Suryawirawan: Switching now to the Java world. So you’ve been doing Java for how many years now?

Trisha Gee: [00:17:49] If you count university, 25.

Henry Suryawirawan: [00:17:51] And I just read as well, another blog from JetBrains. It seems this year is the 25th year of Java. You have been there, seen a lot of things. But recently, I noticed that a lot of languages also popping up, taking some of the market share of Java world. So the first question, is Java losing popularity after such a long while?

Trisha Gee: [00:18:08] I think Java was losing popularity, probably before Java 8, when there was such a big wait between Java 6 and Java 7, with the Oracle acquisition, and it took a long time to get 7 out of the door. And then 7 was out of the door and it was nice. It had some nice features, but there was nothing groundbreaking about it. So really there’s a big gap between 6 and 8. I think it was about seven years or something. At that time, the relevance of Java started to fade a little bit. We had a lot of JVM languages specifically that were growing in popularity with Scala, and Groovy, JRuby, Jython, and all on the JVM. They were adding different types of features and different types of programming paradigms, like Scala embracing functional style programming. I think back then there was a bit of a concern around Java the language. Even then people realize the JVM platform is important. It’s got automatic garbage collection, runtime optimizations. It allows you to write the syntax for a language without worrying about the underlying platform, and of course, it’s “write once, run anywhere” as well. So the JVM, I don’t think was ever in any danger. But since Java 8, when we got lambdas and streams that took Java the language a big step forward in terms of embracing some modern styles of programming. Java 9 was a big release. There was a lot of concern around Java 9 because of Jigsaw backwards compatibility. It’s important to consider those things cause backwards ability is a key part of the Java story. But I think once some of the concessions that were made by the language developers, plus the libraries and frameworks doing the updates that were needed, I think that actually, for application developers, that’s not as big as scary a step as people thought it would be. Since Java 9, we’ve had a release every six months. Java 15 just came out. And for anyone who’s new to Java or who was using Java way back when, they’re gonna be like, “Wait, 15? What happened?” Most developer is still on Java 8, because that was the nice, last big release, but the reality is we’re on 15 now.

With the six monthly release cadence, it’s really interesting because we get predictable releases every six months, regardless of how many features are in them, regardless of how big the release is. Even Oracle was a bit concerned that maybe we might end up doing a release, which actually has nothing for the developers in, or maybe nothing at all in it. But the reality is that, by moving to six monthly release cadence, it means that we’ve got predictable releases, but Oracle also said that they found that, because there’s no big bang release, because there’s no crunch at the end, because it’s predictable. Cause it’s all about flow. I’ll work on the next thing, and the next thing, and my feature might not make it in this release, but it will definitely make it into the next release. Then it turns out that actually there’s quite a few features that go into each release, and each release has had some interesting language features too. The six monthly release cadence allows the language developers to put features in which are preview features. So they can say, look, it’s functionally correct, but we don’t recommend using in production because it will probably change. But what we want you to do is we want you to try this feature out now, and then we will change it if necessary, which is a much better way of getting feedback and allowing developers to influence how the language evolves too.

Java 15, for example, has preview features for records, which is really small data classes. It’s got preview features for pattern matching, for instance, which is quite a small feature, but pattern matching leads to a lot of interesting new reduction in boilerplate features that we can have in Java in the future. We have text blocks as a standard feature, which was a preview feature. So text blocks allows you to embed things like long strings of SQL or JSON or something like that without having to escape every single quote or whatever. These are things which can be more gradually introduced and experimented and iterated over. Text blocks took quite a few iterations to get right. They could have put multiline strings in Java 12, and just gone “that’s it, that’s what you’ve got.” And then we’d be like, struggling with this not great implementation of multiline strings, but actually what they did is they looked at it and when real developers gave a bunch of feedback on how multiline strings are working, and language developers went, “This is not providing the end goal that we wanted to provide.” So they took all of that out and started with text blocks. Text blocks is a really nice feature, it works nicely for exactly what we wanted to embed other languages, for example, in our Java code.

There definitely was a concern about the relevancy of Java but with the move to six monthly releases, with the introduction of preview features, we’re able to see the evolution of the language and the language is evolving faster. And we, the developers, get to influence the evolution of that language. So especially if we’ve been working with other languages, whether they are other JVM languages, like Kotlin, or real other languages like Python, or JavaScript, or whatever, then we can say, we have a thing in this other language that we really like, like data classes in Kotlin, now we’ve got records in Java, for example. I think the release cycle, the preview features, and the fact that a lot of developers are polyglot programmers and they get to bring their ideas into their preferred language, has really helped to energize Java. So I firmly believe that Java is not going to go anywhere anytime soon. It’s only going to continue in popularity I think.

Java vs Other Languages [00:22:47]

Henry Suryawirawan: [00:22:47] So even personally myself, I haven’t been following a lot since Java 8, I must be honest as well. Now it seems like 15, that’s a lot of things. But if you look back to the time, actually it’s not that big, because seven releases, that means probably around three, four years. So it seems like we have this kind of common misconception about Java now that things are moving rapidly, but also there are a lot of other languages coming in, new set of paradigm, new set of features. For example, Rust, Go and Kotlin are some of the most prominent languages this day. What are your thoughts about all these new programming paradigms coming up?

Trisha Gee: [00:23:17] So I will caveat this with, I’ve been programming Java since 1997. I have used other languages. I’ve used JavaScript. I originally programmed in BASIC way back in the day. I’ve done a little bit of C#. I think I’ve even done Perl and stuff. But again, like a lot of developers, if I needed to fix a thing I was doing, I do a little bit of a programming in that language. My main language is Java, so I know it inside out. So I’m always going to be biased, as in I don’t want to invest 20 years in another language. JetBrains created Kotlin so obviously I have a bit more insight into Kotlin than other languages. There’s a lot of things I like about Kotlin, particularly the goal of Kotlin from JetBrains was always to create a productive language for Java developers. It’s not like Scala, which you need to understand a bit more about how things work in real functional way. Kotlin is going to assume you’re a Java programmer and that you just want something with a bit less crap around the boiler plate. I also liked the fact that Kotlin is primarily on the JVM, although you can run it on other platform. So of course you get all the benefits of the JVM as well. You get all your runtime optimizations, garbage collection, and stuff. A lot of the good ideas in Kotlin are now available in Java. So we have records, we have var, we can use var instead of having to declare the whole thing. Kotlin was quite popular in Android when Android was stuck on Java 6, because Kotlin allows you to use Lambda expressions. But Kotlin gets to move forward and they’ve got coroutines as well. Kotlin has some interesting stuff for multithreaded programming, but we’re going to get preview feature of Loom in Java 16. Loom will be lightweight threads on the JVM, so that’s really interesting.

One of my viewpoints for this is that it’s great to have all these different languages because my favorite language Java gets to pick and choose the cool stuff and see what works for Java programmers, see what works from a backwards compatibility point of view and just really cherry pick the nice stuff. And with the now releasing every six months, do that in a incrementally faster way. We don’t have to wait three years for a big blob of language features that was relevant 2.5 years ago. I’m definitely on board with other JVM languages because you get to leverage all the cool stuff about the JVM platform. I don’t know that much about Rust. I do know a bit about Go. When I worked at MongoDB, they were very big on Go. They liked Go because it was one of those languages you could just get stuff done with. Similar reason that a lot of people like Kotlin, because there’s less boilerplate and you can write stuff that works the way that you want it to work. Go seems great, but at some point I feel that they’re going to wake up and go, “You know what? We do need different types of garbage collectors because there are different profiles for different types of applications.” So I often think that from the bottom up languages will end up rediscovering stuff that Java has already put into 25 years of development. Java has been incrementally improving that garbage collector. Everyone always has a go at Java because garbage collection and Java is slow and none of that is really true anymore. And the fact is the way they’ve built the platform, there are now multiple different types of garbage collectors. So you plug in the one that you want that works for your application, then you can configure your language to do what you want it to do. I feel like some of the newer languages, they will wake up to the fact that they’re going to need things like different types of garbage collectors. They’re going to need things that run on different platforms. I know that we’re all in the cloud now. Maybe we don’t care about our hardware. But ultimately Java is an interesting language for the cloud because you don’t care about the hardware. You just run it on anything wherever you want to run it and it will just work.

I think there’s space for lots of different types of languages. JavaScript, for example, is never going to die. JavaScript is here to stay, whether you like it or not. JavaScript has a really nice place too. Obviously it lives in the web. It’s great for scripting. It’s good for beginners. Even though I’m personally not a fan of dynamic languages. I used to do a lot of JavaScript development because I used to be a web developer. What I hated about JavaScript versus Java is, “Can’t the compiler tell me what’s wrong with this thing?”, instead of it not just freaking working. But a lot of people like to start with dynamic languages. Cause you just write it and you don’t get error. The other thing I was going to say is this whole world is just getting more and more programmed, more and more computers, more and more automated. There is definitely space for more than one programming language. If Rust grows in popularity, that doesn’t mean that Java necessarily has to shrink. If Python is growing, because it’s a great language for machine learning, that doesn’t mean that Java has to shrink in the finance world, for example. So I think there’s space for everybody to play.

Transitioning From Java 8 [00:27:20]

Henry Suryawirawan: [00:27:20] You got a good point there in terms of the JVM maturity, and more and more people relying on lots of libraries that are already being written, the ecosystem in the Java world also. You have a lot of application servers already running as well for longest years. One thing that I would like to ask, especially for me and those Java old timers out there, where we are still stuck in Java 8 mindset, and now seems like Java 15. What do you think are some good suggestions for us to move on from Java 8 and continue with the Java release cadence?

Trisha Gee: [00:27:49] I have a lot of suggestions. I do have a whole talk on this. If you want, I can share a link with you and you can put it in the podcast notes or whatever. I have a talk called “Beyond Java 8”, and this is a 50 minute talk where I give the TLDR of what has happened since Java 8, and some tips for migrating. There’s an interesting thing about how licensing works. When you’re migrating off Java 8, you actually have two options. You can migrate to Java 11, which is the next long term support release. Oracle has agreed to support one release for three years, every three years. So for enterprises who don’t want to upgrade every six months, because honestly, lots of people don’t want to upgrade every six months, then you pick the long term support release. So you want to move from 8 to 11. 11 will give you a bunch of nice features. Nothing really groundbreaking, but it gives you some nice stuff. 11 basically builds off 8. You get some more stream operations. You get better optional. You get unmodifiable collections. You get factory methods for collections. You get some just really nice little helpful language features. You get var as well in 11. 11 from a language point of view is a nice step forward from 8. It should be achievable to migrate to 11. You do have to go pass the bump of 9, but that should be fine for most people. The other alternative is if you want to get everything, if you’re happy to, I don’t want to say take risks. It’s not risky, but if you want to be upgrading every six months, then you go to 15 and then you keep upgrading every six months.

For me, what I really would like to see organizations and applications doing, is I really want to see them move to 11 now, because in theory, 17 will be the next long term support release. 17 will be coming next September, so I would really like to see people migrate from 8 to 11, take that jump, make the changes that need to happen, because I don’t want to see people jump from 8 to 17. I think that will be a big jump, in the same way that if you were jumping from Java 1.3 to Java 6, and that was very painful. I don’t think you want to jump from 8 to 17. I think you want to go 8 to 11, 11 to 17 or 8 to 11, 11 to 15, and then keep going up every six months. 15 sounds intimidating, cause it’s like a long way away from 8. There’s a lot of features. I don’t know if I’m going to be able to get the most of these language features, because it feels like perhaps a lot of stuff happened. But I would say go to 11, make the jump past 9. Make sure everything works. I’ve tried it with a few applications. It wasn’t too painful. Make sure you upgrade your Gradle or Maven. Make sure you upgrade all your dependencies. Make sure you address any compiler warnings before you do the upgrade. So do all of those upgrades first, then move to 11. And then, take a look and see if there’s anything in the more recent versions of Java that you want. But 11 from a language point of view, there’s not that many new features, which means that some teams will think, well, I don’t really see why I should take the pain of going to 11 since I’m not going to get that much. But I do think it’s a nice step. Make the jump so that you get off 8, take the small language features, and then when 17 comes along, you’ll be able to use probably, records will be probably a standard feature by then. So you’ll be able to get records, you’ll be able to get Text Blocks, you’ll be able to get pattern matching for instanceof. You’ll be able to get, perhaps maybe Loom, you’ll be able to get lightweight threads. So 17 is a really interesting release. So my advice is jump to 11 and then look at moving onto 17.

Henry Suryawirawan: [00:30:42] So it’s very interesting tips definitely. What I can see also from enterprise point of view, upgrading the platform, the JVM and all that, does it entail some kind of risk, and backward compatibility, and things like that, where they have to go all over again to test the whole applications, whether it works fine? From your experience, do you have any?

Trisha Gee: [00:30:58] Yeah, I’ve got experienced that when we moved from 1.3 to 6 in the bank. Basically at that time we released every three months and we had to set aside three month release window for no new features in our application. Obviously we were also using application server, like you were saying that the old world of using enterprise Java and application servers. So we had to upgrade our version. We had to upgrade our application server. We had to upgrade our dependencies. Then we have to upgrade our version of Java. Then we had to make sure that everything was still working. The most painful thing was upgrading the application server. Looking back now, I think that it was suboptimal for them to decide the upgrading application service was so risky that they would never do it. To be honest, they should have been upgrading that application server every time a new version came out, and then they wouldn’t have to do this big jump, and I think that’s true of everything. What I’m saying now, having worked with Dave on Continuous Delivery ,it’s much less risky to continually update, continually release, to continually do this stuff. If you do these big chunky things, it’s just extremely painful. I had a conversation with someone from IBM. She works a lot with application servers now in the modern world. She has a presentation, which is similar to mine about upgrading off Java 8, and her pain points are all around applications server, because a lot of enterprises are using application servers, and this is not a criticism of the the application server world. If you’re writing an application server, you have to wait for the new version of Java to come out before you can start updating your code as application server. Also, the application servers are usually using Java EE, which is also behind the SE version of Java. So there will be a big gap between. Jakarta EE 9 is only just coming out, and we’re on Java 15, and the Java EE 9 is only just really coming out. So yes, there will be a long tail. And my advice is literally just try and keep everything up to date as much as you can. Update your application server, update your version of Gradle or Maven, updates Spring. Because I remember when we had to update Spring with Java 5, generics came in. It was quite difficult because generics came into the language, but our frameworks and libraries didn’t support generics yet.

So again, you just have to update everything as you go along, as they become available. It’s painful, but enterprises don’t want to take the risk. They feel like it takes a lot to swap in a new dependency. They feel like you should have to test all of it. Of course, especially if you’ve got manual testing and that becomes very painful. So again, Continuous Delivery, Continuous Integration, automated testing, automated regression test, coverage, everything should be automated as much as possible. It’s really difficult with legacy systems. The system I was working on at the bank, I wrote the first unit test there. And that system was 10 years old. And it took me months to write the first unit test, because I had to put in place a framework to test it, because it wasn’t written with testing in mind. By the time I left, we got to 5% test coverage, which was a massive win, but it’s very difficult to retrofit this stuff. It’s difficult, it’s challenging.

Henry Suryawirawan: [00:33:41] Thank you for your story as well from your past experience. I think you mentioned Continuous Integration, Continuous Delivery, all these best practices about testing, automated testing as well. That’s a good idea for all of us here who wants to make leap, and jumped from 8 to 11 to 15 next.

Code Review Best Practices [00:33:56]

Henry Suryawirawan: Trisha, I know you also wrote a few books. One thing in particular that I have interest in is actually doing the code review. You have a book about, how to do code review in the best way. Can you share with us some of the highlights, what do you think are the best practices for doing core review? Because there are so many code being written these days. And there are so many new developers coming into the industry. What do you think are some of the things that you can share with all of them?

Trisha Gee: [00:34:18] So when I wrote that book, I do advocacy for IntelliJ IDEA, obviously. But JetBrains also has a code review tool called Upsource. And when I started doing advocacy for Upsource, they asked me to write a blog post on code review best practice. And I wrote 3000 words on code review best practice. Then I was like, “Oh my goodness.” And that’s just the highlights. Then I wrote a whole series of blog posts called “What to look for in a Code Review”. So I did that highlight of, you should care about security. You should care about bugs, obviously. You should care about readability. You should care about all these things. I split those out into individual post performance, and then put them together into a Leanpub book called “What to look for in a Code Review”.

I liked that, because at this bank, actually the bank I was just talking about, I was asked to review someone else’s code once, and I don’t really know what I’m looking for. It’s a bit like the team lead thing. I can tell this developer to write the code the way that I would have written it, but that seems a bit stupid, because all I’m doing is telling him how to write the code the way that I would write it. Surely if his code works, then it doesn’t really matter how he wrote it, as long as I understand what it does, and it works correctly. So I feel like in the industry, we don’t have a lot of guidance on what to look for in a code review. We don’t have a lot of guidance on what is a code review for. And we get told a lot, you should do code reviews, code reviews are a good thing, but we don’t really get told why and what to look for. That’s why I wrote that book. But then thinking more and more over time, I’ve been stung with code reviews when people have reviewed my code, and told me it’s rubbish, and then you get really upset about it. I’ve had the same thing from bosses who want me to rewrite my code the way that they would have written it. And I’m like, “Look, either tell me upfront the way you want it written, don’t just leave me or write it yourself.” Don’t tell me in the code review when I’ve been working on it for two weeks, that I’ve written it wrong, the design is wrong because it’s too late to tell me at the end that the design is wrong. You told me upfront, how you want it designed, or you accept the fact that I have written automated tests, they prove that it works and is readable. So you should just let it go, and just tell me the stuff that is a showstopper.

That led me to think a different thing, which is that code reviews are for different reasons. You have to understand the reason that you’re doing the code review to figure out what to look for in the code review. If your code review is literally gateway code reviews, the thing that happens at the end that says, “Should it go to production or not?”, which is a very common form of code review. If you’re doing that kind of code review, I don’t think you should be looking at the design. It’s too late. It’s far too late to look at the design because all you’re going to say is “Redo it all over again.” If you’re doing a gateway code review, you should be looking for, “Is it correct? Are the tests testing the right things?” All things that humans can look at, anything which is automatable, is your semi-colon in the right place. Who cares? Get a linter to do that stuff. It’s not important for a human to be doing that kind of thing. Automate as much as possible. The most important thing a human can do is, do the tests, cause there should be tests. Do the tests test the right thing? Because a human can read the requirements, then they can read the test and say, “Is the test actually testing that the code meets the requirements or is the test of some rubbish thing, which is testing something completely different?” For gateway code review, that’s the most important thing. Is the code correct? Does it do what it’s supposed to do? Is it code that I can live with later on if I have to maintain this code?

There are different types of code review as well though. I spoke to a bunch of people who are doing code reviews for sharing the knowledge amongst the team. When I worked at LMAX, a financial exchange, we were doing pair programming. So we didn’t have code reviews, cause there’s no point doing a code review if you’re pairing with someone. Because you’re telling them what they’re doing. There’s at least two people who know what the code does, and then you just share that. And we used to rotate pairs as well. So you just share the knowledge amongst the whole team. There’s a sort of code review where I just want to be able to read the code, what happened? What new design patterns came in? What changes got made? And it’s fine to suggest things like, “I don’t really understand the name of this, or I don’t understand how this works. Or could we have an extra test.” But with those sorts of code reviews, you’re not going to say, “You’ve done it all wrong.” It’s too late. It’s already there. It’s out. It’s in production. If you do want the type of code review, where it’s okay to say the design is wrong, then those sorts of code reviews need to happen right at the beginning, not when it’s finished. I’m thinking about how can you create a code review process, which is a bit like pairing. Because the nice thing about code reviews is asynchronous, which means that you don’t have to worry so much about time zones, physicality or any of that stuff. And particularly now we’re all working remotely, it’s much more important to do this. So I feel like there’s a potential for code reviews where you can sketch out your design with some test names, so the tests tell you what they should be testing. You sketch out the classes and the methods, and they’re stubs basically, they don’t do very much. And then someone can come in and say, “Oh, you know what, I wouldn’t put this class here, I feel like this business logic belongs somewhere else. Oh, I think that what you’re testing here, I don’t think that’s really what we’re trying to achieve. I think we’re trying to achieve something different.” So you really want to have that kind of feedback much earlier on. Not when someone’s invested two weeks in creating a piece of code.

Which leads to another point. Code review should happen. They shouldn’t be huge. If you’ve got 200 classes, they either never going to review that or they’re just going to say, “Yeah, yeah, sure, that’s fine.” They need to be small amounts of code. It needs to be a short amount of time, because if you’ve invested a month in the work, then you really don’t want to hear it’s wrong. So if you’ve invested three days in the work, and someone says, “You know what? I think perhaps this business logic belongs over here.” You use your automatic refactoring and IntelliJ IDEA. Move it around, move on.

Henry Suryawirawan: [00:39:00] I also feel that code review is like an art sometimes. There’s no like perfect guides, okay, here’s how you do code review properly, and everyone just follows it. Because obviously different languages, different type of applications, different skillset within the team as well, the experience that they have tend to matter. And I also see a lot of team leads, now it becomes their responsibility to do the code review for everybody. Do you think it’s a good thing to do for a team lead to review everyone? Or do you just want to rely with the collective mindset?

Trisha Gee: [00:39:26] My personal opinion, it depends on which sort of code of review you’re doing. If you’re doing a gateway type review, someone has to decide whether it’s good enough to go into production. And again, this happens in a lot of big banks or other regulated environments. You do need a senior person. You do need a senior architect or someone who understands the implications of saying yes/no. They need to be able to have the veto. But I don’t think that it’s the responsibility of the team leads or the senior people to be reviewing every single line of code. I actually think you should include at least one junior in all code reviews. And the reason being, if your junior can’t understand your code, you did not write readable code. It’s fine for a senior person to understand your code, cause they know the business logic. They know the framework. They know the niche things of your application. They understand it. You really want to cater to the lowest common denominator. You really want your juniors to be able to understand it as soon as possible. I would have everybody review code at some point, definitely. You want to split it amongst the team. But if you’re doing a gateway type code review, I would probably have at least a junior and a mid-level, a peer of whoever wrote it. They do the detailed code review in terms of, this doesn’t seem to be named very well, I don’t really understand what this is doing. Or this test doesn’t seem to map very well to what the requirements are. And then ultimately the senior person goes through all of those comments and any of the changes that might have happened, and then takes that, and signs that off. So it’s not up to the senior person to do the line-by-line stuff. Actually, it should be down to everybody to do the line-by-line stuff. It’s up to the senior person to see, “Did the junior and mid-level person, did they catch the sorts of things that I would be looking for?” And if so, does it look like everything’s been addressed the way that I would like them? So that relieves the burden off the senior person, and also helps to spread the responsibility amongst the whole team, and allows you to make sure that your code really is understandable by the whole team, and that the whole team learns what changes are going into the application.

Henry Suryawirawan: [00:41:09] Apart from the gateway review, are there any other reviews that you can mention for us to learn more?

Trisha Gee: [00:41:14] It depends a lot on the team and the application. In teams where you can trust that everyone’s doing the right job, or perhaps there aren’t that many new people on there, or they’re a high performing team, you just did the code review for learning. The pattern with that is, quite often, you’ll be submitting your commits, maybe even just publishing to main straight away. Your code review might select individual commits and put them together on a single code review, rather than having to look at the whole of main. One of the things with code review, of course, is putting aside time to do this. The whole team, every morning, let’s say you put aside 30 minutes to review whichever code reviews have come in from the previous day. You just literally look over the code and just see, “Do I understand it? Does it make sense? What sort of functionality just got added to the application?” And this is not a burden. This is not, “Oh, I have to decide whether this code is good enough to go or not.” This is a learning experience for you. If I have to maintain the new orders segment, do I understand what the new orders segment looks like and how it works? So it’s really for you to understand what’s going on in the application.

Henry Suryawirawan: [00:42:09] So you keep mentioning a lot of times about reading the code, making sure that everyone understand what the code has been written for. And you also wrote a blog post “Reading Code is Harder than Writing It”. So I’m sure there’s a thing that you want to send message across. What are the important thing for person who writes the code in terms of readability?

Trisha Gee: [00:42:26] I did a presentation about “Reading Code is more Difficult than Writing It” because this is off the code review stuff. So I was working with another person in JetBrains, Maria, and she was saying, look, it’s really weird, when we’re doing code reviews, one of the things about code reviews is it’s very difficult to read the code. We’re not taught how to read code. When we learn other languages, so Maria is learning French at the moment, I’m constantly learning Spanish because I live in Spain, you’d learn how to read it, you learn how to listen to it. You don’t necessarily learn how to write it. It’s absolutely the last thing that you learn. But with programming, we’re taught how to write it right from the beginning. And we’re not really taught how to read it, or we’re not taught to value the skill of reading it. If we read code and we don’t understand it, we often just say nasty things about the person who wrote the code, even if it’s us. So it leads into this constantly negative critical thing. Of course, the code you wrote six months ago isn’t as good as you would right now, because you’ve got six months of learning, the language better, the domain better, things have evolved in your applications. I know that’s not the way that you would do it now. Let’s accept the fact that things evolve, and things change, and that you would do things differently today than how you did them yesterday. That’s fine. Let’s not be critical of this. Let’s not accuse the person who wrote the code of not writing readable code. Let’s accept the fact that we need to learn how to read code and how to live in the code. Because most of what we do, even if we’re not doing code reviews, most of what we do is reading code.

When we’re trying to find out where the bug is or where we’re going to add the new feature, we spend 90% of the time reading the code, figuring out “What’s the design? What is the problem? What do the tests do?” It’s not that we don’t know how to read code, cause we do read code, but we don’t value it. We still see it as a waste of time. I’m not writing lines of code. I’m not writing stuff, so I’m not productive. We’re never measured on our ability to read code. But our ability to read code maps directly to our ability to write good code, because we know the right place to make the changes. We know how to write new code that fits in with the existing code. By reading our code base, of course we’re going to write readable code. If I’m reading a book in German and I decide this needs a new paragraph here, and I write a new paragraph in English, that’s dumb. You just wouldn’t do that. But and yet in an application, we quite often go, “Well, this is really old code and has an old dialect.” If you like, it’s an old style of Java. I’m just going to add a Lambda expression in here, because that’s a modern way of doing stuff. But that’s not idiomatic to this application. So although you’re writing readable code in some contexts, it’s not readable code in the context of someone who’s going to have to read this whole application. We talk a lot about writing readable code, we don’t talk a lot about what that really means, and how it applies to the rest of the team, to the rest of the application, to the dialect of the code, if you like, cause your code bases do have different dialects, and you still have to live within that, and accept it, not just try and change it all the time.

Henry Suryawirawan: [00:44:55] Yeah. Sometimes I think for all of us techies here, we do have this kind of buzzwords, or the up and coming shiny new features. We just, “You know what, I’m going to change the library. I’m going to use this new features. And we just dump it in the code. And yes, we did it.” So I think sometimes that’s not a good practice as well, like what you said. You have to be also adaptive in terms of what was the code written in the beginning, and just adapt to the style that it was written in, rather than changing, then confusing the other people who are reading the code seeing like a mix style patterns.

Using IDE [00:45:23]

Henry Suryawirawan: Trish, you’re also a developer advocate for JetBrains, so let’s talk a little bit about JetBrains. I know these days there are a lot of proliferation of text editors or code editors. Some are in the cloud, some are just different applications. Why do you think developers should use an IDE from JetBrains versus, for example, VS Code or probably Atom or things like that? Trisha Gee: [00:45:41] Again, this is going to be caveated with my background as a Java programmer. We generally like our IDEs. Granted, Java’s got a bit of boiler plate, so having code generation is helpful for us. The code navigation is helpful. Java is a statically typed language, so your IDE can give you a lot, because it can give you compiler warnings in line, you don’t have to compile a whole application. Static languages also allow you to do data flow analysis. Some of the stuff in IntelliJ IDEA’s so cool, because it goes, “This value will never be null.” You’re like, “Really? Okay, I trust you. I’m sure you’ve figured that out.” So I don’t have to worry about all the nuts and bolts. I just write the business logic. When the business tells me I need a button which allows me to place new orders, I just have to worry about how the flow goes through the system. Instead of worrying about the intricacies of checking this, or making sure this is the right type, or whatever. Given my background as a Java programmer, when I did C# programming years ago, I use Visual Studio, and I was like, “Oh, I don’t really understand this.” Then I found out about ReSharper. So I put ReSharper in there, and I’m like, “Oh, now I can navigate the code the way I expect to do it inside IntelliJ IDEA.” I know Visual Studio has come a long way since then, but still ReSharper is still one of the most popular plugins for that. The IDE allows me to have a set of skills to understand my tool, and that’s transferable to other languages. Now when I’m writing C#, I can use ReSharper to get the same sorts of suggestions, especially when I write Java style C#, and then it goes, “no, no, no, you don’t want to do that.” And what I do, I quite often write JavaScript in Angular and stuff like that, and I’m using WebStorm for that. Because WebStorm allows me to write JavaScript the way that I would expect to write Java. It gives me code suggestions. It gives me analysis. It gives me inspections and warnings. Especially if I’m using TypeScript, which I’m new to. It says “Oh, perhaps you want to do it this way.” I don’t have to go off, and research that, and learn that. I get the learning in line as I’m typing it when I need it. That’s what I like about the IDEs. It just gives you the knowledge that you need right now in that particular piece of code that you’re working on. As developers, we can always get code to work. Getting working code is not really the problem. Again, it comes down to idiomatic code, especially if you’re a polyglot programmer, and you’re going from language to language. When I’m writing Groovy, IntelliJ IDEA will say, look, of course it will work because Java works inside Groovy, but I wouldn’t do it that way. This is a more Groovy way of doing it. So it really helps you to write readable code, idiomatic code, and it will also tell you if you’re writing stuff which is inefficient. That’s just from the code point of view.

One of the things that I’ve been wanting to work on for ages, haven’t got round to yet, is a tutorial for using Git inside IntelliJ IDEA. I know most real developers use Git from the command line. I am not capable of that, cause I’m a visual person. I want to see the little dots. I want to see the branches. I want to see the timeline and I can work that way. IntelliJ IDEA has full integration for Git and GitHub. So I just do everything inside the IDE. And I can do my cherry-picking, my merging, my rebasing, and it all makes a lot more logical sense to me, cause it’s all inside the IDE. The IDE is not just about code suggestions and code analysis. It’s an integrated development environment. So I get integration with Git. If I’m using application servers, like we were talking about before, I get my integrated application server. I can debug inside my application server. I can even debug remotely. I can debug in the cloud if I want to. We have plugins for like AWS and Azure. I haven’t used either of them, but we have plugins for deploying to and debugging in the cloud, which is much more common these days. Everything is there and it all runs integrated. I don’t have to hop to a terminal, or to a different tool to do my Git stuff. I love the fact that all my database stuff is inside there. I want to be able to run a database query inside my IDE. I can run the SQL inside my Java, inside IntelliJ IDEA by saying, “Run this SQL”. And I don’t have to mess around with moving from tool to tool. So that’s what an integrated development environment does. I do see the value of code editors. If you want to pop into something, and make some changes, which happens all the time, particularly in production. You want to be able to quickly open up an editor and make those changes. And you do want syntax highlighting, and code completion for those sorts of things, too. So you get a lot of benefit from that kind of tool too. But for me, you can’t take my IDE from me. You can’t rest it from my cold dead hands.

Henry Suryawirawan: [00:49:27] Yeah. I can also relate to some of your stories. So when I learned how to write in Ruby. I also got suggested, “Hey, you should not do this, there’s this Ruby features.” Okay, just click shortcuts, then my code just gets transformed. I think it’s pretty nice. One way is that the code gets better and also I learn new things. Like you said, I also use Git from the IDE, instead of doing all these Git commands. So I find it quite efficient, just by pressing few key, and the thing gets done out of the box.

JetBrains Roadmap [00:49:51]

Henry Suryawirawan: What are some of the exciting trends, or products, or maybe focus areas, or innovations coming out from JetBrains? If you can share with some of us.

Trisha Gee: [00:49:58] It’s really interesting working for JetBrains. I’ve been here for six years. And we’re constantly evolving and moving forward. Given that our main product is IntelliJ IDEA, which is the main IDE for the Java world, it would be quite tempting to be like, “You know what? We kind of won. We’re kind of fine. We can carry on being the most popular IDE for Java, and carry on making money.” But JetBrains is an organization of a thousand engineers. And you know what engineers are like, they’re like, “Oh, we could do something cool. We could do something different.” We have a new product called Space, which is a team tool. It’s an integrated environment for team stuff. It’s got chat. It’s got issue tracking. It’s got Continuous Integration. It’s got code review. It’s all integrated into a single tool. We can do things like meeting tracking, and it’s got location of people in offices. It’s got the whole team, the whole organization in there. In theory, everything that you want to do with the people in your organization, you can do there. I think that’s still an EAP at the moment, but it is available.

We have just launched a very early EAP of collaborative development. I’m really excited about this, because this is remote pairing. It’s not quite remote pairing yet. It’s not, I have my IDE open, you have your IDE open, and we code in the same thing. But what it is is, you have your IDE open. You want some help from me or something. You want to pair with me on something. You send me a link, and that will open a lightweight client on my computer. It looks like IntelliJ. It acts like IntelliJ. But it’s not my IDE, it is a client. I can then hop in, and I can be coding inside your IDE. You can see my cursor and I can be like, “Oh, what if we do this? What if we do that?” We have loads of ideas on how to make this better. At the moment, I’ve been using it with my team in terms of, we usually have, something like Meet open, so we can be chatting, and then we can be coding at the same time. There’s some caveats to it at the moment in terms of, if I’m using a lightweight client on my machine, I shouldn’t have access to your terminal to run anything on your machine. There’s obviously security caveats on how we do stuff. That’s why we don’t have full access to everything in the IDE. But this is very exciting. And this is something that is obviously extremely relevant this year. It’s also our oldest bug in our bug tracker. We’ve had collaborative development open for like over 10 years.

I think that’s the most exciting thing we’re working on at the moment. We are looking for people who are interested in trying it out. We are actively looking for feedback. Obviously we’re using it ourselves. The products that we dogfood ourselves are the best because, we use IntelliJ IDEA to write IntelliJ IDEA. We use IntelliJ to write Kotlin. And so, we’re always improving those things. Now we have a thousand engineers working collaboratively out of the office, I expect this tool to improve. But also we’re really interested in getting feedback from real developers, and their real use cases, and what they do. By all means, we would quite like people to try this out. But be aware, that it’s early access. There’s a lot of work which needs to happen.

Henry Suryawirawan: [00:52:32] I’m also one of the voter for that bug that you mentioned. Especially, for us now having to work from home, and we rely on just doing remote. So all these pairing, and co-editing, or screencasting of the code that we are working, I think it’s going to be useful. And I’m very excited to hear that this product is there, as an EAP, but still good enough. Probably, I’ll also check it out. And for those of us who wants to learn how to do this on IntelliJ or JetBrains products, make sure to check it out.

3 Tech Lead Wisdom [00:52:58]

Henry Suryawirawan: Trish, It’s a pleasure talking to you. Obviously we learn a lot about Java, about JetBrains, about code reviews. I have one last question that normally I would ask for all my guests here in the show. Would you be able to share with us 3 technical leadership wisdom, probably for all of us to learn as well from you?

Trisha Gee: [00:53:13] I guess my primary technical leadership wisdom bit is the thing I talked about earlier. As the leader, it’s not your responsibility to do. It’s your responsibility to teach and help your team to level up. And that’s probably the hardest transitioning to make. And you just have to constantly remind yourself that, of course you could probably do it faster, maybe even better. But that’s not what your job is. Your job is to level up your team, so that you have a team of people who can do it better and faster.

Another piece of technical leadership. When you’re a leader, you’re just not going to have as much time. You’re just not. You’re going to be in meetings. It’s your job to network. You are going to be the umbrella for the team. You have to go to the meeting so that not everyone in the team has to go to meetings. You have to be the filter for information. You’re in those meetings, so that you learn stuff from the rest of the organization, or from outside the organization. Your job is to filter through all that information, and make sure other people know it too. You are the umbrella for the team. You don’t want to distract the team, but you also do need to remember to feed on some of the valid information, so that they feel like they’re in the loop, and that things don’t take them by surprise.

Not everyone is going to make a good leader. That doesn’t mean that you’re a bad person. It doesn’t mean that you haven’t grown. It doesn’t mean that you haven’t progressed. Sometimes you want to try leading, but it’s a different set of skills, especially as an engineer. If you’re a great developer, you might not want to be a leader. It’s not great in our environment, because in our industry, we still tend to reward late leaders and managers with more money and more bonuses, not necessarily doing more. You might just want to keep paying the star engineer more money, not encourage them into a leadership role. They might not have the skills for that. And it’s fine and I think that should be fine. We shouldn’t always be poking senior people up into senior positions. They might just be much more effective as an individual contributor.

Henry Suryawirawan: [00:54:49] Thank you for sharing your wisdom. So Trish, where can people find you online?

Trisha Gee: [00:54:53] I’m active on Twitter, trisha_gee for Twitter. I do have a GitHub, which is trishagee. I relaunched my website, trishagee.com. I’m blogging again. I haven’t blogged for the longest time. So that’s probably a good place to find me. I’m usually at conferences, but not this year.

Henry Suryawirawan: [00:55:08] Okay. So I’ll make sure everyone check out all your Twitter, website and all that. I’ll put it in the show notes. Thanks again, Trish, for spending your time with us. It’s really great to see you, and also hearing from what you have learned, and what you have been doing in the Java world. So, thanks again.

Trisha Gee: [00:55:21] Thanks very much for having me. It was really fun.

– End –