Forem: Pooja Sharma

Day 13 & 14 / 120 : When Access Friction and Standup Noise Distort Progress

Pooja Sharma — Thu, 12 Feb 2026 13:30:36 +0000

A full day was spent securing repository access. The process required multiple follow-ups and cross-team coordination. Instead of resolving access structurally, suggestions were made to comment out failing code to bypass errors. That workaround culture would have enabled short-term progress at the cost of long-term instability.

Standups became high-noise environments: raised voices, accusations of slow progress, and pressure to deliver despite unresolved blockers. Developers were stalled by access gaps, then later criticized for delays. Requests were made to bypass local testing before SIT deployment—followed by criticism about not adhering to protocol.

Questions already documented in Jira resurfaced verbally, increasing repetition and cognitive load. Abstract discussions lacked concrete ownership or sequencing.

The response was deliberate:

Persisted through formal access resolution instead of using unsafe shortcuts
Documented blockers clearly in Jira and tagged stakeholders to keep conversations asynchronous
Maintained composure in standups without escalating emotionally
Continued building observability depth: Prometheus alerting, PromQL queries, Tempo traces, Sentry stack trace interpretation

One Takeaway for Software Engineers

In enterprise environments, public noise does not equal engineering direction.

Access hygiene, documentation discipline, and refusal to normalize unsafe shortcuts are structural skills—not overhead. Clear async traceability protects engineers when verbal narratives shift.

Over time, the ability to diagnose systemic friction becomes more valuable than reacting to it.

Day 11 & 12 - Finding Energy in Deep Systems Work

Pooja Sharma — Tue, 10 Feb 2026 13:16:11 +0000

Not every tough phase ends with frustration. Some end with quiet satisfaction.

Post-weekend ramp-up was mentally heavy—new product context, limited documentation, and standups that still felt noisy and reactive. Priorities shifted quickly. On Monday, feature work paused to focus on alerts and monitoring due to anticipated traffic growth. By Tuesday, a new urgent requirement surfaced with an already committed deadline.

The environment remained imperfect. But something changed internally.

Instead of resisting the shift, I leaned into it.

Observability work became an unexpected anchor. I explored Prometheus configs, built dashboards in Grafana, and revisited core ideas—metrics, traces, spans, latency percentiles, and error signals. I exec’d into the application pod to see which APIs were actually being hit and what latency patterns looked like in practice. Auditing existing .prom files gave clarity that documentation hadn’t.

There was real joy in learning how the system actually behaved.

Access issues still existed, but tools and curiosity bridged the gaps. Even more energizing was the team itself—developers pausing their own work to help unblock things quickly, without ego or hesitation.

One Takeaway for Software Engineers

When external conditions feel unstable, deep technical learning can be a source of calm and confidence.

Understanding systems at a first-principles level creates progress that doesn’t depend on Jira movement. It compounds quietly—and stays with you long after the sprint ends.

These days were a reminder of why I enjoy this field: learning, collaboration, and the satisfaction of clarity earned through exploration.

Day7&8 - When Decisions Refuse to Land

Pooja Sharma — Fri, 06 Feb 2026 14:18:34 +0000

Some days, progress doesn’t slow because code is hard.
It slows because decisions refuse to settle.

By Day 7, the architecture had already been discussed, aligned, and agreed upon—with the architect, the lead, and other developers. Implementation was well underway. Then the questions resurfaced.

Why BigQuery and not Postgres or Mongo?
Why Elasticsearch at all?

These weren’t new concerns. They were re-openings. And late-stage reversals are uniquely damaging: they erase visible progress while quietly exhausting the people doing the work.

A long meeting followed—11:30 AM to 4:30 PM. Feature development was paused in the name of “platform stability” due to expected traffic growth. The discussion circled around alerts and monitoring, but without concrete scope, owners, or next steps.

The contradiction landed immediately: right after deciding to halt features, the team agreed to continue feature work for one more day.

Decision paralysis, wrapped in serious language.

I stayed present. I didn’t argue in loops. I observed where energy was being lost and where ownership might emerge—alerts and monitoring quietly surfaced as a potential responsibility area.

The key realization came later:

Lack of output wasn’t a performance issue.
It was a decision-making issue.

One Learning for the Future

In environments like this, progress must be measured by clarity created, not just code shipped.

Going forward:

Push for time-boxed decisions
Capture agreements explicitly to prevent retroactive questioning
Conserve energy when discussions generate more noise than direction

When decisions keep shifting, execution gets mistaken for inertia.

Day 5&6 - When You Refuse to Inherit Silent Technical Debt

Pooja Sharma — Wed, 04 Feb 2026 13:43:51 +0000

In some workplaces, technical debt isn’t just tolerated—it’s quietly reassigned.

