5 Things Only Experienced Devs Can Teach You About Java

See more posts like this at Takipi.^[1]

There are numerous tools, methods, environments and features that change the way you handle your code, that you usually don't come across during school years. While it offers the first foot through the door in the Java development world, most of the actual learning happens on the job.

In the following post, we'll go over some key elements you only learn about as you get more experienced. These will include the basics and mix in some philosophy. Get your notebook ready, it's back to school time.

Congrats, You're About to Fudge Up

While learning to code we face pure problems: figuring out how algorithms work, identifying the right data structures to use and knowing how to fix the code that we wrote ourselves. However, the real world has a lot of new issues that we've never encountered before: adjusting your code to fit the coding standards of the team, understanding someone else's code and… finding the best taco truck in the neighborhood.

The first line of code we'll write will probably be different than the 10,000th one, since we learn, adjust and develop along the way. As part of this process we might fail or fudge up big, and that's ok since it's a part of any learning curve. But there are a few things we can be ready for in advance, to try and minimize the destruction of the code, DB or application we're working on.

Write, Merge, Debug, Repeat

Every engineer knows that coding is a big part of the job, but writing it is probably the easiest part. It's the adjustments and elements around it that make it a challenge. There are a lot of topics to cover here, but we decided to focus on those you can actually learn in advance, starting with:

1. Merging Files

It might sound basic, but there are a lot of ways to mess this up. One of the most common actions you'll come across is a merge. It's the action of joining two (or more) development histories, text files, arrays or any other objects together. For example, committing a whole branch is pretty basic, but what if you only want to commit some of it? You better learn how to actually do it before you mess up everyone's hard word. That's why it's important to know what's going on in this process, being able to see and understand the code before hitting commit.

You can go for the manual method, actually looking at the files, identifying the changes and see how they might affect the code, or you can choose a tool that helps spot the changes. There are a number of tools you can use, such as IntelliJ IDEA's conflict resolution tool ^[2], KDiff3 ^[3], Meld ^[4], Guiffy ^[5], Kompare ^[6] and others.

IntelliJ IDEA's conflict resolution tool

2. Understanding the Debugging Process

Once your code is out and in the wild, or at least running on your development environment, it's time to see if it actually works. The debugging process itself is pretty basic, but in order to make it even more helpful, you need to focus on your logs.

There are different levels to choose from:

Trace: Most detailed information.
Debug: Detailed messages that are written to the log.
Info: Runtime events that are visible on your console.
Warning: Message about potential problems.
Error: Unexpected conditions.
Fatal: Severe errors.

While there are frameworks that write these messages for you, it's important to give as much information as possible, to know how to handle and solve different issues.

First of all, you need to identify the correct level of each message. For example, use Debug to log ANYTHING that happens in the program, to better debug your code and understand what's going on before sending it to production. Use Info to know which actions are created by users, and use Warn to mark events that might end up as an error, if you'd like to keep track of them and of course.

Second, make sure you give your logs as much information as needed. Sure, right now you know what this means:

But you have to think about your co-workers trying to understand your code. You don't want them calling you up during your vacation asking what car you're talking about, and you don't want to find yourself 2 years from today wondering what you were thinking while writing this. Treat your code the way you'd like to receive it – with as much information as possible, so others will know how to handle it.

Also, if you practice good logging skills you're bound to make everyone do the same.

3. Using Exceptions for Your Advantage

There are a lot of exceptions in Java, and recently we've published a collection of tips and insights for handling a number of Java exceptions ^[7]. But how can you use exceptions for your own good in the development stage? Through breakpoints.

You can manually set breakpoints for thrown exceptions, and mark where execution should pause when you are running your application in development. Whenever a breakpoint is executed, a message will be printed in the Debugger Console with the relevant information needed.

It's like a pause button for your application, that lets you inspect and see exactly what happened up until that point. There are different types of breakpoints that stop the execution of your application it reaches a certain method, class, variable or line of code – so you can play and test as you wish.

On the other hand, if you're looking for a tool that will help you know when, where and why your code breaks in production, you can try OverOps. It's the only tool that shows you the complete source code and variable state across the entire call stack for every exception, logged warning, and error. Check it out ^[8].

4. Handling a Production Environment

After all the hard work, you've deployed your code and it's live in production. If you've written meaningful log messages you'll be able to know when an exception is thrown, but sometimes it will be harder to understand why it actually happened.

One of the things you have to keep in mind when moving over to production, is this gap. We're not talking about rail passengers and trains, we're talking about your local environment vs production. This is the recipe for numerous errors that'll waste your time trying to figure out where they came from, and why.

You need to understand why these environments are different, and how you can deal with this gap. If you're looking for some advanced Java debugging techniques, check out this post ^[9]. Another way to configure applications for multiple environments can be implemented with Docker, and you can read a quick guide for it here ^[10].

5. Thinking About Future Teammates

We've got 2 words for you: backwards compatibility. Imagine this: you have Java 8 installed on your machine, while production runs Java 6, and you don't understand why things are breaking. Or maybe one of the customers is running an old version of the application and your newest feature doesn't work for them. It's a sticky situation that can be avoided easily.

You need to keep in mind that each team has a past, and a list of decisions that were made long before you arrived. That's why you have to think of the past in order to move forwards (we said we were gonna get philosophical, right?).

When writing new code, take the time to test, identify and fix whatever might break old versions of the app. It'll help you along the way, and will make everyone happier since they won't have to face old or even surprising bugs for big customers that are not willing to update their application version.

What Else?

The hardest part of the job is getting in the zone. We're not talking about that morning pick-me-up cup of coffee, we're talking about productivity hacks that will boost you work and help you do it even better.

There are a number of things you can use, such as special bash scripts, self-made command line hacks or even special tools to help you monitor everything better. If you're looking for some tips and tricks, check out a few productivity tips we've gathered from the Java community ^[11].

Final Thoughts

The hardest part is getting started. It doesn't matter if it's the first day of a new job, or even a new blog post about it – there's a lot of research and learning during this process. Don't be afraid to ask as many questions as you have, since it's the best way to understand how the team, code and application works.

If you have any other key features for new employees you think we've missed, we'd love to hear about them in the comments below!

See more posts like this at Takipi.^[12]