DEV Community: pratikshya behera

Find Documentation boring? Here's how it saved me from a loop of rework:

pratikshya behera — Thu, 18 Sep 2025 12:35:13 +0000

pratikshya behera

Sep 18 '25

From Chaos to Clarity: Lessons learnt on the Importance of Documentation

#webdev #programming #softwaredevelopment #documentation

Comments

2 min read

From Chaos to Clarity: Lessons learnt on the Importance of Documentation

pratikshya behera — Thu, 18 Sep 2025 12:32:51 +0000

Recently, I was writing a module with multiple APIs for a new project. I started with the fundamental API. The team had multiple rounds of discussions. I put in hours writing code, testing, and debugging.

When I raised the PR, it went through rigorous reviews (as it happens with any new functionality module), until finally the changes were merged and deployed.

But in the next meeting with the Business team, we realized that we missed a major point in the earlier discussions. And one missed point translated into reworking the whole API from scratch.

It became clear that without a structured approach, we risked falling into the same cycle of rework again. The solution that saved us was documentation.

The functionality was complex and difficult to grasp at once, and therefore, there's a high chance we'll go through the cycle of rework repeatedly.

After the meetings, I created a detailed document capturing:

My understanding of the functionality from all prior discussions.
The proposed API details and workflow to support the functionality.

I shared this document with all stakeholders — developers, my SPOC, the Product Manager, Backend Leads, and our Engineering Manager. This opened the floor for collective feedback, corrections, and even better suggestions for the API flow.

We decided to pause all coding work until the documentation was finalized and approved. Once everyone aligned on the functionality and API structure, I restarted development. This time, the process was much smoother:

I had a solid reference point to resolve any confusion.
Most potential blockers had already been addressed during the documentation phase.
The overall development aligned seamlessly with the agreed functional flow.

Looking back, I realized how one well-structured document saved me hours of frustration, rework, and repeated discussions. It gave me clarity, reduced my mental load, and gave my team a single source of truth to rely on.

My takeaway (and advice to you): Don’t treat documentation as an afterthought. Use it as your first step.
If it worked for me in a complex API module, it can work for you too — no matter what you’re building.
Start documenting more, and you’ll see the difference it makes in your speed, clarity, and confidence as a developer.

How to Avoid TLE (Time Limit Exceeded) Errors in Coding Problems

pratikshya behera — Sun, 13 Jul 2025 12:45:19 +0000

Time Complexity is the most basic yet most crucial aspect of any efficient code.
When solving problems on platforms like LeetCode, Codeforces, HackerRank, or GFG, we often start with the most intuitive logic — commonly called the Brute Force Approach.

But here’s the twist:
Even if your logic is correct, your code might still fail with a TLE (Time Limit Exceeded) error. So what gives?

Pro Tip Before Submitting Your Code

Always estimate the time complexity of your solution based on the input constraints before hitting submit.

Here’s a good rule of thumb:

Your solution should not exceed 10⁸ operations per second.

So if your input size is n = 10⁵, your code must run in about O(n) or O(n log n) time, not O(n²) or worse.

Reference list of Time Complexities to predict if your solution may lead to a TLE error according to the input constraints:

Work on logic that sustains the needed time complexity for a good solution.

Final Checklist Before Submission:

Estimate your code’s time complexity.
Compare it with the input constraint.
Rewrite or optimize before it’s too late.

Time complexity isn’t just a theoretical topic to be studied, it’s a coding skill just like logic.

Also published at: https://medium.com/@bpratikshya30/how-to-not-get-a-tle-8159bb06c3bd

What Is Callback Hell in JavaScript? Explained with Example and Promise Solution

pratikshya behera — Thu, 03 Jul 2025 16:02:53 +0000

Callback Hell is a common problem in JavaScript that should be avoided for efficient coding.

In this post, we’ll understand what callback hell is, how it happens, and how to fix it using Promises.

What Are Callbacks?

Callback in JavaScript is the concept that says we can pass a function as an argument to another function.
For example, we have 2 functions and they shall only be called one by one and in a fixed sequence:

To ensure the second function is called only after the first function, we can use a callback like:

Note:
_Do not call the function in this way: first(1, second());
Parenthesis () indicate immediate execution of the function second. Hence, second will execute during the first function call and throw an error.
_
If the callback needs arguments, wrap it in an arrow function:

This was a simple example of 2 functions, but in real-world scenarios, we may have to deal with multiple functions that need to be executed in a specific sequence, each function depending on the output of another function.

Real-Life Example: Social Media App Flow

Validate username
If valid, check the password
On success, fetch feed
Click on a post → show reaction count
Click on reaction → show user list
Click on a user → show profile
In code, each activity can be considered a function.

Here setTimeout function is used for asynchronous execution of code.

Now let’s see what happens when we use callbacks to execute the code:

This scenario gives rise to nested callbacks, also known as Callback Hell.

Callback Hell is nested callbacks stacked below one another. These callbacks often form a pyramid structure, hence also known as the Pyramid of Doom.

