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.