This phase began with pushback for doing something deceptively simple: naming the problem.

I asked for a task split to account for legacy cleanup. I called out that the handed-over branch hadn’t been synced with master for nearly four months and classified it plainly as technical debt. The response was defensive.

“This is software engineering.”
“You don’t get a fresh branch.”

What those statements really meant was: this disorder is normalized, and questioning it is inconvenient.

The feature itself had been picked months before I joined. Context was missing. KT was incomplete. Access delays were real. Yet the narrative forming around me was about “1.5 months without dev work”—as if blocked time was inactivity.

By Day 5, the feedback escalated into questioning my project understanding. That’s when it became clear: if left private, this would quietly become my problem.

So I changed tactics.

I raised the issue in standup—not emotionally, not defensively, but structurally. I separated feature delivery from legacy reconciliation and insisted they be treated as distinct tasks. No silent scope creep.

That moment shifted the room.

Others acknowledged they had reused parts of the same legacy branch. Nothing from it had ever gone to production. What felt like an individual “performance issue” was suddenly visible as a shared system failure.

Day 6 brought a softer tone. Conciliation. Offers of explanation. Validation that my questions were “good.”

I accepted the reset—without forgetting why it was needed.

This wasn’t about winning an argument.
It was about refusing to inherit blame for undocumented debt.

Silence protects dysfunction.
Structure protects engineers.

This was the day the engagement subtly changed—from absorption to self-respect.

Day 4 - When Branch Rot Steals Momentum

Pooja Sharma — Mon, 02 Feb 2026 13:39:40 +0000

“Lost momentum due to legacy branch rot and shifting contracts —-> reset work from master to regain control.”

This day was a reminder that in large codebases, what you inherit matters more than how fast you code.

While testing a pipeline, I discovered that the API contracts had changed. The working branch handed over during KT hadn’t been synced with master for months—something that was never communicated. I had assumed the branch was clean and built on top of it, investing real effort before reality surfaced.

When I tried to reverse-merge from master, the truth became unavoidable: conflicts everywhere, structural drift, and assumptions baked deep into the code. Salvaging it would cost more than restarting.

So I made the call that feels painful but is often correct:
abandon the branch, reset from master, and rebuild.

The irony? Once the foundation was correct, a large part of the actual task was straightforward and could be completed quickly. The delay wasn’t complexity—it was branch hygiene debt.

The hidden cost showed up elsewhere too:

duplicated work
wasted Cursor tokens
frustration from redoing avoidable effort
and, worst of all, a perception forming that I was “over-designing” instead of executing

Standup felt awkward. Progress wasn’t visible. In hindsight, the mistake wasn’t resetting—it was not escalating early enough. Silence leaves space for narratives you don’t control.

This day marked a shift in mindset.

Respecting existing work is important—but correctness and system integrity come first. From here on, validating assumptions, checking branch freshness, and calling out blockers early aren’t overhead. They’re core engineering work.

Survival in code-first big tech isn’t about pushing harder.
It’s about knowing when to stop, reset, and protect the foundation.

Day 1 — Accepting the Impossible Sprint

Pooja Sharma — Fri, 30 Jan 2026 13:56:22 +0000

Day one of the sprint.
Two tasks assigned.
Both impossible to complete within the sprint timeline.

One required new table design, DDL changes, and pipeline wiring.
The other? Unclear, undocumented, and already overdue before it reached me.

I raised concerns. Privately. Clearly.
The timelines didn’t change.

So I accepted the tasks.

Not because I believed they were achievable—but because arguing over deadlines often costs more mental energy than the deadline itself. This is an unspoken rule many developers learn the hard way.

Instead, I shifted focus:

Reduce ambiguity aggressively
Recreate the pipeline locally
Write scripts to understand system behavior end-to-end
Lean on tooling to accelerate understanding, not blind execution

I also started documenting everything—meetings, conversations, assumptions. Not for politics. For protection. In environments where memory is selective, written artifacts become your safety net.

This wasn’t heroics.
This was survival.

Day one wasn’t about delivering features.
It was about stabilizing my own operating system—mentally and technically—before the sprint pressure inevitably escalates.

This series will unpack days like these. Not to glorify burnout, but to name it—so we can navigate it without losing ourselves.

Why This Series Exists: Surviving Code-First Workplaces

Pooja Sharma — Fri, 30 Jan 2026 13:49:44 +0000

Software engineering today isn’t just about writing code.
It’s about surviving environments where code is treated as a magic wand—expected to fix broken processes, unclear requirements, missing access, and unrealistic timelines.

This series is about that reality.

Not the idealized “high-performing agile team” version.
The real one:

Sprints that spill over before they even begin
Tasks accepted despite knowing they’re impossible
Meetings where context is missing but expectations are crystal clear
Pressure to “just deliver” while the system underneath is still shaky In many workplaces, speed is celebrated louder than correctness. Documentation is optional. Ownership is blurry. And when something breaks, the conversation quietly shifts from “what went wrong?” to “who can we point at?”

This series isn’t about ranting.
It’s about survival patterns:

How developers protect their sanity without becoming disengaged
How to communicate risks without being labelled “slow”
How to build reliability in systems that reward shortcuts
How to document reality when verbal commitments are conveniently forgotten

Each article is short. Each one is drawn from lived experience.
Some days will be technical. Some will be psychological. Most will sit in the uncomfortable middle.

If you’ve ever felt that your real job description was “absorbing chaos with code”, this series is for you.

Building Self-Healing, Reliable Data Pipelines That Think

Pooja Sharma — Mon, 03 Nov 2025 09:38:51 +0000

Engineering for Scale, Reliability, and the Future of Agentic Data Systems

When people think of data innovation, they usually picture dashboards and machine-learning insights.
But what truly powers that innovation lies behind the scenes — the data plumbing that quietly ensures information flows cleanly, reliably, and on time.

I was brought into a client engagement where the organization’s data backbone powered a large-scale analytics platform spanning multiple consumer-product domains.
As the business grew, the volume, diversity, and velocity of data expanded dramatically — from thousands of records per refresh to half a million+ rows processed every hour across multilingual, multi-category pipelines.

It was time to evolve from manual file management to intelligent, automated data infrastructure.

💡 The Challenge: Scaling Without Chaos

The client’s ingestion process was built around multiple mapping files — one for each vertical or market segment.
It worked well early on, but as new product lines were added, the file count — and maintenance burden — grew exponentially.

Each domain came with unique schema quirks, language fields, and taxonomies.
By the time I joined, the ingestion stack included over a dozen mapping files, with every new domain adding several more.

Symptoms of scale-related strain had begun to appear:

Data points surfacing in one reporting layer but missing in another
Cross-lens mismatches between themes, ingredients, and attributes
Inconsistent category mappings causing delayed refreshes and QA churn

We had two options: keep increasing manual effort — or re-architect for scale, reliability, and automation.
I chose the latter.

🚰 The Turning Point: Data Plumbing

The concept of data plumbing guided this redesign — ensuring that data flows predictably, verifiably, and efficiently from source to destination.

Just as plumbing ensures water reaches every faucet without leaks, data plumbing ensures every record moves through the system without corruption, duplication, or loss of context.

The new architecture needed to:

Adapt dynamically to schema changes
Validate data integrity before ingestion
Run large parallel loads within strict SLA windows
Maintain end-to-end lineage and traceability

This called for rebuilding the ingestion service around automation and intelligence.

🧠 Engineering the Solution

The new ingestion framework was designed around four engineering principles:

1. Dynamic Schema Resolution

Instead of hardcoded field definitions, the pipeline now reads schema metadata dynamically.
When a new domain or variant is introduced, it adjusts automatically — no code redeployment required.

If discrepancies appear (extra columns, renamed headers, missing data types), the system flags them and quarantines the affected rows without halting the job.

2. Automated Validation Layer

I implemented a pre-ingestion validation module to detect errors early.
Rules check for:

Naming inconsistencies across files and lenses
Missing taxonomy or translation references
Duplicate or null identifiers

For example, if a “trend” exists in one dataset but not another, the job automatically raises a structured exception.
This reduced recurring QA cycles and downstream reprocessing.

3. Parallel Ingestion & Orchestration

Using Airflow DAGs, ingestion jobs now run concurrently by region, category, or data type.
Each DAG executes ETL steps, records metrics, and triggers follow-up enrichment or aggregation tasks.

This parallelization, combined with optimized batching, increased throughput to over 500,000 rows per hour, cutting data-refresh turnaround time by more than half.

4. Centralized Version-Controlled Storage

All mapping and taxonomy files were migrated to cloud object storage (S3) with clear versioning and lineage metadata.
Every file reference is traceable to a refresh run, ensuring reproducibility and auditability — a single, trusted source of truth.

📊 The Results

⚡ ~60% reduction in refresh time through parallel processing
✅ Near-zero data-quality issues due to automated pre-checks
🧩 Schema-agnostic ingestion, easily extendable to new domains
🔄 Consistent taxonomies and category mappings across pipelines

The transformation was more than a technical win — it introduced a culture of proactive validation and data reliability by design.

🕸️ Beyond Plumbing: Data Mesh Architecture

Once the core pipelines stabilized, the next step was to extend them into a data-mesh-inspired model.

A data mesh treats data as a product — owned by domains, discoverable across teams, and governed centrally through standards.

In this setup:

