LTS Version or Latest Version of Java?

We, the Java Developer Advocates at JetBrains, are building a Spring Boot application. Right at the start of the process (which was yesterday on publish date) we kicked off the New Project wizard and selected Spring Initializr. Everything was fine until that point, we (Trisha, Dalia and myself) were having a nice chat and all in agreement. That was when we got to this screen:
Spring Initializer Settings
We gave it a name, set the location, and then had a quick debate about Maven or Gradle. If you’re interested we chose Maven for this project but will choose Gradle for a different component because we like a bit of variation. That wasn’t the contentious part, that was merely a warm-up exercise as it turned out.

We got down to Project SDK and Java. And this is where I felt like I’d been ported to an episode of Mortal Kombat with Trisha and Dalia playing leading roles. BTW, in case you were wondering (because I was), the Java field is the Language Level. I opted to extract the (mostly) full conversation here because I think it’s really useful to show this transparency of a healthy debate. Also, now I’m listening to this back to extract the transcript, Dalia totally started it. Oh, and then there was this, by way of escalation.

Dalia: Alright, hold on. The version of Java we’re using, do we want to use 11?
Helen: (yes I got this one word in) It’s the latest LTS isn’t it?
Trisha: It is, but 16 is so nice, but 16 is also challenging because 16 it hides the internals of the JDK by default so if you have any other JVM language like Kotlin it doesn’t work that well on 16. Now, since we’re using Spring Boot, Spring is always a little bit behind anyway so Spring supports Java 15, I don’t think it supports Java 16 but if we use Java 16 we can use Records, which is fun. I want to go with 16 and then see what breaks.
Dalia: My opinion is 11 because if you’re in an enterprise scenario, you will not be using 16, you’ll be using 11 because you want to make sure you’re not going to have to upgrade every 6 months.
Trisha: I agree with that. What I would like to do is I would like to showcase what you’re missing, but, here’s the other thing, so we might not even use that many features from Java 12 through 16, what we might want to do though is if we use anything that’s 12 through 16 we’ll just “if you’re using Java 11 this is how you do it”, like Records, because Records can be converted to data classes.
Dalia: When is 17 coming out?
Trisha: September
Dalia: Okay do we feel like we’ll want to upgrade to 17 when it comes out because that’s the main argument for me because then we can upgrade to 17 and that might be around the time we showcase this.
Trisha: So, I would like to show 16 to really help to pull people in the direction of 17. 16 has Records as a standard feature, not a preview feature which will be really helpful for small services.
Dalia: The only thing I’m saying is that if we are recommending “here’s how you start a new service”, then best practice is not to start with a short term release.
Trisha: I know what you’re saying, I think given 17 is coming out in September I think we should be poking people in that direction. We’re talking about new services and if you’re trying to get people to do new services with 11 it’s going to be forever before anyone gets anywhere. So if we go with 16 then we can say “you should be doing this on 17” when it comes out and it’s a full Java 17 application.
Dalia: I agree to disagree, I would have done 11 but I think you have a fair point too.
Trisha: We can revisit this decision if it looks like there’s anything that’s going to be show-stopping. So yes, lots of decisions on the first page!
Dalia: Yes! I think this is a really good topic to create content from how we made these decisions.

And, that is how this blog came to be! Then, we moved onto this page:

Spring Boot Options

And the conversation continued. We discussed which version of Spring we should use given we’ve selected Java 16. That involved some Googling, and we landed on the snapshot release which of course continued to make Dalia pretty nervous (understandably!).

We had a discussion around what our objectives were in terms of who we should be providing feedback for and why. We agreed that sending feedback on all bugs and problems to all software vendors (of course including JetBrains) was paramount, so we try things out and find issues before you all do. We went on to discuss the fact that we didn’t want the tutorial to be immediately out of date and that was another reason to forge ahead with Java 16.

The conversation concluded like this:
Trisha: I’m going to propose we go my way, but, as soon as we lose more than half an hour to a stupid bug then we roll back one thing at a time.
Dalia: Yes! Yes!

Finally, I managed to get a word in and asked how easy it would be to change the version of Spring Boot after we’ve made these selections. Turns out, that’s very easy (just like it is for the SDK).

We all wanted to share this with you because it was a healthy and fun debate. These are great discussions to have and are critical for new projects. Yes, IntelliJ IDEA makes changing this stuff easy after the event, but that doesn’t mean you should just forge ahead without understanding why you want to go down that path.

At the time of writing the poll was very evenly split. My personal view is that this is because both Trisha and Dalia are excellent ambassadors for the Java community, and they were both advocating for what they believed to be the best option for the content we all want to create.

3 Things I Learned from My First Week as a Developer Advocate

This week I started my new job at JetBrains as a Java Developer Advocate which I am super excited about! It’s been a fantastic week and my feet haven’t really touched the floor, but I wanted to summarise my learnings from week one. I hope you find them useful!

Free-Photos from Pixabay


Asking questions is a Good Thing™️

I’m not normally one to hold back on questions, but I find that it’s really easy to be less forthcoming with queries when you join a new company and start doing a job that you’re new to as well. After all, no one wants to look, or feel, stupid.

Of course what I need to remember is that I can’t possibly know everything. This feeling is amplified many times over when you are new to a company, a team, and a role. I had already obliterated this piece of advice by day #4 so I urge you not to do the same. Fortunately I was reminded of this by a colleague who clearly thought I needed to hear it (they were totally right, I did — thank you!).

Everytime I struggle to ask questions in unfamiliar environments, I remind myself that:

  • If I don’t know the answer, there’s a very good chance that someone else doesn’t either

  • Everyone wants me to succeed, I need to ask the questions that will empower me to do just that

  • Questioning shows engagement. It shows that I care and it helps me learn

Struggling improves learning