Using callbacks in this way leads to a style of programming that is difficult to understand and thus difficult to manage.

Callback Hell shall be avoided in real-world programming.

Solution: Promises

To solve this problem and produce more understandable and manageable code, we use Promises in JavaScript.

A Promise is an object in JavaScript used for eventually completing a task, but not immediately.

Syntax to define a Promise:

Here, resolve and reject are two callbacks or handlers provided by JavaScript.

Let’s rewrite our app logic using Promises:

The code to execute our functions using Promises:

Conclusion

Callback Hell is a common struggle in JavaScript, especially in real-world applications. But by using Promises, we can write cleaner, understandable, and more maintainable async code.

Agile Lessons: Navigating Shifting Priorities in a Tech Career

pratikshya behera — Sat, 24 May 2025 06:57:46 +0000

I was recently working independently on a PoC for the first time. An existing feature needed significant changes to accommodate new requirements in our product. This eventually grew into a platform-level feature implementation across all our products.

After working for more than an year as a junior, this was my first independent task of real significance. As I was 3 weeks into the work, the initial discussions and study were just completing.

Before I could get the approval for the next phase of the PoC, a new client signed in for a new product development. While I was preparing for my next meeting presentation, we were called in for a discussion.

After the meeting, all our tracks and tasks were put on hold until the new product was ready.

This is normal in a tech company. A few months ago, I would have been devastated to be taken off the work I was so invested in. It has happened before, but perhaps now I know better, because this time, I felt nothing.

We all know what happens when product enhancements clash with the client’s requirements. The enhancements will be blocked until someone takes them up voluntarily. And yet in a fast-paced environment, it’s not likely that someone will find the time to take up work on top of their existing load.

So yes, my first independent PoC might just go under the rug and never get implemented.

But now I think this is what experience teaches us. This detachment is professionalism. The ability to shift from one track to another without feeling sad or angry because you know that’s how it works, that’s what comes with experience.

This situation showed me that I am an asset to my company because this is the second consecutive time that I have been assigned to a completely new project.

And for now, I’ll go with that.After working for more than an year as a junior, this was my first independent task of real significance. As I was 3 weeks into the work, the initial discussions and study were just completing.

After the meeting, all our tracks and tasks were put on hold until the new product was ready.

So yes, my first independent PoC might just go under the rug and never get implemented.

This situation showed me that I am an asset to my company because this is the second consecutive time that I have been assigned to a completely new project.

And for now, I’ll go with that.

How AI Chatbots Helped Me Improve at LeetCode Without Giving Me the Answers

pratikshya behera — Sat, 17 May 2025 13:12:41 +0000

When I started practicing Leetcode again after a year of experience in Web development, I knew I’d need some help.

Reluctant to take help from AI chatbots, I kept moving back and forth to chatbots every time my submission failed.
This kept me wondering if I can solve these problems on my own or if I have lost my potential after coding every day alongside AI chatbots at work for all these days.

Until I realized why we started coding with chatbots in the first place — to learn better.

After I solved a problem on my own and put the code through a chatbot, I found more ways to approach the problem.
I could see why my code has a longer runtime than another solution.
I could analyze my own solution deeply and improve my ways gradually.

Like, I solved a problem on Array Wrapper with a traditional approach with 49ms of runtime. After analyzing the solution with AI I learned that the same problem can be solved with an Arrow function implementation, which reduces the runtime to 32ms.

One can say that you can find hundreds of solutions online, but it’s not about solutions on platforms like Leetcode; it’s about the skill to solve problems better.
AI can help analyze solutions in depth and improve the approach altogether in the long run.

I have one rule when solving problems: don’t ask AI for solutions.
Because every problem out there on these platforms is solved already. What I am doing is polishing my problem-solving and coding skills.

I ask for bits and pieces when I get stuck, but to put everything together into an actual solution is always my job.
And after solving each problem, I ask AI to analyze or improve my solution.

This keeps me confident in my own capabilities and helps me learn better with AI — because Leetcode isn’t about finding solutions, but about developing the skill to solve problems.

Want to read about learning AWS through work experience in a fast paced start-up? My latest article serves it just right. Happy learning!

pratikshya behera — Mon, 28 Apr 2025 17:08:11 +0000

pratikshya behera

Apr 28 '25

How AWS Kinesis and Lambda Work Together to Send Emails Instantly

#aws #serverless #node #webdev

Comments

3 min read

How AWS Kinesis and Lambda Work Together to Send Emails Instantly

pratikshya behera — Mon, 28 Apr 2025 01:50:30 +0000

Recently, I was working on a new project — a clone of the company’s original product — and was assigned a ticket regarding an email sending issue on a high-priority feature.

While working on the ticket, I came across the AWS service Kinesis.

I added all necessary constants, configurations, and conditions for the new project into the code and ran a self-call (I work with NodeJS). However, I encountered the following error:

ResourceNotFoundException: Stream l*l_microservice_backend under account 2********1 not found.

Reason:

The Kinesis data stream l***l_microservice_backend, originally present in our product instance, had not yet been created on the new project’s AWS instance.

