DEV Community: Rajkumar Thangavel

The API Didn’t Fail. Our Preparation Did.

Rajkumar Thangavel — Sat, 29 Aug 2026 06:54:45 +0000

I recently came across a situation that reminded me of one important lesson in development:

Don’t wait for SIT or UAT to discover what your API can handle.

Imagine an API that works perfectly during development and SIT with normal test data. Everything looks fine.

Then, suddenly, during testing, someone sends a much larger response — maybe millions of records or a payload that crosses the expected limit — and the API can't handle it.

Now it's a last-minute problem.

That’s exactly why I believe API behaviour should be documented before it reaches SIT.

Things like:

Expected response size and capacity
Maximum supported load
Timeout limits
Failure scenarios
Large-data behaviour
Server/resource limitations
Expected error responses

These shouldn't be questions we discover during UAT.

There’s another lesson I’ve learned from the same experience:

Once a feature reaches UAT, don't casually introduce new requirements.

Whether it's frontend or backend, a new requirement at that stage can affect existing functionality, testing, integrations, and timelines.

If something genuinely new comes in, it should go through proper change management and impact analysis rather than quietly becoming part of the current release.

The more I work on projects, the more I realise:

Good development isn't just about making the happy path work.

It's about asking “What can go wrong?” before the environment tells us.

Tags

#SoftwareDevelopment #API #BackendDevelopment #SoftwareTesting #SIT #UAT #QualityEngineering #DeveloperExperience #Agile

My AI Coding Assistant Was Quietly Stealing My Productivity 😅

Rajkumar Thangavel — Fri, 28 Aug 2026 05:53:56 +0000

I recently noticed something funny while working with AI coding assistants.

I give AI a feature request, write a detailed prompt, and hit Enter.

Then AI starts doing its thing.

Sometimes it takes 10–15 minutes to generate the code.

So naturally, I'm not going to sit there staring at the screen for 15 minutes. 😄

I move to another task.

Then AI suddenly asks:

“Allow access?”

Meanwhile, I'm happily working on something completely different.

I come back later, click Allow, and go back to my other work again.

Sometimes the AI finishes the task while I'm away.

And sometimes... I completely forget that I even gave it a task. 😂

But there's another problem too.

If I decide to stay and watch the AI work, I'm basically doing this:

AI: Generating code...
Me: 👀
AI: Still generating...
Me: 👀
My productivity: 📉

That's when I started using a simple trick:

I set a timer.

I give the AI the prompt → start a timer → move to another task.

When the timer goes off, I come back and check:

Did the AI finish?
Is it waiting for permission?
Did something fail?
Is the output ready for review?

If it's still working, I set another timer and continue with my other work.

This small habit has helped me avoid both extremes:

Waiting for AI = wasted time.
Forgetting about AI = wasted opportunity.

AI should work alongside my workflow, not become the workflow.

Sometimes, the best productivity feature isn't another AI tool.

It's a simple timer. ⏱️😄

Tags

#AI #AICoding #CodeAssistant #DeveloperProductivity #SoftwareDevelopment #Productivity #DeveloperExperience #AITools #CodingWithAI

Before You Touch a Project, Understand Its Environment Flow

Rajkumar Thangavel — Fri, 28 Aug 2026 05:50:52 +0000

One thing I always try to understand when I join a new project is how the environments are connected.

A typical setup has three important environments:

DEV → UAT → MAIN (Production)

DEV is the playground for developers. Features are developed, tested, and validated here, usually through feature branches.

Once the feature is ready, it moves to UAT for proper validation.

UAT should closely mirror Production. It shouldn't be treated as another playground because any instability there can directly affect release validation.

Finally, after UAT testing and approval, the changes move to MAIN, which is connected to the live application used by real users.

The flow is simple:

Develop → Test → Validate → Release

But understanding this flow before starting development is important.

Because one wrong assumption about branches or environments can create unnecessary conflicts, broken UAT deployments, or even production issues.

My advice:

Before writing your first line of code in a new project, understand where your code goes, how it gets promoted, and which environment represents what.

Knowing the environment flow is just as important as knowing the codebase.

Tags

#SoftwareDevelopment #Git #GitWorkflow #DevOps #UAT #Production #DeveloperExperience #SoftwareEngineering #Agile

Formal vs Informal Testing: Both Matter More Than We Think