Each data domain maintains its own ETL logic and validation rules.
The shared plumbing layer handles ingestion, orchestration, and lineage tracking.
Governance policies ensure consistency and interoperability.

This approach shifted the system from a monolithic data warehouse toward a federated, scalable architecture — allowing new verticals to onboard seamlessly without breaking existing flows.

If data plumbing is the city’s pipe network, data mesh is its zoning plan — decentralized but connected by common standards.

🧩 The Next Evolution: Agentic Data Refresh

The next logical step is agentic data refresh — pipelines that don’t just execute tasks but also reason about them.

In this vision, automation evolves into autonomy.
The system can:

Monitor data freshness and trigger refreshes dynamically
Diagnose errors and suggest fixes
Adjust to schema drift using metadata reasoning
Communicate insights like “Data for Category X is delayed due to missing translation file”

By integrating LLM-based reasoning agents into orchestration layers like Airflow and Jenkins, pipelines transition from reactive schedulers to self-healing, context-aware systems.

It’s where data engineering meets artificial intelligence — and where reliability meets foresight.

🧭 Lessons in Technical Leadership

Delivering this system as an external engineering partner was as much about architecture as it was about alignment.
It required close collaboration between backend developers, data engineers, QA, and DevOps — each contributing to a shared principle: automation starts with structure.

The experience reinforced a leadership lesson I carry forward:

“Strong engineering isn’t about fixing what’s broken — it’s about designing what won’t break tomorrow.”

When done right, data plumbing becomes invisible — and that’s the beauty of it.
Every dashboard, every metric, every machine-learning insight depends on those silent, dependable flows of data.

In the end, we didn’t just refactor ingestion scripts; we built the pipes that power every decision — and laid the foundation for a self-aware, resilient, and scalable data ecosystem.

#DataEngineering #Automation #DataMesh #Airflow #Jenkins #BackendDevelopment #EngineeringLeadership #AgenticAI #DataPipelines

Hacktoberfest 2023 Pledge

Pooja Sharma — Wed, 25 Oct 2023 07:16:36 +0000

Officially registered for #Hacktoberfest2023!

Looking forward to discover awesome repositories and contribute new features and fixes.

How I entered the Hacktoberfest Hall of Fame

Pooja Sharma — Wed, 25 Oct 2023 06:09:27 +0000

Intro

I am a self-taught developer. I learnt to code during my sojourn into UPSC Civil Services Preparation. In those long lonely nights waiting for my Prelims result (those who know know!), while scrounging through internet to find the most accurate Prelims key, I chanced upon GitHub.

Github is a repository of codes and a programmer's gold mine. That is when I fell for open source community. I made my first web application in 2020, and with good help from my friend and now husband, I launched my first online website.It gained 200 subscribers!

Highs and Lows

I found #Hacktoberfest mentioned in a LinkedIn post. The author was elated about a tree planted on his behalf. So I clicked on Like and immediately registered for Hacktoberfest.

My biggest challenge was the-how-to and where-to (start). Where were those repositories that were accepting contributions? How will I understand their project structure?

Once I got started, the next challenge was defending my contributions. Some Pull Request (PR) conversations went to and fro for days together. At this point, it was less about programming and more about articulating your ideas and aligning your vision of a website with that of the moderators.

Some requests were for changes in Pull Request (PR) headings. The commit -m "message" had to adhere to the repo contribution guidelines. Through these conversations I realized how these seemingly insignificant steps made PR/MR cycle smooth and efficient.

My biggest accomplishment, as a first time participant, was successfully completing the #Hacktoberfest with >4 merges. I had the most fruitful coding month ever. Links to accepted PRs:-

https://github.com/Techiral/A-Z-Python-Projects/pull/136 (Accepted)
https://github.com/TheAlgorithms/Python/pull/10562 (Accepted)
https://github.com/OtacilioN/awesome-hacktoberfest/pull/803 (Accepted)
https://github.com/OtacilioN/awesome-hacktoberfest/pull/804 (Accepted)
https://github.com/zero-to-mastery/file-io/pull/164 (Waiting)
https://github.com/ReciHub/FunnyAlgorithms/pull/1223 (Waiting)
https://github.com/Mrinank-Bhowmick/python-beginner-projects/pull/549 (Waiting)

Growth

I understood the power of Version Control System like Git through Git Workflows. There is so much one could automate with Git Actions for Continuous Testing and Integration of new features into a web app. I learnt that programming is as much about clean coding as it is about defending your choices and humbly accepting changes in your code if needed.

Open source community is more widespread and growing today than ever before. Look at what we have created with OpenAI! My love and appreciation for all things open source has grown leaps and bounds over the last month.

If interested in #opensource pair programming or want any help on how to start, please connect!