Tag: developer advocacy; communication

LTS Version or Latest Version of Java?

Leave a comment

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!

Summary

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. 🥑