Solution:

I created the Kinesis data stream in the new instance with the help of my mentor.

What is a stream, and where does Kinesis come in?

Amazon Kinesis is a real-time data streaming service.
It is used to process and stream large volumes of data efficiently.

Kinesis is commonly used for:

Events
Clickstreams
IoT sensor data
Video streams
Logs

Kinesis has 4 Core components:

Kinesis Data Streams (KDS)
Kinesis Data Firehose
Kinesis Data Analytics
Kinesis Video streams

We implement our email sending service using KDS or Data Streams in Kinesis.
We can create data-processing applications, known as Kinesis Data Streams applications.
A typical Kinesis Data Streams application reads data from a data stream as data records.

When we say we created a new "data stream," we are actually referring to setting up a data stream and a Kinesis Data Streams application to process a specific set of data records.

The delay between the time a record is put into the stream and the time it can be retrieved (put-to-get delay) can be less than 1 second.
We can scale the stream up or down based on the application’s requirements, so we never lose any data.

How we used Kinesis?

In Kinesis, there are two major components:

Producer: Anything that puts data into the stream.
Consumer: Anything that reads data from the stream and processes it.

In our case, the producer is the service that I was testing, and a subsequent function that communicates directly with the KDS.
In a sequence of service calls, we prepared some data and used that data further in an email template.
Then we sent the email template along with some other details to the KDS as the producer.

The consumer of the KDS in our case is a Lambda.
The Lambda contains code to process the output of the data stream application to perform the needed actions.
Our Lambda decodes the response from KDS into a usable form.
Then the Lambda code uses the business logic to take the required action— here sending emails.

Using Kinesis makes it possible to send bulk emails instantly.

Summary

What Kinesis does:

It's an AWS service that handles real-time data like events, logs, or sensor data super fast.

It has different parts, but we mainly use Kinesis Data Streams (KDS) for sending emails in our app.

How we use it:

One of our services acts like a producer — it prepares the email details and sends them into the stream.

A Lambda function reads from the stream, processes the info, and sends out the emails.

Using Kinesis helps us send bulk emails almost instantly and handle scaling easily.

Work-Life Harmony in the Tech World: A Woman’s Guide to Staying Sane

pratikshya behera — Sun, 06 Apr 2025 12:15:53 +0000

As software developers, we spend 8–9 hours a day, working 5 days a week. But does your mind passively think about work even after you’re done working? Let’s change that.

We work in a male-dominated field. This brings with it the fear of being seen as less capable, even for the simplest mistakes. There is often a constant need to prove ourselves worthy of our position. Hence, we tend to overanalyze past conversations and work to ensure quality.

We tend to question if we’re doing it right, constantly feeling like we need to catch up even when we aren’t lacking in any way. Each time after logging off, we keep wondering if we were good enough today.

We start blurring our boundaries — not because the job demands it 24/7, but because deep down, we fear being labelled less competent. As women, especially those balancing family expectations or invisible responsibilities, we overcompensate, just to prove we can handle it all.

The so-called “hustle culture” is often glorified in many tech workspaces. Instant replies to any communication and constant availability are totally normalized, being seen as a sign of dedication.

Most of the success stories we see are of women who seemed to have it all together — the promotions, the late nights, the spotless image. But we rarely see the sleepless nights, the missed birthdays, the quiet moments of burnout they faced. The toll it took is often edited out of the story, as if struggle isn’t worth mentioning unless it ends with success.

As women early in our careers, especially when we’re underpaid or overlooked, we carry a quiet fear of falling behind. While others seem to rise, we worry we’re being passed over. So we overcompensate. We take on more, stay late, reply at odd hours — not just out of ambition, but from a deeper need to prove we deserve our place.

So, how to keep the balance?

We can’t just find the balance. We need to build a balance between work and life.

We start by redefining what success means to us. Not by how long we stay online or how many things we juggle — but by how we feel while doing it. Calm, clear, and proud.
We learn to set boundaries without carrying guilt. Logging off doesn’t mean we’re slacking. Saying no doesn’t mean we’re not ambitious or rude. It just means we’re choosing to protect our energy — and that’s brave.
We slow down and ask if the pace feels right. Sometimes we rush because we’re afraid to fall behind. But growth isn’t always fast, and it doesn’t need to be.
We stop measuring our worth by our output. Our value isn’t tied to tasks or timelines. We are allowed to rest and start again later.
We find our people. Whether it’s one friend who truly gets it or a group of women lifting each other, we keep those people around who enhance our energy.
We try to become the role models we didn’t get to see. Not perfect, but honest. Women who work hard but also pause, protect their peace, and show others that balance is possible.
And most importantly, we permit ourselves. To take a breath. To log off. To grow differently. To do enough — and to believe that we are enough, even when the world forgets to say it.

What matters is that we’re aware. That we’re trying. That we’re unlearning the noise that says we have to do more, be more, prove more just to be taken seriously.
We’re already enough. We’re allowed to rest.
And we can build careers we’re proud of — without burning out along the way.