Rajkumar Thangavel — Fri, 28 Aug 2026 05:49:49 +0000

Recently, I noticed our testing team discussing formal testing vs informal testing, and it made me think about something I've experienced quite often as a developer.

The difference is actually pretty simple.

Formal testing is structured and planned.
There are defined test cases, expected results, test data, execution steps, and documented outcomes.

Informal testing is more exploratory.

You don't necessarily follow a predefined test case. You try different inputs, unusual scenarios, edge cases, and sometimes simply ask:

“What happens if I do this?”

Both are important.

Formal testing helps us make sure the application behaves according to the requirements.

Informal testing helps us discover the things we didn't think about while writing the requirements.

And this is where I think developers have an important responsibility.

Before handing a feature over to the testing team, developers should do both.

Don't just verify:

“Does my code work?”

Also try:

“How can I break my code?”

Check the happy path.
Try invalid inputs.
Try unexpected combinations.
Try boundary conditions.
Think about what a real user might do — even if it wasn't mentioned in the requirement.

Because the testing team shouldn't be the first people to discover that our feature is broken.

They should be the people who validate and challenge the confidence we've already built as developers.

Tags

#SoftwareTesting #Testing #QualityEngineering #SoftwareDevelopment #DeveloperExperience #QualityAssurance #Agile #CleanCode #ShiftLeftTesting

AI Makes Development Faster. But It Can Also Create More Dead Code.

Rajkumar Thangavel — Fri, 28 Aug 2026 05:48:08 +0000

One thing I've started noticing while developing with AI code assistants is that faster development can sometimes hide a new problem — dead code.

A requirement comes in.

I use an AI coding assistant, generate the implementation, test it, and move on.

Then the requirement changes.

Instead of completely revisiting the previous implementation, we often modify the existing code to fit the new requirement. And that's where things can get messy.

Old functions, conditions, components, variables, and logic may no longer be needed — but they quietly stay in the codebase.

The same thing can happen with test cases.

A requirement changes, but the old test cases remain. They may still pass, but they're no longer relevant to the current behaviour.

AI makes this easier to overlook because we can generate and modify code so quickly.

So I've started treating requirement changes differently:

When a requirement changes, don't just ask AI to modify the existing code. Ask it to identify and remove everything that became obsolete.

And when the requirement is updated:

Review the existing implementation.
Remove unused code.
Review related test cases.
Remove obsolete tests.
Add tests for the new behaviour.
Run the full relevant test suite.

AI can help us write code faster.

But we still need to be responsible for what stays in the codebase.

The goal shouldn't be to generate more code.

The goal is to maintain only the code we actually need.

Tags

#AICoding #CodeAssistant #SoftwareDevelopment #CleanCode #DeadCode #Testing #DeveloperExperience #AI #CodeQuality

What Veeva Quality Taught Me About Good Documentation

Rajkumar Thangavel — Fri, 28 Aug 2026 05:39:10 +0000

Recently, while working with Veeva Quality, I realised that documentation is a lot more than just writing down information.

In the beginning, I thought the process would be straightforward — create the document, add the required details, review it, and move on.

But real-time work taught me something different.

When you're dealing with quality-related documentation, every small detail matters.

You need to understand how information should be structured, how documents should be reviewed and maintained, and even how images, diagrams, and other visual elements should be interpreted and documented correctly.

That made me realise that documentation is actually a skill of its own.

It's not just:

“Write something and save it.”

It's about making information clear, accurate, traceable, and easy for someone else to understand later.

My experience with Veeva Quality has made me want to learn more about proper documentation practices — especially how to structure technical information, handle visual content, and create documentation that can actually stand on its own.

Sometimes, the best lessons don't come from a course.

They come from working on something real and realising:

“Oh… I need to get better at this.”

Veeva #VeevaQuality #Documentation #QualityManagement #TechnicalDocumentation #DeveloperExperience #SoftwareDevelopment #LearningFromExperience

The API Didn’t Fail. Our Preparation Did.

Rajkumar Thangavel — Mon, 24 Aug 2026 03:30:00 +0000

I recently came across a situation that reminded me of one important lesson in development:

Don’t wait for SIT or UAT to discover what your API can handle.

Imagine an API that works perfectly during development and SIT with normal test data. Everything looks fine.

Then, suddenly, during testing, someone sends a much larger response — maybe millions of records or a payload that crosses the expected limit — and the API can't handle it.

