[{"content":"Ah still in the works\u0026hellip;\n","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/personal-blog/","section":"Musings about life","summary":"","title":"Musings about life"},{"content":"All opinions are my own.\n","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tech-blog/","section":"Tech Blog","summary":"","title":"Tech Blog"},{"content":"This list is not exhaustive. This does not include a lot of fiction that I love to read!\nComputer Science/Tech # System Design Interview - An Insider\u0026rsquo;s guide by Alex Xu Designing Data Intensive Applications by Martin Klepmann Spark : The Definitive Guide by Bill Chambers, Matei Zaharia Head First Design Patterns by Eric Freeman, Elisabeth Robson Productivity/Work ethic # Deep Work by Cal Newport So Good They Can\u0026rsquo;t Ignore you by Cal Newport Atomic Habits by James Clear Debugging Teams by Brian Fitzpatrick and Ben Collins-Sussman Other # Never Split the Difference by Chris Voss ","date":"6 February 2026","permalink":"https://usuallyunusual.github.io/usuallyunusual/book-shelf/","section":"","summary":"","title":"Book-shelf"},{"content":"Distributed Systems # J. Dean and S. Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters,” 2004 Leslie Lamport, \u0026ldquo;The Part-Time Parliament\u0026rdquo;, 1998 Leslie Lamport, \u0026ldquo;Paxos Made Simple\u0026rdquo;, 2001 Tushar D. Chandra, Robert Griesemer, and Joshua Redstone. \u0026ldquo;Paxos made live: an engineering perspective.\u0026rdquo;, 2007 Diego Ongaro and John Ousterhout, \u0026ldquo;In Search of An Understandable Consensus Algorithm (Extended Version)\u0026rdquo;, 2014 Computer Science # David Goldberg, \u0026ldquo;What Every Computer Scientist Should Know About Floating-Point Arithmetic \u0026ldquo;, 1991 ","date":"6 February 2026","permalink":"https://usuallyunusual.github.io/usuallyunusual/paper-shelf/","section":"","summary":"","title":"Paper-shelf"},{"content":"Career Trajectory: # Software Engineer 2 @ Hy-Vee (Aug 2025 - Now) Architected the end-to-end AI platform at Hy-Vee — spanning indexing workflows, reporting, observability, MCP server architecture, an Orchestrator agent, and prompt management — integrated on top of the existing data platform. Designed and built the MCP server with 18+ tools, OAuth 2.0, RBAC, and decoupled prompt management with versioning; adopted by 100+ internal users across Claude, Cursor, VS Code, and a custom app. Optimized a core MCP service achieving a 60% reduction in P99 latency, 50% increase in throughput, and 50% reduction in resource utilization. Built the full CI/CD pipeline for all AI platform components on Concourse. Provisioned and managed all platform infrastructure as code using Terraform. Designed the observability and monitoring stack — including custom token-usage metrics pushed to GCP, distributed tracing across service tiers, and historical trace ingestion into BigQuery for high-cardinality and long-term analysis. The AI platform is driving data democratization by unlocking value from the existing data warehouse for non-technical stakeholders across the organization. Software Engineer 2 @ Oracle (Mar 2024 - Aug 2025) Designed and developed a complex compaction-process which was a critical part of an overall effort to decrease the data-refresh times from 72 hours to less than 7 hours across the platform. Discovered and reported a concurrency bug in Oracle Cloud Big Data Service by performance-testing loading Avro files into Iceberg lake-house on Object Storage, using Spark. Decreased time taken to provision infrastructure from days to a few minutes by using Terraform to deploy on Oracle Cloud. Develop and maintain Java services and big data pipelines for petabyte-scale processing on AWS and Oracle Cloud, handling millions of weekly requests. Contribute to the technical roadmap, streamline processes for operations and support engineers, and organize recurring code deep dives to improve team understanding of the codebase. Software Engineer 1 @ Oracle (October 2023 - Feb 2024) Successfully retained a high-profile client by delivering a critical feature that was acknowledged at the Oracle Analytics All-Hands meeting. Unblocked the onboarding of clients onto the data platform by consolidating business logic to deal with stream and batch processing in our workflows. Integrated Oracle Cloud Application-Performance-Monitoring Java agent into Docker images making it generally available to use across the platform by enabling a feature flag. Reduced the effort required to generate operations review docs by atleast 30% by massively simplifying processes and setting up dashboards in NewRelic. Established comprehensive documentation covering architecture, codebases, tech stack, CI/CD, SecOps, and access guides for products, which is now used as a guide for onboarding new hires. Software Engineer 2 @ Cerner (May 2022 - September 2023) Designed the decoupling and removal of a deprecated library from our codebase and guided the team on the plan thereby reducing unused code by at least 20% and reducing tech debt. Reduced lead times by 50% for clients requiring low-latency processing with Kafka and Storm by upgrading and consolidating runtime versions in production. Upgraded search indexes from Solr5 to Solr8 and developed an extensible regression testing tool to identify subtle differences in payloads. Developed an extensible regression testing tool for our organization that helped find subtle differences in payload from our busiest service during the upgrade from solr5 to solr8 and helped avoid issues in production. Migrated on-premises MapReduce jobs managed by Oozie to AWS EMR, reducing latency with an event-driven AWS SQS setup, and provisioned infrastructure using AWS CDK. Unblocked the AWS migration project by figuring out how to run custom and canary workflows and also fix our deployment pipelines to deploy to S3 instead of on-prem HDFS by modifying libraries for which no maintainers were available. Software Engineer 1 @ Cerner (June 2021 - April 2022) Created a bash script to automate AWS EMR job startup, reducing time by 35% using AWS CLI. Automated detection of missing annotations in Avro schemas with a recursive Java solution, integrated as a build-time test. Worked on a critical project around sensitive data filtering requirements. Investigated and resolved a production cluster capacity issue, increasing available capacity by 10% and identifying workflows needing additional hardware. Software Engineering Intern @ Cerner (Nov 2020 - May 2021) Unblocked the deployment of a service containing critical client features surrounding sensitive data by resolving close to 60 CVE’s. Skills: #Programming Languages : Java, Python, SQL, Terraform, Bash, Scala\nBuilt complex big-data processing pipelines and backend services in Java and Python. Basically can learn any language if you\u0026rsquo;re willing to give me 2 weeks.\nDatabases/Processing Engines : Spark, Storm, Kafka, Crunch, Hadoop MapReduce, HDFS, HBase\nServices/Platforms : Kubernetes, Oracle Cloud (BDS, Object Storage, IAM, Dataflow, ATP, APM), AWS (IAM, S3, EMR, EC2, Lambda, CDK, RDS), GCP (IAM, BigQuery, CloudRun, Monitoring, Dataform, AgentEngine, VertexAI, AppEngine), Oozie\nDevOps : Jenkins, Concourse, CI/CD, Docker, Git, Splunk, Grafana, NewRelic.\nEducation: # Master of Science, Computer Science, Christ (Deemed to be) University Bengaluru, IN (May 2021) Short term course on Artificial Intelligence, Indian Institute of Science Bengaluru, IN (August 2020) Hobbies: #Playing Tabla and Guitar, Running, Hiking, Reading, Motorcycling, Cooking\n","date":"6 February 2026","permalink":"https://usuallyunusual.github.io/usuallyunusual/about/","section":"","summary":"","title":"About me"},{"content":"Problem Solver\n","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/","section":"","summary":"","title":""},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tags/leadership/","section":"Tags","summary":"","title":"Leadership"},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tags/productivity/","section":"Tags","summary":"","title":"Productivity"},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tags/softwareengineering/","section":"Tags","summary":"","title":"Softwareengineering"},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"Most engineers join a new team with a clear picture of what good looks like. Six months later, that picture is gone, replaced by deployment rotations, massaging egos, random meetings and a tech debt ticket that\u0026rsquo;s been \u0026ldquo;prioritized next quarter\u0026rdquo; for three quarters running. The ambition didn\u0026rsquo;t disappear. The focus did. I’ve found this pattern strangely familiar and common in my experience. I used to call it burnout. Eventually I thought maybe the team was not picking enough slack, but now I think it’s a lack of direction, figuring out what to work on, figuring out what needle you’re trying to move.\nThere is something to be said about the team not picking up enough slack which leads me to the next section.\nDrop the ball #I think it’s critical to “drop the ball” when necessary. Compensating for a team\u0026rsquo;s lack of work ethic or skill is not a great idea, and you’d be surprised how hard I’ve tried to convince myself that I wasn’t doing it.\nIf the team is not picking up slack, that may not be your problem. It is our responsibility to give feedback to peers and your manager and..that’s it. Unless you’re in a management position or hold considerable influence over the team, this is pretty much all you can do.\nDeployments don’t happen unless you start the conversation? Drop it. Code issues don’t get flagged by the team unless you review it? Let it through. Team missed an important deadline? Let it.\nWhen you drop the ball, whoever is responsible for the miss gets a strong signal which otherwise would have been lost. It is very important that this signal not be lost. It brings up the real issues in the team which would otherwise go unnoticed. Usually leads to burnout, lots of low-priority high-urgency tasks which should’ve been planned better. This might seem like I’m asking you not to care about the product, some folks may even gaslight you into thinking you don’t. Don’t listen to them. Covering for non-ideal behaviour in a team enables the product to hobble on, never really going anywhere.\nYou see the gaps in the team, you see who’s performing well and who’s not. The team should ideally sort itself out given enough time. And if it does not, then you get a strong signal about the team and can make your next decision based on that. Drop the ball, let the signal take its course and see where it leads.\nLet\u0026rsquo;s talk about the product.\nThe product wins, always #At the end of the day you’re trying to get the product to succeed. In my experience, most engineers get caught in this trap of looking at code or the system as the end product itself rather than solving end user concerns. This misconception costs a lot.\nEngineers usually think of every problem as code, which is not half wrong but it does eventually lead us comfortably into limbo. Let me explain.\nWe start by being handed a problem to solve, a product. We solve it and eventually the code becomes large enough we are no longer able to fit both the codebase and the problem it’s trying to solve in our mental model.The code begins to whisper to you about your CI pipeline not being the most efficient, the tests not running fast enough, some initial proof of concept being used as production code.\nThis is the point where it feels like getting buy-in to push this through is a monumental task.\nBut we’re missing a piece of the puzzle. We do not have the full picture of the problem yet. The other piece of the puzzle might be leadership forcing the team to push out a feature, your manager trying to prove the team\u0026rsquo;s worth by prioritizing some other piece of work, or just the fact that you have only 2 engineers working on the product. We’re seeing the problem through a telescope, all nicely zoomed in on the piece you’re trying to solve. The problem is actually much more constrained, which is what brings real complexity (People are way more complex than code). In an ideal world with enough capacity, time, money or whatever hidden impediment you don’t know about, solving for code is pretty straightforward (Especially with the AI coding agents) but our weakness lies in not understanding the full constraints of the problem.\nDon’t get me wrong, all the problems mentioned above are definitely worth investing resources into, but it becomes a question of investing now, or waiting for later, based on whatever else is pushing the fate of the product.\nYou could cause a lot of frustration by pushing too hard for the work to be prioritized and end up leaving a bad impression. Solving this feels like a dance in communication and tact. We need to let the product win, and therefore ourselves.\nIn some big enterprises, the problems we are solving look extremely different to the problems we solve in an early-stage product going from zero to one. The problems (and their solutions) cannot be generalized across. My experience with an early-stage product was rough for a couple of months because I was looking at it through the experience of an engineer who worked in a big enterprise with a very mature tech-ecosystem. I was worried about the wrong things, and it feels extremely counterintuitive.\nIn an early-stage product it\u0026rsquo;s more important to deliver features quickly than to get the code right (AI slop seems to be making this true for every org, ugh). This feels wrong, but it has to be done if required. It’s a balancing act.\nIntroduce a cache layer and reduce latency by some ms vs push out a new feature some VP was asking for. Ideally both. But we all know we don’t live in that utopia. Would reducing latency benefit the users enough to convince leadership it’s worth the extra cost? Or is it better you deliver a new feature that lets the product prove itself? These are all questions worth asking.\nCompare this to a mature product already deriving value from their spends, reducing latency would be a huge win given some extra $$$, since at their scale the economy plays in their favor. They aren’t scaling per user like an early-stage product, they’re scaling per thousand users or per millions of users. Deleting code to reduce maintenance might be extremely useful on a product that has hundreds of engineers working on it. They might just be able to squeeze out more work because you just freed up some of their mental capacity. The amount of money you have to get from zero to one is drastically different from, let\u0026rsquo;s say, an established product already earning enough money to support your technical endeavours.\nDifferent problem, different needle. The product still wins, always.\nFinding your work #The real question is never \u0026ldquo;what should I work on?\u0026rdquo; It\u0026rsquo;s \u0026ldquo;am I still aligned with the product?\u0026rdquo;\nWhen you are, the decisions mostly make themselves. Work that moves the product forward is your work.\nWhen you can\u0026rsquo;t quantify the value of a piece of work at all, that\u0026rsquo;s a signal. It doesn\u0026rsquo;t mean the work has no value, it means you haven\u0026rsquo;t understood it well enough yet. Dev hours saved, cognitive load freed up, a future incident that doesn\u0026rsquo;t happen are all good value metrics. If you still can\u0026rsquo;t find a proxy, be honest about whether the product actually needs it.\nIf work seems repetitive and already has a reference for it, there’s no value in doing it unless the speed of delivery is the value. You should document your way out of the work. Delegate. Document everything anyway, not as good practice but as a way of ensuring you\u0026rsquo;re never “impossible” to replace for the wrong reasons. The engineer who is critical to the product because they own the hard problems is very different from the engineer who is critical because nobody else knows how to run the deployment script.\nSpending time on these tasks pulls you off the vector you should be on.\nNo one to delegate to? Do it if it’s temporary, hire for it eventually or automate it, but if it looks permanent then that’s not an edge case, it’s the job. You have to think about whether that’s the job you want. Dry work like dashboarding and maintenance is a good signal too. It could mean your product is stabilizing enough to think hard about which direction to move in, in which case there’s a possibility of pushing the product to be better through harder problems.\nIf it feels like that is the end goal, it might imply the product isn’t really moving forward or has other issues that are stopping it from growing. This is also an opportunity to figure out if that’s a problem for you to solve, whether you’re still in alignment with the product.\nI spent years brute forcing whatever was handed to me while simultaneously trying to find the work I actually wanted to do. The cost was time. Time I could\u0026rsquo;ve spent arguing for the hard problems, time I could\u0026rsquo;ve spent moving metrics that actually mattered. The framework I\u0026rsquo;ve described here would\u0026rsquo;ve saved me a lot of that. Not because it\u0026rsquo;s complicated, but because it reduces every decision to one check: are you and the product still moving in the same direction?\nIf yes, find the most valuable thing you can do for it right now and do that.\nIf no, that\u0026rsquo;s the most important thing you\u0026rsquo;ve learned about your current situation.\n","date":"16 June 2026","permalink":"https://usuallyunusual.github.io/usuallyunusual/tech-blog/what_needle_are_you_trying_to_move/","section":"Tech Blog","summary":"The gap between good engineers and great ones isn\u0026rsquo;t technical skill. It\u0026rsquo;s knowing which needle to move and when.","title":"What needle are you trying to move?"},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/tags/work-life-balance/","section":"Tags","summary":"","title":"Work-Life-Balance"},{"content":"","date":null,"permalink":"https://usuallyunusual.github.io/usuallyunusual/categories/","section":"Categories","summary":"","title":"Categories"}]