DEV Community: Lavkesh Dwivedi

What a meeting‑free week taught me about leading

Lavkesh Dwivedi — Thu, 18 Jun 2026 13:19:58 +0000

Originally published on lavkesh.com

When I cleared my calendar for a full week, the silence in the conference room felt like a sudden vacuum that made me wonder how the team would keep moving without my constant presence.

The first day was uneasy; a handful of Slack pings arrived asking whether I had missed something, but by the second morning the messages thinned and colleagues began posting solutions in the channel instead of waiting for my nod.

What surprised me most was that, without the cadence of stand‑ups and status calls, I could actually see where work stalled - a missing data feed here, an unclear handoff there - details that had been drowned out by endless chatter for months.

I realized many of our meetings were less about deciding the next step and more about reassuring each other that we were all on the same page, a ritual that ate up time without adding value.

That observation pushed me to think of our meeting habit as a habit that could be trimmed, replacing some of the synchronous check‑ins with written updates that let people move forward on their own schedule.

Staying in the loop required me to skim daily summaries and a few concise reports, and I found that the written record was actually clearer than the fragmented notes that usually emerge from a 30‑minute call.

Without a packed agenda I took the chance to walk the floor, ask a developer what they were wrestling with, and chat with a designer over coffee; those spontaneous moments built rapport that a scheduled meeting never could.

When I slipped back into my normal calendar I trimmed a handful of recurring calls, encouraged the team to post status updates in the channel, and only scheduled a meeting when a decision truly needed collective input; three weeks later the board showed fewer blockers and the engineers reported feeling more trusted.

Now I leave the conference room door open and let the team own the work, stepping in only when the signal is clear.

No New Books

Lavkesh Dwivedi — Thu, 18 Jun 2026 11:28:23 +0000

Originally published on lavkesh.com

I decided to stop buying new books for twelve months, and it's been a fascinating experiment, my shelves were already full and I wanted to see if I could find new value in the books I already owned

The first few months were tough, I had to resist the temptation of buying the latest releases from my favourite authors, but as time went on, I started to appreciate the books I already had and I began to read them in a different way, I found myself re-reading old favourites and discovering new insights

I started to lend books to friends and family, which led to some great discussions and debates, my reading habits changed and I started to focus more on the quality of what I was reading, rather than the quantity, I was no longer just collecting books, I was reading them

My relationship with books changed, I no longer saw them as something to be collected, but rather as a source of knowledge and inspiration, I started to think more critically about what I was reading, and I began to appreciate the authors and their craft, I was more patient and willing to spend more time on a single book

I was savouring the experience of reading, rather than rushing to finish a book so that I could start a new one, this change in approach has had a profound impact on my personal growth, I am now more reflective and thoughtful in my approach to learning, I am not sure if I will start buying new books again, but I do know that my approach to reading has changed forever

The experience has also made me think about other areas of my life where I might be collecting things unnecessarily, am I holding onto clothes that I no longer wear, or keeping gifts that I do not really need, the exercise of stopping buying new books has taught me the value of living with what I already have

I have come to realize that personal growth is not just about acquiring new knowledge, but also about appreciating what we already have, it's about finding new value in the things that surround us, and being more mindful of our consumption habits, I am excited to see how this new approach will impact other areas of my life

The decision to stop buying new books has been a catalyst for change, and it has taught me the value of living with intention, it has shown me that personal growth is not just about what we acquire, but also about how we appreciate what we already have, I am eager to see where this journey will take me

I am starting to appreciate my belongings in a new way, and I am finding new ways to simplify my living space, the journey is just beginning, and I am excited to see what the future holds, I have learned that sometimes the best way to move forward is to stop, and to appreciate what we already have

Cache Stale Data Issues

Lavkesh Dwivedi — Thu, 18 Jun 2026 09:37:38 +0000

Originally published on lavkesh.com

I recall one of the first design decisions for our payments platform, which was to deploy an in-memory cache for low-latency access to customer account balances. The architecture diagrams looked clean, with Go services using sync.Once-initialized maps in memory, bypassing the database for sub-millisecond reads. However, this approach worked as expected for only three months, until users started reporting inconsistent charges on receipts.

The problem surfaced at peak hours when concurrent updates to the same balance would overwrite each other. For instance, the account balance for user ID 12345 went from $1,200 to $850 to $1,200 again within seconds, leaving the cache in a state that defied the database of record. Engineers stared at the logs, baffled by the mismatch between transactions and cached values, because the team had not accounted for the fact that memory maps are not thread-safe by default in Go.

Debugging revealed the fundamental error: we were optimizing for speed without considering write-through guarantees. The cache treated concurrent requests as idempotent, which they were not. During a single user’s purchase flow, multiple goroutines could validate the balance, each reading a stale value from memory before any had a chance to commit updates. We had to shift to Redis with explicit lock keys and time-to-live settings, adding 4 milliseconds of latency but ensuring atomicity.

The cache also invalidated itself only when a change occurred, not when an upstream source updated. We discovered this when the accounting team reconciled overnight and adjusted balances based on fee settlements - the cache never reflected these updates until it expired naturally. To fix this, we had to implement message queues to broadcast invalidation events across all services. What started as a performance optimization became three nights’ worth of rewriting concurrency models.

This experience taught me two concrete lessons about distributed systems: first, that latency and consistency are a trade-off, not a checkbox; second, that in-memory solutions scale poorly in production when data flows through multiple planes. The original diagrams omitted the reality of cross-service communication, assuming all updates would flow through a single request path. They didn’t, and this oversight led to significant issues.

