How To Get Up To Speed In A New Java Job

[Simon Ritchie]

Hi everyone,

Next month I'll be starting in a new role as a mid-level Java developer with a successful startup.  The architecture is a microservices design, which is something I've a couple of years experience in thanks to a similar role I once had with a large multinational.  I'm keen to start well in the new role so I thought I'd ask some advice here.

What is the best way you've found to come up to speed on a new codebase?  Are there any tips or recommendations?  I've always found the first couple of months in a new role intimidating because, on top of all of the new technologies you've to become familiar with, you're also confronted with this massive codebase that's often difficult to understand.

[Tim Holloway]

Actually, I've always found the greater challenge is getting used to a new corporate environment. That is, who does what, how to deal with new people, and so forth.

Yes, expect that they will have some large and quirky systems that influence everything else, but the very ubiquitousness of such systems means that people are constantly helping each other with them.

You may, in fact, find that the biggest shock is in how a startup is run. Large corporations have many people with their own specialities. Smaller corporations - especially during start-up - have more overlap in functions and fewer people to do functions. "Not my Job" is rarely an option.

[Simon Ritchie]

Thanks Tim.

I should have stated that I'm actually leaving a startup to join this new one.  But the difference is that the old startup was based around a monolithic back-end.  The reason I left was largely personal - I found the tech architect and the scrum leader to be impatient and unhelpful at times.  But I did make the mistake of diving into the code and making changes without fully understanding what it did and how it worked.  I don't want to repeat that mistake (or any other mistake) this time around.

[Ty Hardenstein]

I’ve had success “getting up to speed” with new code by writing unit tests. You get a chance to see the code actually work while testing your assumptions. It offers a ton of insight (architecture, dependencies, coupling, etc.) and works much better for me than trying to absorb by passively reading code. Codebases with lots of test coverage seem to be the exception rather than the norm so I’d imagine you’ll have plenty of opportunities to gain understanding while simultaneously increasing the project’s test coverage.

[Campbell Ritchie]

TH: welcome to the Ranch That sounds like a good idea. You are enhancing the old code as you learn to understand it.

[Andrew Fielden]

Simon Ritchie wrote:Hi everyone,

Next month I'll be starting in a new role as a mid-level Java developer with a successful startup.  The architecture is a microservices design, which is something I've a couple of years experience in thanks to a similar role I once had with a large multinational.  I'm keen to start well in the new role so I thought I'd ask some advice here.

What is the best way you've found to come up to speed on a new codebase?  Are there any tips or recommendations?  I've always found the first couple of months in a new role intimidating because, on top of all of the new technologies you've to become familiar with, you're also confronted with this massive codebase that's often difficult to understand.

Congratulations on the new job!

#1 tip I can give you, is to get involved in bug fixing. To start with you'll want to tackle fairly easy ones, but it does make you poke around the code and get a feel for how it's organised. This will help you familiarise yourself.

The other thing I can recommend is to understand the database schema. Most software systems are underpinned by a database. If you understand the data, it goes a long way to understanding the application code.

Good luck!

[paul nisset]

What I've done is look at the database structure. Almost all the jobs I've had had used relational databases, so I've found that looking at the database structure through a graphical tool like SQL Developer has been enormously helpful. It gives me a good idea of how the data works and good insight into the business functionality. A picture is worth a thousand words.

An alternative is to look at an object diagram if there is one. What you want first off is an overview of how the application is supposed to work .

Also ,you can step through the code using a debugger .See what happens when a button is clicked ,preferably with a non production database . If you have to use the production DB , do things like searches.

Good luck.

[Mark Herschberg]

Talks to as many people as possible, both on your team and off. Ask them what challenges and opportunities they see and what things they think you should keep in mind.

[Tim Holloway]

I'm going to take Paul's advice one further. There are some great tools for this.

The schemaspy utility can scan a database schema and render it with graphical documentation. It can produced a hyperlinked website of the schema, and also, if memory serves, several other forms, such as PDFs

You can get a class overview using the reverse engineering features of tools like ArgoUML. The downside to UML charting being that it has no sense of proportion so you end up with acres of paper where the most trivial classes are indistinguishable from the most critical ones.

And, last, but not least, run JavaDoc! Applications that have fully leveraged JavaDoc's abilities can make a complete illustrated technical manual out of a program's source code, but even poorly-documented apps can at least be outlined.

Note also that if you're in a continous-integration shop, tools like Jenkins can run these documentation apps as part of the build process and display the results as part of the Jenkins dashboard.