This may sound like it flies in the face of asking questions, but there has been some times this week when my immediate team were otherwise engaged and couldn’t answer my gazillionth question. As anyone who knows me will attest to, I am extremely stubborn when it comes to certain things. As it turns out, bending IntelliJ to my will is one of those.

And I got there, I solved the problems, each and every one of them by myself with the aid of Google and at times a walk around the block to work out what I was missing. It feels insanely good to solve a problem by myself and I will never (like ever) forget the following:

  • ⌘⇧8 gives you column select mode (I typed it that many times that it’s now in long-term-can-never-forget memory)

  • If you want IntelliJ to show intention actions and quick-fixes (⌥⏎) you need to make sure the caret is on the word you want it to deal with, not just the line. IntelliJ will highlight the word which is very helpful

  • If your Project window isn’t colour coded and you can’t interact with it, it’s entirely possible that you’re looking at the git Repositories window instead of Project… oops

  • I don’t need a 3rd party app for git, I can use ⌘9 and see it all in IntelliJ, perfect

I have a lot to do

It’s a really steep learning curve, I knew it would be and I am 100% okay with it. However, that doesn’t detract from the fact it’s hard, likely really hard. I did catch myself feeling quite overwhelmed quite quickly (day #3), but again, I was reminded that I can’t do everything, and neither can anyone else.

The skill is triaging the immense workload and being smart about what I work on and how I work on it. Some of the things I’ve found helped me are:

  • Automate it. If I can automate any part of my workflow, I do. I’m confident that there’s plenty more I can do in this area and I plan to sieve through the huge wealth of knowledge that my team and the business has to give me some more go-faster skills

  • Talk about it. Talking with my team has been invaluable. We prioritise work together, we challenge each other’s viewpoints, we bring new information to the table and we help each other.

  • Share it (early and often). As I’m working on new things I’m sharing them throughout the process. It’s much better to make a small change to process or content early on then wait until a big bang at the end!


When you’re in unfamiliar territory and you’re grappling with all sorts of unknowns and knowledge gaps, my top 3 tips are:

  • Ask lots of questions, they’re a Good Thing™️! ❓

  • Don’t worry about struggling to learn something, when you do crack it, and you will, it will be embedded in your memory for good. 🙌

  • Look at what you’re doing and share your workload with those that can help and empower you. 🥑

Remote Behaviours

Before the UK was overtaken by Covid-19, I wrote an article called Stop Calling them Soft Skills. It’s something I’ve always been passionate about and it once again came to the forefront of my mind this weekend when it dawned on me the immense pressure that we’re all in right now as we adjust to life under lockdown.

First up, wherever you’re at right now, you are awesome. You should know that. Irrespective of whether you’re working from home with kids on your lap watching Frozen II on loop, putting in long, emotional hours in our hospitals, delivering meals for the elderly and vulnerable, or indeed working in any of the front-line positions, there are so many. You’re saving lives and I am incredibly grateful to you all.

Many of us are now working remotely and that brings its own challenges. It occurred to me that the behaviours I associate with the phrase soft skills might be even more crucial when we’re working remotely.

Genuinely I wish my makeshift desk looked this good!

Image by Free-Photos from Pixabay

The original definition of these behaviours was:

…a combination of people skills, social skills, communication skills, character or personality traits, attitudes, career attributes, social intelligence and emotional intelligence quotients, among others, that enable people to navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills.

So how does working remotely impact these behaviours? And how can we help people working remotely to navigate in their environment, work well with others, perform well and achieve their goals?

Remote Working and Behaviours

It would be very easy to list the things we might find hard when interacting with our colleagues remotely, especially for those of us that are not accustomed to it. It could be summarised as:

  • Harder to read people’s body language and social interactions

  • Harder to manage the flow of communication between multiple people

But this is bigger than that, we have to factor in that for all us existing and new remote workers, we are all under an immense cognitive load in addition to the obvious challenges. Many of us:

  • Have kids at home (and school is most definitely out for summer)

  • Have never done this before

  • Have vulnerable people in their house that now need additional support

  • Have vulnerable people they can’t see, but worry about

  • Are vulnerable themselves

So what can we do?

We don’t need to modify our behaviours, not really. We don’t need to get hung up on the challenges of remote communication, that’s a given.

We just have to amplify our behaviours. We have to shout them (metaphorically perhaps) from our rooftops/balconies (Europe I’m looking at you ❤) or our windows for those of us in the UK.

Most importantly we need to act those amplified behaviours out in front of our laptops.

My top behaviours to amplify are:

  • Be empathetic

  • Act with kindness

  • Show compassion

  • Respect everyone (and their families)

  • Have patience

Looking after yourself

  • Make time for yourself. I appreciate this is much easier said than done, but if it’s at all possible, take whatever time you can for you 📚

  • Ask for help; don’t suffer alone. We’re all in this together and if you need help then so does someone else 💛

  • Be you. Be real. I ditched the make-up on day #3. 😏

  • Respect your time. Just because your laptop is on the dining room table does not mean you need to look at it on a Saturday night. Don’t burn out 🕯

  • Be honest with the people around you. Whether they are your family, friends, or brand new housemates. Ask for support from those physically located with you or those you can phone ☎️

Looking after others

  • Video-call your colleagues without a work agenda and ask how they are, listen to them 🎥

  • If you have the capacity to do something to help someone else and improve their day, do it 💗

  • Give a wave to the little kid sitting on the parent’s lap on your video call, it will make their day. Respect their family, they’re not enjoying this either 👶🏻

  • Make allowances for everyone. We’re all finding our way and we’ll all make mistakes on the way as we change and grow 🌱

  • Forgive your colleagues when they drop more balls than usual. We’re not all as good as juggling as we might think right now️ 🎾

And in case you forgot this already, you are awesome!