As a leader, it's not your responsibility to do. It's your responsibility to teach and help your team to level up. Your job is to level up your team so that you have a team of people who can do it better and faster. Hey everyone. My name is Henry Surya. Juan. And you're listening to the tekhelet journal.
The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hey, hey. Hey, welcome back to another episode of the tekhelet journal with me. Ojos, Henry Surya.
We do one time passes by so quick, and I'm extremely happy to reach a new milestone for this show. Today's episode is technically Journal episode number ten, which is its first double-digit episode Special, thanks to all of the great guess who participated in the show and I cannot thank you enough for your trust support and sharing of your knowledge and Them 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 content 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. She ate it and if you'd like to pledge your support and make contribution to the show, you can do so through our patreon page at tekhelet journal, the death / Patron, Our Guest for today's episode is Trisha g, 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. 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 Go to listen to Trisha steps Tricia shared about some of the code review. Best practices and explain 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 ID 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 it enjoyed this episode and I'm looking forward to hearing your comments and feedback. Let's get started right after our sponsor message. Do you want to learn to code?
Do you have friends who are looking to learn how to code our sponsor at jetbrains recently? Launched jetbrains Academy and education platform that offers interactive Project based learning combined, with powerful, professional development tools, Advanced, your Java and python skills. With more programming languages to come to get an And it three month, free trial on jetbrains Academy.
You can go to technology. No dot, f /. Jetbrains Dash Academy. You can go to tekhelet journal dot, f /. Jetbrains Dash Academy. Hey, Trisha is great. To have you in the show. So, welcome to the Tecla Journal. Well, thank you for having me. So Trish. I've seen you a lot about my journey in my career. I use 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? I would love to share all that stuff. I'm happy to talk about pretty much anything. 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.
I'll try to give The Abridged version because I don't want to give you like the 20-year version. I came from a traditional Jewish background for a programmer. In that. I did a computer science degree did computer science. Special intelligence. I picked that because I was doing Computing at between 16
and 18 in high school. And I've figured I really like the programming actually, I was originally going to do physics astrophysics, but I really like programming, so I decided to computer science at University through 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.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 job or experienced JSP and servlets with coming into their own. At that time.
I was doing web development for five years or so, then I've ended up moving into backend, Java staff and financial markets and working for banks and stuff because 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 amid naughties 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 bank's, 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. But you normal 925 development doing consulting working for the banks and things like that. I've been reading about agile.
I'd been reading about Automation and things like that, but I haven't really seen a lot of that stuff done in. In the real world. And then when I worked at lmax, I was working with Dave Foley, 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 learnt 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 went to El maximize 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 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 And and 92 2012. And so I was doing a bit developer. Advocacy for them because Dave was speaking at conferences on continuous delivery in 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 the time no one did everyone did all of that stuff in C and C plus but Martin realized that the power of the jvm is especially with the runtime optimizations and staff. 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 a tell Max 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. However, mongodb for two years, doing open source staff 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 because 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 Hard deadlines for the conference side because there's always a cfp due dates conference, dates those two sets of deliverables, 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. Uppers 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 at all inside out. But if you can learn at all to do your job better, that's useful. And so that's a brand of advocacy that I've been doing for about six years for jetbrains. Now, recently, you mentioned to me that you just got promoted to a team lead.
Maybe you can share the journey. How you got promoted. Maybe, what have you learned throughout this journey? 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 to 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 and 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 say, Hands-On in terms of being a deliver 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 are two developer advocates for IntelliJ IDEA, but the other one, Brendan he left fairly early on. I was the only advocate for IntelliJ IDEA for maybe a four years or so. We hired Malla at the start of last year, the overall developer. Advocacy team for jetbrains. When I joined, I was maybe 10 or 12 of us. And by the end of last year, there was maybe 20 of us and my boss is 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 will split the advocacy team into smaller teams, which makes way more sense because managing 20 people is not visible for anyone. He split as off into the job. Advocacy team, which was me and Marla 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. Same stuff. Technically.
I was leading malar. 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 is leader since January has been much more mentoring teaching helping Malla 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, which has been an industry for 20 years. And she's worked with a lot of java development teams. She's had 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 engineering side. Whereas what we normally do is you normally hire an experienced engineer and teach them the advocacy side of Staff. One of the things I'm doing is a lead. Again. It's all about mentoring and learning and growing for everybody is. I'm trying to help her see the strength. She already has in the advocacy side of stuff because she doesn't think of them as advocacy skills because not the job title she had before but they are absolutely advocacy skills.
Talking about writing was from at teaching, were talking about influencing were 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 strength. 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 and just modernize those skills because 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 Deliver I do know IntelliJ better. I have more industry experience as a Java program and then both Helen and maladjusted 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 leaders is first and foremost, a mentor, a teacher, a level Opera. That's how you get 10x, programmers, that the senior programmers are people who helped the Ten 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 Malla and Helen as well. One of the reasons I want to work with them is because they have skills.
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 Malla has way deeper knowledge on Java. What's coming new in Java? Can learn a lot there. She's a book or so, 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 first all level each other up and figure out what our strengths are, figure out, what our weaknesses are some weaknesses. It's 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 Puss grow, so I can totally understand your journey because a lot of aspiring software. Engineers also would want to be a 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 delivering and also the quality and all that, you want to do the best, but once you step up to become a lead, that's which sometimes, it's not natural. For many people.
Do you have some tips for them? 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 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 a one task each which might take them for 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. 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 mallow 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 will 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 Is 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 their problem.
My stuff is generally, a 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 malice stuff is much more in depth. So my instinct is to say all of that down, but actually, malice audience 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 an audience for it? And then when you start to see actually her audience is a slightly different audience in my audience, you realize that your skills are complementary. 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 is to be done the team's way. Average, 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. 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 are good at is so something that is great switching now to the Java world. So you've been doing Java for how many years now if you can't University 25 and I just read as well, another block 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 the popping up taking some of the market share of java world. So the first question is Java, losing popularity after such a long while. I think Java was losing popularity, probably before Java 8, when there was such a big weight between 6 in Java 7 with the Oracle acquisition and took a long time to get 7 out of the door and then seven was out of the door and it was nice.
It has some nice features but there was nothing groundbreaking about it. So really there's a big gap between six and eight. 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 Jonathan on all on the jvm.
They were adding different types of features and different types of 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. One was a big release. That was a lot of concern around Java 9 because of Jigsaw or
backwards. Compatibility is important to consider those things because backwards compatibility 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 as 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. Way back when they're going to be like wait, 15. What happened? Most developers are still on Java 8 because that was the nice. Last big release. But the reality is Ron 15.
Now with the six monthly release Cadence is 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 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 because it's all about flow. Our work on the next thing and the next thing. And my featured 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 to the six monthly release Cadence allows the language developers to put features in which our 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 to Java 15, for example, has preview features for records, which is really in 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 enjoy. In the future, we have text blocks as a standard feature, which was a preview feature. So, text box allows you to embed things like long strings of sequel, 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 multi-line 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 multi-line strings, but actually what they did is they looked at it and went Real developers, give a bunch of feedback on how multi-line 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 To influence the
evolution of that language. So, especially if we've been working with other languages, whether there 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, the 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 job is not going to go anywhere. Or anytime soon. It's only going to continue in popularity. I think. 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. There'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 34 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 setup, Paradigm, new set of features. For example, Russ go and kotlin are some of the most prominent language.
This day, what are your thoughts about all these new programming? Paradigms coming out. Small, 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 sharp. I think I've even done Pearl 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 an I don't want to invest 20 years in another language. Which jetbrains creative 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 a real functional way. Cochran is going to assume you're a Java programmer and that you just want something with a bit less crap around the boilerplate. I also like the fact that kotlin is primarily on the jvm. Although you can run it on other platforms. Because 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 Cotton are now available in Java. So we have records, we have VAR we can use VAR instead of having to declare the whole thing cotton was quite popular in Android when Android was stuck on, Java, 6, because kotlin allows you to use Lambda Expressions, but Colin gets to move forward, and we got co-routines as well. Column has some interesting stuff for multi-threaded programming, but we're getting it preview feature of lumen 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, but I have to wait, three years for a Big Blob of language features that was relevant two and a half 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. A trust, I do not bit about go. When I worked at mongodb. They were very big on go.
They like to go because it was one of those languages you could just get stuff done with a similar reason that a lot people like continent 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. I'm stuff that Java has already put into 25 years of development. Java has been incrementally improving their 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 a platform. There are now multiple different types of garbage collectors. So you plug in the one that you
want. That works for your application. So 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. Actors, 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 would just work. I think the 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 to 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 are 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 because 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 Right language for machine learning.
That doesn't mean that Java has to shrink in the finance world, for example, so I think the space for everybody to play, you got a good point there in terms of the jvm maturity and more and more people relying on a, 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 a specially for me and those Java
Old-Timers out there. 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 it and continue with the Java release Cadence. 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 night.
So 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 jar 11, which is the next long-term support release Oracle has agreed to Port 1 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 eight. You get some more stream operations, you get better optional you get unmodifiable collections, you get Factory
methods for collections. You getting just really nice little helpful language features you get VAR as well in 11. 911 from a language. Point of view is a nice step forward from ate, it should be achievable to migrate to 11. You do have to go past the bump of nine, but it should be fine for most people. The other alternative is, if you want to get everything if you're happy too, I do want to say,
take risks is not risky. But if you want to be upgrading every 6 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. Will be coming next September. So I would really like to see people migrated 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.32 Java 6. And there was a 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 because it's like a long way away from eight.
There's a lot of features. I don't know if I'm going to Able to get the most out 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 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 to the get off. Eight, take the small language
features. No, 117 comes along, you'll be able to use. Probably records will be probably a standard feature by then. You'll be able to get records. You've got to get text blocks, you be able to get pattern matching. For instance of you, 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 on to 17, 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 race 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? Yeah, I've got experience that when we move from one point, three to six 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're saying 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 is 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 their 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 Seeing now, having worked with Dave on continuous delivery is much less risky to continually update, continually release to continually do the 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 application server because a lot of Enterprises are using application servers and this is not a criticism of the application server world. If you're writing an
application. That 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 using using Java ee which is also behind the SE version of java, so there will be a big gap between Jakarta ee9 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 met. Ivan update spring because I remember when we had to update spring with Java 5 generics came in, it was quite difficult because, you know, it's came into the language, but are 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 Livery, continuous integration or My to testing automated regression, test coverage. Everything should be automated as much as possible. It's really difficult with Legacy systems. The system is 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 25 percent test coverage, which was a massive win, but it's very difficult to retrofit this stuff. It's difficult. It's challenging. 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 the leap and jump from 8 to 11 to 15. Next 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 cool review? Because they are so many code being written these days and 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? So, when I wrote that book, I do advocacy for IntelliJ IDEA, obviously, but jetbrains also has a code review tool called up
source. And when I started doing advocacy for up Source, they asked me to write a blog post on code of you best practice and I wrote three thousand words. I'm code review. Best practices and I was like, oh my goodness and that's just the highlights. Then I wrote a whole series of blog posts or what to look for in a coat of you. 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 split those out into individual post performance and then put them together into a lean pump book called what to look for in a code of you. I like 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 wire 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 of you.
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 of user a good thing, but we don't really get told why or what to look for. That's why I write 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 up, front, the way you want it written. So just leave me or write it yourself. Don't tell me in the code of you when I've been working on it for two weeks that I've written it.
Wrong that the design is wrong because it is too late to tell me at the end that the design is wrong. You tell me up front, how you want to Designed, or you accept the fact that I have written automated test. They prove that it works and it is readable. So you should just let it go. 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 a code of you, to figure out what to look for in the code of If your code view is literally Gateway code abuse. The thing that happens at the end that says, should it go to production or not, which is a very common form of code of you. If you're doing that kind of code of you, 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 of you, 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 semicolon 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 or two. I ate as much as possible.
The most important thing a human can do is do the test because 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 are as the test is some rubbish thing, which is testing two completely different for Gateway code of you. 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 reviews as well, though. I spoke to a bunch of people who are doing code reviews for sharing the knowledge and The team when I worked at lmax the financial exchange, we would impair programming. So we didn't have code reviews because there's no point in a code of you. 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 we used to rotate pairs as well. So you just share the knowledge, amongst the whole team. There's a sort of code of you where I just wanna 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. I don't understand how this works.
Or could we have an extra test, but with those sorts of code of use, you're not going to say you've done it all wrong. The too late. It's already there. It's out. It's in production. If you do want the type of code of you 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 of physicality or any of that stuff. And particularly now are all working remotely. It's much more important to do this. So I feel like there's a potential for code of use where you can sketch out your design with some test name.
So the tests, Tell you what, they should be testing, you sketch out the classes and the methods and their 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 do something different.
Do 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 of you 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, 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 rested at 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 in IntelliJ, IDEA, move it around, move on. I also feel that Korea 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 skill set within the team has The experience that they have 10 to matter and I also see a lot of him lately. Now, it becomes their responsibility to do the curry before everybody. Do you think it's a good thing to do for team needs to review everyone? Or do you just want to rely with the collective mindset? My personal opinion?
It depends on which sort of code of you doing. If you don't 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 or no. If they need to be. L too 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 of use 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 because 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 of you, I would probably have at least a junior and a mid-level appear 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 match 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 ticks that and signs that off. So it's not up to the senior person to do the line. By line staff actually, it should be down to everybody to do the line by line staff. 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 at the whole team. Learns, what changes are going into the application apart, from the Gateway review. Are there any other reviews that
you can mention for? To learn more. 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 that there aren't that many new people on there, or there are high performing team. You just do the code of you for learning the pattern with that is quite often. You'll be submitting your commits.
Maybe even just published in two main straightaway, your code of you might select individual commits and put them together in a single code of you, rather than having to look at the whole of main. One of the things with code of you, of course, is putting aside time to do this, the whole team every morning. Let's say you put aside 30 minutes to review which Whatever code reviews have come in from the previous day. We 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 Order segment looks like and how it works. So, it's really for you to understand what's going on in
the application. So you keep mentioning a lot of times about reading the code, making sure that 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 that there's a thing that you want to send message across what other important thing for person who writes the code. In terms of readability. I did a presentation about reading code, is more difficult than writing it because this is often code of you 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 very difficult, to read the code. We're not taught how to read code when we learn other languages. So, Maria's learning French at the moment. I'm constantly learning Spanish because I live in Spain, where you learn how to read it.
You learn how to listen to it. You don't necessarily learn how to write, it is. Absolutely the last thing that you learn but with programming were 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 - 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 Domaine better things have evolved in your applications are no 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. 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 pose. The problem? What are the tests do? It's not that we don't know how to read code because we do read code but we don't value it. We sort of see it as a waste of time and not writing lines of code. I'm not writing stuff.
So I'm not productive whenever 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 Right 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 in your in applications, we quite often go. Well. This is really old code and has an old dialect if you like as 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 your writing readable code in some context. It's not readable code in the context of someone who's going to have to read this whole
application. We are talk a lot about writing readable code with. I've talked a lot about what that really means and how it applies to the rest of the team to that rest of the application to the dialect of the code. If you like, because your code, bases do have different dialects and you don't have to live within that and accept it. Not just try and change it all the time. Yeah, sometimes I think, for all of us to take, he's here.
We do have this kind of buzz words or the up-and-coming shiny new features. We just, you know what? I'm gonna 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. What was the code written in the beginning? And just adapt to the style that it was listening, rather than changing, then confusing.
The other people who are reading the code seeing like a mixed style patterns, Trish, you also a developer advocate for gender. And 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 ID from jetbrains pesos? For example, the S code or probably add them or things like that. Again. This is going to be created.
With my background as a Java programmer, we generally like our ID. He's granted Javas. Got a bit of boilerplate. So having cogeneration is helpful for as the code navigation is helpful. Java is a statically typed language. So your ID can give you a lot because it can give you a compiler warnings in line. You don't have to compile a whole application. Static language, is also allow you to do data flow analysis. Some of the stuff in IntelliJ.
IDEA is so cool because it goes this value will never be null. You 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 of whatever.
Given my background as a Java programmer. When I did see Sharp 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 re sharper in there. Mike. 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 we shop is still one of the most
Other 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 sharp, I can use resharper to get the same sorts of suggestions, especially when I write Java style, C sharp, and then it goes, 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 from using typescript. Camp nou to it says all 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 idea is 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 program, run, you're going from language to language. When I'm writing groovy IntelliJ.
IDEA will say look, I course it will work because Java Works inside groovy, but I wouldn't do it that way. This is 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 around to yet, is a tutorial for using get inside until ago.
Dear. I know most real developers use get from the command line. I am not capable of that because 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 in IntelliJ IDEA has full integration for git and GitHub. So I just do everything inside the IDE and I You my cherry picking my merging, my rebasing, and it all makes a lot more logical sense to me because 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 get if I'm using application servers. Like we're 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 are 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 talk to a terminal or to a different tool to do my get 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 Sequel, 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 How to quickly open up an editor and make those
changes. And you do want a syntax highlighting and code completion for those sorts of things too. So you get a lot of benefit from that kind of tool to. But for me, you can't take my IDE from being, you can't rest it from my cold, dead hands. Yeah. I can also relate to some of your stories. So when I learn how to write in Ruby, I also got suggested. Hey, you should not do this. There's this Ruby features. Ok, just click shortcuts been, my code just gets transformed.
I think it's pretty nice. One way. Is that the code gets better? And also I learned new things like you Said I also used it from the ID instead of doing all this to get command. So I find it quite efficient just by pressing a few key and nothing gets done out of the box. 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, 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 can't have one without On a 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, well, we could do something cool.
We could do something different. We have a new product called space, which is a team tool as an integrated environment for team stuff. It's got chart. 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 that meeting tracking and it's got location people in offices.
It's got the whole team, the whole organization in their Theory. Everything that you want to do with the people in your organization, you can do that. I think that's still an EOP 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 intelligent, 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 meat 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 and How we do stuff. So 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 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 dog food ourselves are the best, because we use IntelliJ IDEA to write IntelliJ IDEA. We use IntelliJ The right 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. 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 Your screen casting of the code that we 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 are 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. Trish is a pleasure talking to you. Obviously, we learned a lot about Java, but jetbrains about Korea views. 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, three, technical leadership, wisdom, probably for all of us
to learn as well from you. I guess my primary technical leadership wisdom. That is the thing. I talked about earlier as the leader. It's not your responsibility to do is your responsibility to teach and help your team to level up and that's probably the hardest transition 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 just not, you're going to be in meetings. It's your job to network. Work. 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 our information and make sure other people know it to 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. We're not necessarily doing more. You might just want to keep paying the site 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. Thank you, for sharing your wisdom. So Trish, where can people find you online. I'm active on Twitter. Tricia underscore GE or Twitter. I do have a GitHub which is strategy. Arie launched my website. Trisha g.com. I'm Vlogging again. I haven't blocked for the longest time. So that's probably a good place to find me.
I'm usually at conferences, but not this year. Okay, so I'll make sure everyone check out all your Tweet, the website and all that. I'll put in the show notes. Thanks again, Trish for spending your time with us, but 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. Thanks very much for having me. It was really fun. Thank you for listening to this episode and for staying right till the end.
If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really really helps me a lot. In order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at tackle, the journal, the death website, including the full transcript, interesting quotes, and links to the resources and mentions from the conversation, and lastly, make sure to subscribe to the shows mailing list on technology on of the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.