Tech Corner

How to enter an unknown terrain of code

Shripati Bhat
Sep 10
4-5 mins

Table of contents

Automate your business at $5/day with Engati

How to enter an unknown terrain of code

Writing every single line of code grounds up in every project you work on is reductio ad absurdum. Often times we need to look at and understand code written by our team members or some employees who no longer work on that project.

So if you are new to a project, here is what you could do before you ask one of your colleagues for assistance and try to increase your skills to debug existing code.


Read Product documentation

This is mostly the best place to start because this is where your customers start. For you to know a feature from end to end, this should give references or content that your customers actually go through to setup or use the feature. If you don't find this, just imagine how a customer who doesn't even have access to the code would be using the feature!

Try the feature in a lower environment

After you read up the documentation and you have some context, always try the feature yourself in a test account in one of the lower environments (something that’s your Continuous Integration environment). This will always give you the ability to be comfortable with some network calls and also with some interactions happening from the client which can help you kick start looking at code.

Go through the Technical Documentation

Every project ought to have some technical design document or some form of documentation for the feature that you are about to venture into. Going through the technical documentation will give you an idea of why a particular feature is developed in a particular way. It might answer some questions like `What were the design drivers, considerations, challenges?`, `What’s still to-be-done for the project?

Endpoint Identification

This section is only applicable if your application has HTTP (RESTful, GraphQL, SOAP, or such) Endpoints, Asynchronous Messaging Endpoint, Scheduler-based Endpoint, etc exposed that the client invokes to achieve a business functionality. Once you have the endpoint, you have to look for the endpoint pattern in the codebase of your application gateway (if you have a multi-tiered application) or the codebase of the microservices.

Unit test cases

This may seem weird to a few people, but unit test cases, if well written, can easily act as a guide to understand the business functionality and the output of a specific core business functionality for a given set of inputs 

Specifically, as you write code and if you are debugging your application, always try to ensure that you have the call stack and its arguments written at each level. This gives an idea of which stack was invoked with what values to arguments. And NEVER PRESUME ANYTHING. One should make no presumptions around the code and start debugging every stack and every code within a method.

For example, let’s take a sample code where you are trying to start a group call with a participant where you first validate if a group call already exists with the participant, if not fetch the participant detail and then start group call.


public GroupCallDTO startGroupCall(GroupCallRequest request) {

final GroupCall groupCall = getExistingGroupRequest(request.getRequestId());

if (groupCall != null && groupCall.alreadyExists()) {

      log.error("Group call already exists for request: {}", request.getRequestId());

   throw new GroupCallExistsException("Group call already exists");


final Optional<CallParticipant> optionalParticipant =


if (!optionalParticipant.isPresent()) {

      log.error("Participant: {} does not exist", request.getParticipantId);

   throw new ParticipantException("Participant does not exist");


final CallParticipant participant = optionalParticipant.get();

final GroupCall groupCall = groupCallService.startGroupCall(participant);

return convertToDTO(groupCall);



The code is a core logic and you would've gone through a lot of cases to understand each step. But what truly helps is something like

Start Group CalI Request code
Dividing the code into logical chunks

So always try to break the methods into smaller logical chunks based on the business workflow. Always understanding code based on business use-case mapping is easier.

Also read: Declarative programming

Shripati Bhat

Shripati is a Senior Director at Engati. He's a technical enthusiast, passionate about designing and building scalable software.

Shripati has a deeply ingrained customer-first ideology and is highly skilled in designing and developing Java/J2EE applications and BigData applications.

Close Icon
Request a Demo!
Get started on Engati with the help of a personalised demo.
Thanks for the information.
We will be shortly getting in touch with you.
Oops! something went wrong!
For any query reach out to us on
Close Icon
Congratulations! Your demo is recorded.

Select an option on how Engati can help you.

I am looking for a conversational AI engagement solution for the web and other channels.

I would like for a conversational AI engagement solution for WhatsApp as the primary channel

I am an e-commerce store with Shopify. I am looking for a conversational AI engagement solution for my business

I am looking to partner with Engati to build conversational AI solutions for other businesses

Close Icon
You're a step away from building your Al chatbot

How many customers do you expect to engage in a month?

Less Than 2000


More than 5000

Close Icon
Thanks for the information.

We will be shortly getting in touch with you.

Close Icon

Contact Us

Please fill in your details and we will contact you shortly.

Thanks for the information.
We will be shortly getting in touch with you.
Oops! Looks like there is a problem.
Never mind, drop us a mail at