Now it's a last-minute problem.

That’s exactly why I believe API behaviour should be documented before it reaches SIT.

Things like:

Expected response size and capacity
Maximum supported load
Timeout limits
Failure scenarios
Large-data behaviour
Server/resource limitations
Expected error responses

These shouldn't be questions we discover during UAT.

There’s another lesson I’ve learned from the same experience:

Once a feature reaches UAT, don't casually introduce new requirements.

Whether it's frontend or backend, a new requirement at that stage can affect existing functionality, testing, integrations, and timelines.

If something genuinely new comes in, it should go through proper change management and impact analysis rather than quietly becoming part of the current release.

The more I work on projects, the more I realise:

Good development isn't just about making the happy path work.

It's about asking “What can go wrong?” before the environment tells us.

Tags

#SoftwareDevelopment #API #BackendDevelopment #SoftwareTesting #SIT #UAT #QualityEngineering #DeveloperExperience #Agile

The Underrated Microsoft Loop Workflow I Use for Project Knowledge

Rajkumar Thangavel — Sat, 22 Aug 2026 13:45:00 +0000

In my previous posts, I shared how I use Microsoft To Do for daily tasks and OneNote as my work journal.

Another underrated tool I use is Microsoft Loop.

I mainly use Loop as a project knowledge hub.

For each project module, I create a separate page and document things like:

What the module does

Its purpose and functionality

Important workflows

Supporting documentation

Useful tables and references

The formatting flexibility is one thing I really like about Loop. I can bring headings, tables, links, notes, and other content together on a single page without making it feel like a messy document.

It becomes especially useful when I'm preparing project documentation.

I also use Loop as a central place for important links.

Instead of keeping everything as browser bookmarks, I maintain a page with links I frequently need — leave applications, mandatory learning, project resources, client documents, shared Excel files, and other frequently used resources.

So when I need something later, I know exactly where to look. I also create separate pages for different project modules and keep their relevant information together.

But there is one important lesson I've learned while using multiple productivity tools:

Don't duplicate the same information everywhere.

If the same content exists in To Do, OneNote, Loop, emails, and another document, maintaining all of them can become a productivity problem of its own.

The goal of productivity tools is to reduce mental overhead, not create another task to manage.

So my approach is simple:

To Do → Tasks

OneNote → Daily learning & work journal

Loop → Project knowledge, documentation & resources

Give each tool a clear responsibility, and don't make one tool do everything.

Sometimes, the best productivity system isn't about using more tools.

It's about knowing exactly what each tool is for.

Tags

MicrosoftLoop #Productivity #DeveloperProductivity #SoftwareDevelopment #KnowledgeManagement #ProjectDocumentation #DeveloperExperience #ProductivityTools #Microsoft365

The First “Can You Work This Weekend?” Is Never Just One Weekend 😅

Rajkumar Thangavel — Fri, 21 Aug 2026 13:45:00 +0000

I learned this one the hard way.

When a project gets hectic, the first request usually sounds very innocent:

“Just this weekend. Can you help us out?”

The first time, the Project Manager asks nicely. You understand the situation, agree, and spend your Saturday/Sunday working.

Then the next week comes.

“This weekend also, we may need some support.”

You agree again.

And suddenly, the following week, the conversation changes:

“The team will be working this weekend.”

Wait… WHO agreed to that? 😂

At some point, your one-time exception quietly becomes the team's new expectation.

Even if someone says, “We'll give you a comp-off,” the real issue is not the comp-off.

It's the precedent.

Once people know you're always available on weekends, weekend availability slowly becomes part of your unofficial job description.

So I've started looking at it differently:

Saturday and Sunday are already booked.
Booked with “personal commitments.” 😄

Of course, genuine emergencies happen, and sometimes we may need to step up as a team.

But making weekend work a regular habit just because we said “yes” once is something we should be careful about.

Because sometimes the most expensive “Sure, I'll help this weekend” is the one you keep saying every week.

Tags

#WorkLifeBalance #DeveloperExperience #SoftwareDevelopment #WorkplaceCulture #CareerAdvice #ProfessionalBoundaries #DeveloperLife #Agile #Productivity

The Simple Project Onboarding Habit That Saves Me Time Later

Rajkumar Thangavel — Thu, 20 Aug 2026 02:30:00 +0000