We eventually replaced the local cache with a Redis cluster and added circuit breakers to handle Redis failures gracefully. The change dropped read throughput by 30% but eliminated 90% of our support tickets related to balance discrepancies. Engineers now run load tests simulating out-of-order updates, which they didn’t before the incident, to ensure the system can handle such scenarios.

The real mistake wasn’t using in-memory storage but treating it as a production-ready solution without stress-testing its edge cases. The team had seen this pattern work in POCs but didn’t account for the messy concurrency of real user behavior. That six-hour debug session in the server room, where we traced race conditions line by line, remains the most expensive but valuable lesson in distributed design I’ve learned.

I keep a screenshot of the problematic cache code on my wall as a reminder: theoretical elegance is worthless if it breaks under real-world load. Production systems demand we question every assumption, even the ones that worked in benchmarks. This experience has stuck with me, and I often think about it when designing new systems.

The next morning after the fix, the team sat in the conference room with stale chai, Go code open on every screen, and a shared understanding that the most obvious optimizations often hide the hardest problems. My mother still asks why we can’t just 'make things fast like the old days.' I tell her that making things fast without making them correct is like boiling a pot on the stove and forgetting to check if the rice is cooked.

I recall that moment in the conference room, with the team reflecting on what we had learned. The experience was a hard lesson in the importance of considering all aspects of a system, not just the theoretical benefits of a particular approach. It’s a lesson that has stayed with me, and one that I try to apply to all my work.

Finding Quiet in Dallas Library Reading Rooms

Lavkesh Dwivedi — Thu, 18 Jun 2026 07:51:46 +0000

Originally published on lavkesh.com

The first time I walked into a public library in the Dallas‑Fort Worth area a few years after arriving, the sheer size of the collection was impressive, but the palpable silence caught me off guard and made me realize how much I had been missing a space where thought could settle without interruption.

Back in Orai, the quiet was the background hum of street vendors, neighbors chatting, and temple bells, a communal noise that felt like home, yet the library offered a silence that was deliberately cultivated, a stillness that felt almost foreign to my upbringing.

I began to treat the reading room as a regular stop, not just for books but for sitting, for letting ideas percolate, and I soon saw that the silence was shared by a diverse crowd, each person alone in their mind but together in the same hushed atmosphere.

The room smelled of aged paper, the lamps cast a soft amber glow, and the occasional rustle of a page turned became a rhythm that reminded me how such environments shape our thoughts, feelings, and sense of self.

Even as a child I found pockets of quiet in the mandir, the mosque, the park, places where people gathered to sit and reflect; those early experiences echo in the modern reading rooms I now seek out.

In a city that moves at a breakneck pace, the Dallas reading rooms serve as more than just places to read - they are small anchors where one can pause, reflect, and reconnect with a deeper focus.

Sitting there today, surrounded by the quiet hum of fellow readers, I am reminded that even a sprawling, noisy metropolis hides corners of calm, and that we can carve out similar moments for ourselves if we choose to slow down.

As a software engineer, I find that stepping away to a quiet room lets me untangle complex code, recharge my mental bandwidth, and return to a project with clearer intent and fewer distractions.

When I close the book and push open the library door, the soft click and the librarian's nod signal the end of a brief retreat, leaving me with the lingering sense that these quiet spaces are as essential to my work as any line of code.

A 1990s DICOM Server Still Haunts Our Integration

Lavkesh Dwivedi — Thu, 18 Jun 2026 05:27:02 +0000

Originally published on lavkesh.com

We were hired to bolt our new healthcare platform onto the hospital’s PACS, confident the client’s promise of a modern, standards‑compliant DICOM server would make the job painless.

The first sign that confidence was misplaced showed up in the middle of the night when an MRI scan uploaded at 3 a.m. simply disappeared by sunrise, and a CT series arrived looking like a mosaic of broken pixels; our own logs stayed clean while the PACS logs were a jumble of ASCII art and hex strings.

A quick walk to the server room revealed a beige box humming in time with the building’s ancient HVAC, a sticker proclaiming ‘RIS/PACS v3.2’ - a pre‑XML relic - and an on‑site admin who shrugged, ‘It works, no?’ while a second monitor streamed YouTube videos on loop.

Digging deeper uncovered a proprietary database older than SQL that kept image metadata in hand‑crafted flat files named after Unix timestamps; a folder called 20190527 surprisingly held scans from 2023, a clear sign someone had rewritten timestamps during a hardware swap.

Replacing the whole stack was estimated at six figures and a year of downtime, a price the hospital could not swallow, so we cobbled a middleware proxy that emulated the server’s quirks, translated modern DICOM queries into its broken dialect and patched corrupted headers; the proxy now shuttles roughly 12 000 images a day.

The technical hack was only half the battle; the original development team had vanished years earlier - the lead architect retired in 2012 - and the only remaining documentation were paper index cards cataloguing patient IDs and scan times, forcing us into a kind of forensic reverse‑engineering.

Seeing those cards reminded me that calling a 1996 system ‘just old code’ misses the point; it is a time capsule of shortcuts and duct‑tape fixes, and each day it stays online it costs the hospital more than a fresh build would, yet the perceived risk of replacement outweighs the obvious expense.

The proxy holds for now, though its logs peppered with occasional latency spikes and the server’s fan now sounds like a dying breath, leaving me to wonder whether the next engineer will stumble on the same index cards or simply accept the chaos as normal.