From “Can I Do This?” to Becoming Part of the Team: Lessons From My Apprenticeship at ISRO

Chaitanya Pranav Sai Kodamasimham — Sat, 29 Aug 2026 07:49:58 +0000

My first real experience working in a professional engineering environment began during my apprenticeship at ISRO

On my first day, I was introduced to the project.

They explained what the project was, its purpose, its scale, what my role would be, and the prerequisites I needed to understand before getting started.

At that point, everything sounded exciting.

I was about to work in a real engineering environment and contribute to an actual project.

Then, after a day, I received my first task.

And that was the first time I opened the project's codebase.

Honestly?

I didn't understand anything.

Well, that's not entirely true.

I could understand what was written. I knew the programming concepts. I could recognize classes, methods, variables, and the object-oriented structure.

But I didn't understand what the code was actually doing.

I could read a file.

But I couldn't yet see the system.

That was probably one of the first major differences I experienced between learning programming and working in a real engineering environment.

When You Know the Code but Don't Understand the System

In college projects, I usually knew the entire application.

I had either built it myself or worked with a small team. If I wanted to understand something, I could open a few files and eventually figure out what was happening.

This was different.

I was looking at an existing production codebase.

Code written for a specific purpose.

Components interacting with other components.

Decisions that had been made before I arrived.

I remember looking at the code and thinking:

Can I actually do this? And what happens if I mess something up?

The next day, I went to my mentor with a list of doubts.

Instead of simply answering them one by one, he did something much more valuable.

He took me through the parts of the production code relevant to my work and explained the reasoning behind the way things had been implemented.

While I was there, he also integrated a new feature into the system and explained his thought process as he worked.

That experience changed how I approached the codebase.

Watching an Engineer Think

For the next three days, I spent time working alongside my mentor.

On the first day, I honestly couldn't keep up.

He would encounter an issue, inspect something, trace it through the code, check another part of the system, and suddenly have an idea about where the problem might be.

Meanwhile, I was still trying to understand what had just happened.

At first, I thought the difference was simply experience or speed.

But after watching him for a while, I started noticing something else.

It wasn't just that he was debugging faster.

He was thinking differently.

He wasn't looking at code as individual files or isolated functions.

He was thinking about the system.

Questions like:

What could be causing this issue?
Where does this data come from?
What calls this component?
What changes if we modify this?
Could the issue be coming from somewhere else?
What assumptions are we making?

Slowly, I started paying less attention to what he was clicking and more attention to how he was thinking.

That changed something for me.

I started realizing that working with a real system wasn't about memorizing the entire codebase.

It was about learning how to navigate it.

How to trace a problem.

How to follow the flow of data.

How to understand the responsibility of different components.

And most importantly, how to ask the right questions.

Going Back to My First Task

After those three days, I went back to my first task.

The codebase hadn't suddenly become easy to understand.

But I had a starting point.

I knew how to approach it.

Instead of staring at individual files and trying to understand everything at once, I started tracing the flow.

I asked myself what each component was responsible for.

I followed how data moved through the system.

And whenever I got stuck, I tried to understand the problem before immediately asking someone for the answer.

I completed my first task in about a week.

At the time, it felt like a small win.

Looking back, I think it was the beginning of a much bigger transition.

Three Months Later

Fast forward three months.

I was completing my tasks without needing constant support.

That doesn't mean I suddenly knew everything.

I still discussed my work with my mentor. I still asked questions. I still needed validation for my decisions.

But something had changed.

I was no longer starting every task with the question:

Can I actually do this?

Instead, I had started asking:

How do I approach this?

That difference might sound small, but for me, it represented a major change.

I had started understanding how to approach unfamiliar problems.

I became part of team discussions and meetings.

Instead of simply listening to technical and architectural decisions being made, I could understand the discussions and occasionally contribute my own suggestions.

A few months earlier, I was worried about accidentally breaking the project.

Now, I was trusted to work on parts of it independently.

The change didn't happen because I suddenly became an expert programmer.

It happened because my way of thinking changed.

"It Works" Is Not the End of the Story

Before working in a professional environment, a large part of my programming mindset was simple:

Write the code. Make it work. Complete the task.

But real-world engineering made me look beyond that.

I started thinking about why code was structured in a particular way.

I started trying to understand the system before changing it.

I started considering what could break.

I started thinking about how one change could affect another part of the system.

I started learning that engineering isn't just about solving the problem in front of you.

It's also about understanding the consequences of the solution.

Good engineering isn't always about writing the most clever code.

Sometimes, it is about writing code that someone else can understand.

Sometimes, it is about making the smallest safe change instead of rewriting everything.

Sometimes, it is about spending more time understanding the problem before touching the code.

And sometimes, the most important skill isn't knowing the answer.

It's knowing how to find it.

Becoming Part of the Team

By the end of those three months, I had gone from being afraid of touching an unfamiliar production codebase to becoming someone who could work independently and contribute to the team.

I had started with:

Can I do this? What happens if I mess up?

And slowly, that changed.

I wasn't just completing tasks anymore.

I was understanding why things were built the way they were.

I was participating in discussions.

I was beginning to understand architectural decisions.

I was becoming more comfortable navigating unfamiliar parts of the system.

Most importantly, I was becoming someone the team could rely on.

That was one of the most meaningful parts of the experience for me.

Not because I had become an expert.

But because I had seen how much a person's approach can change in just a few months when they are willing to learn, ask questions, observe experienced engineers, and slowly take responsibility for their own work.

You Don't Need to Understand Everything on Day One

One of the biggest lessons I took from this experience is something I still remind myself whenever I enter a new project or codebase.

You don't need to understand everything on day one.

When you first open a large or unfamiliar codebase, it can feel overwhelming.

You see files you didn't create.

Patterns you don't fully understand.

Decisions made before you joined.

Dependencies between components you haven't even discovered yet.

And it's easy to think:

Maybe I'm not ready for this.

But not understanding everything immediately doesn't mean you aren't capable of working with it.

Your job isn't to understand the entire system on the first day.

Your job is to learn how to find your way through it.

Ask questions.

Trace the flow.

Understand the problem.

Observe how experienced engineers approach it.

And slowly build your own way of thinking.

That was the beginning of a major transition for me.

From writing code because it works...

To trying to understand why it works, how it fits into a larger system, what could break, and how I should approach changing it.

I'm still learning.

But my apprenticeship at ISRO was one of the first experiences that made me feel myself beginning to think less like someone completing a programming task and more like an engineer learning how to work with real systems.

But That Was Only the First Part

By the time I reached this point, I had learned something important:

How to work inside an existing system.

I had learned how to approach an unfamiliar codebase, understand how experienced engineers think, and slowly become more independent within a team.

But then I wanted to move toward something I was increasingly interested in:

Artificial Intelligence.

That decision would take me into the next phase of my apprenticeship at ISRO.

This time, the challenge would be different.

I wouldn't simply be joining an established workflow and learning how to find my place within it.

I would have much more ownership.

I would be working on an AI-focused project largely on my own, with guidance from a mentor.

And that experience taught me another important lesson:

Watching experienced engineers think can teach you a lot. But eventually, you have to learn how to make decisions and solve problems yourself.

That's a story for Part 2.

This article focuses on my personal learning experience and engineering growth during my apprenticeship. It does not discuss or disclose confidential projects, systems, code, or operational information.

DEV Community: Chaitanya Pranav Sai Kodamasimham