Whenever I join a new project, the first few days are usually about understanding the project, meeting the team, and getting familiar with the setup.

Recently, I started doing one more thing during onboarding.

I create a project resource sheet.

I keep track of:

Project manager and key stakeholders
Team members and their roles
Client-side dependencies
Areas of expertise and skills
Official work contact details

It sounds simple, but I've found it surprisingly useful.

A few weeks later, if I suddenly need to contact someone about a specific issue, I don't have to search through old emails, chats, or meeting notes.

I can quickly check:

Who owns this area?
Who has the right skill?
Who should I contact?

It also helps during stand-ups, retrospectives, and task discussions.

For example, if a task suddenly needs some backend knowledge and I know a frontend developer on the team also has strong backend experience, I can suggest that person instead of randomly looking for someone.

I recently started practicing this in a real project, and it has already made communication much easier.

Knowing your project is not just about knowing the codebase.

It's also about knowing the people behind it.

⚠️ A small but important note: This sheet can contain sensitive work-related information. It should be created and maintained only using your official work account/work-approved storage. Avoid keeping employee IDs, phone numbers, or other work contact details in a personal account or personal spreadsheet, as that may violate company security and data-handling policies.

Tags

#SoftwareDevelopment #DeveloperExperience #ProjectManagement #Teamwork #DeveloperProductivity #Agile #ProjectOnboarding #WorkplaceProductivity

The Last-Minute Merge Problem

Rajkumar Thangavel — Mon, 17 Aug 2026 05:22:59 +0000

One thing I recently faced in my team reminded me how painful last-minute merges can be.

We were getting ready for a release. Different team members were working on different branches, and when everything came together, we started seeing conflicts in the main branch.

What made it worse was that some conflicts had already been fixed, but a few changes were still floating around in different branches. So we had to bring people together, figure out who changed what, resolve the conflicts, and make sure nothing important was accidentally missed.

And all of this happened right before the release.

That experience made one thing very clear to me:

Merge conflicts are much easier to solve early than at the last minute.

A simple habit can make a big difference:

Know who is working on what.
Keep the team coordinated when changes overlap.
Merge and validate changes regularly.
Don't wait until release day to discover integration problems.

The problem isn't really the conflict itself.

The problem is discovering the conflict when there is no time left to deal with it properly.

Something I'm definitely taking forward from this experience.

SoftwareDevelopment #Git #GitHub #GitWorkflow #VersionControl #Teamwork #DeveloperExperience #Agile #DevOps #CodeReview

From Typing Prompts to Talking to AI — A Small Tool That Changed My Workflow 🎙️🤖

Rajkumar Thangavel — Sun, 16 Aug 2026 12:27:51 +0000

From Typing Prompts to Talking to AI — A Small Tool That Changed My Workflow 🎙️🤖

One thing I’ve noticed since AI became a regular part of my development workflow:

The way I interact with AI has completely changed.

Earlier, I would carefully type a prompt, edit it, add context, fix the wording, and then send it.

Now, I often just talk to AI.

I explain the problem the way I would explain it to another developer — naturally, with context, examples, corrections, and all the small details that come to my mind.

But typing all of that manually can still take time.

That’s where I recently started using Handy.

Handy is a free, open-source speech-to-text application that runs locally on your computer. It uses speech recognition models such as OpenAI Whisper to convert what you say into text. It can also detect the language automatically, which makes it especially useful when switching between languages while speaking.

My workflow now looks something like this:

🎙️ Speak naturally

↓

🧠 Whisper understands the speech

↓

📝 Speech → structured text

↓

🤖 Send it to AI

↓

💡 Get the solution

Another thing I really like about Handy is that it is open source and extensible. You can choose the speech model that fits your requirements, and Whisper is one of the models I personally recommend trying.

For developers who use AI heavily, I think this kind of workflow can save a surprising amount of time.

The interesting part of AI isn't just that it can write code for us.

It's that it is also changing how we communicate with computers.

We started with:

⌨️ Typing commands

Then:

💬 Typing prompts

Now:

🎙️ Talking naturally to AI

And I think we're only getting started.

If you're someone who uses AI regularly for coding, writing, research, or documentation, give voice-based AI interaction a try.

It might change the way you work.

AI #OpenSource #Whisper #Handy #AICoding #DeveloperProductivity #VoiceAI #SoftwareDevelopment #ArtificialIntelligence