Working on a monolithic legacy system in a large cooperation

The lessons and challenges that I've come across working on a monolith, as a junior JAVA support developer. Firstly I would like to start walking you through what I do on an average day.

As a Java support dev, I provide support to senior devs and perform duties such as fixing bugs and updating existing code requirements, replacing UI elements which for some odd reason a client requested that they are moved from one screen to the next. I get the occasional email asking me to inspect the increasing error rates on service X running on server Y.

In essence, I am just a glorified assistant.

When I come into the office, every morning, the first thing I do is open up Outlook, to check if there are any emails from IM (Incident Management team). IM is a team tasked with monitoring the status of our servers & services using Dynatrace. If IM gets an alert from Dynatrace, they send out an email to our team, which I have to read then figure out the problem and provide feedback.

Finding & fixing the bug.

This is the most challenging part of the job. Having to search on a codebase of close to a million lines, for what went wrong with a service call which calls ten other services, in which some of these services are exposing a piece of functionality from other teams which we need to fulfill the request.

The general recipe :

• Look at the logs to find where the call failed.
• Follow the sequence of calls, as observed from the logs on the codebase.
• Huh! so it went through here.
• Postulate the cause (Assume everything that can go wrong went wrong)
• Try to recreate the problem on the test (As you already know, it always works on test)
• Just read the code (That's the response you will get if you ask a senior dev, so save your time, and just read the damn code)
• Get a jug of coffee (Cause you're going to be here for a while)
• With some luck and a lot of caffeine you find what's wrong, most of the time it's a data issue that team X caused by not returning the component that you use to calculate a customer's premiums.
• Don't assume it's the other team (This is to avoid humiliation. If it happens always come with evidence. Don't go there empty-handed)

In addition to the above, I am also tasked with releasing code to production, but in truth, I just prepare the code for the release, this happens once a week. The release team does the rest. I update the versions on all the code repositories going live since it’s a monolith I also have to update the versions for all of its dependencies, which takes about an hour of my time.

After spending my day answering emails: "checking", "investigating", "please reassess", I get to write code.

This doesn't happen as often, but I do write code, sometimes. On average I work on five JIRA tickets a month, four of them are bug fixes, and one is a feature (Not a true feature more like updated requirements to an already existing feature).

Introducing a feature

1. Evaluate your requirements, make sure you fully understand them.
2. Read the code, and try to map the impact your new feature will have on the current code structure. If you are modifying existing code, make sure you look at the usages of the classes or methods you need to make changes on, to integrate your feature (You don't want your code to break other parts of the system).
3. Write your code in such a way that it is reusable, and can be integrated with other components. (This makes it easier for the next dev whom will work with your code)
4. A simple solution is always the best one, don't write fancy code that will confuse even yourself if you were woken up on the AM's to explain what it does in a minute.
5. Write comments. Comments are meant to explain why the code is doing whatever it's doing.
6. Lastly, always write unit tests, this can never be said enough.