← Archive · viveksharma.blog
‹Sunday, November 1, 2026›

Root & Branch

Notes from the Bottom of the Stack · by Vivek Sharma, Engineer

Topics:

Top Story
By Vivek Sharma·TECHⓘ 5 min

Azure Policy and Why It Matters

Azure Policy is a governance service that lets you define rules for what is and is not allowed in your Azure environment, and then enforces them automatically across every subscription and resource group. Instead of trusting each engineer to remember the standards, you encode the standards once and let the platform apply them everywhere.

A policy is a simple statement of intent — "only allow resources in the West Europe and Central India regions," "require a cost-center tag on every resource," or "deny any storage account that is not encrypted." You group related policies into initiatives and assign them at a scope: a management group, a subscription, or a resource group. Everything beneath that scope inherits the rules.

The real power is in the effects. A policy can 'deny' a non-compliant deployment before it ever happens, 'audit' existing resources so you get a compliance report without breaking anything, or 'deployIfNotExists' to automatically remediate — for example, switching on diagnostic logging the moment a resource is created. This turns compliance from a quarterly audit scramble into something that holds continuously.

The significance is straightforward: at scale, manual governance does not work. Azure Policy gives you consistency (the same rules everywhere), security (risky configurations are blocked at the door), cost control (no oversized or untagged resources sneaking in), and audit-readiness (a live compliance dashboard instead of a spreadsheet). It shifts governance left — from cleanup after the fact to guardrails that make the right thing the default.

If you run more than a handful of resources, start small: pick two or three rules that have burned you before — required tags, allowed regions, mandatory encryption — set them to 'audit' first to see the blast radius, then promote them to 'deny' once you trust them.


Derivative of sin x from First Principles: Why It's cos x

Every calculus student learns that the derivative of sin x is cos x, and most of us just memorise it. In this post we'll build it ourselves, starting from only the definition of a derivative and one formula from school trigonometry, and see exactly where the cos x comes from. No derivative rules allowed.

Complex Numbers: Start with the Basics

Understand i, calculate with a + bi, and see numbers as points on a plane. A beginner-friendly lesson with step-by-step examples and 10 objective questions with explained answers.

Complex Series and Trigonometric Functions

Extend convergence, power series, sine, and cosine to complex inputs, one step at a time. A beginner-friendly lesson with step-by-step examples and 8 objective questions with explained answers.

Euler’s Formula: Rotations, Powers, and Roots

Connect exponentials to trigonometry and use complex numbers in applied mathematics. A beginner-friendly lesson with step-by-step examples and 10 objective questions with explained answers.

Infinite Series: Adding Without an End

Can infinitely many small pieces add up to a finite total? Learn to read summation notation, build partial sums, and decide whether a series converges, with worked examples and four practice questions.

Power Series: Building Functions from Powers

Build functions from powers of a variable. Learn about coefficients, centres, convergence intervals, and polynomial approximations, with worked examples and four practice questions.

10 Backend Design Patterns Explained Through One Payment System

Most backend code starts simple: a route, a query, a response. The trouble comes later, when ten people edit the same files, a second payment provider shows up, and a partner's API goes down on a Friday night. Design patterns are named, well-tested answers to problems like these. They are not rules to memorise. Each one exists because a particular kind of code kept hurting people, so the useful way to learn them is problem first: what goes wrong without the pattern, what the pattern changes, and when it is not worth the extra code.

Where Engineers Still Beat AI Agents, and How to Stay There

In 2026 it is normal for an AI agent to finish in an afternoon what used to take an engineer a month: a migration, a test suite, a working prototype. The trend is steep. METR, a research group that measures this, found that the length of software tasks frontier agents can complete on their own (measured by how long they take a human professional) doubled roughly every seven months from 2019 to 2025. Its January 2026 update puts the doubling time since 2023 closer to four months. So the useful question is not whether AI is fast. It is what is left for people, and how to stay good at it.

Medicare Parts A, B, C and D, Explained Simply

Medicare is the US federal health insurance program for people aged 65 and over. It also covers some younger people: those who have received Social Security disability benefits for 24 months, and people with ALS or end-stage kidney disease. It is not the same as Medicaid, which is run by the states and based on income. Medicare is split into four parts with letters, and the letters cause most of the confusion. The simplest way to hold it in your head: Parts A and B are the core coverage, Part D adds prescription drugs, and Part C is a different way of getting A, B and usually D from a private insurer.

Why Medicaid Coverage Is So Hard to Verify

For most commercial insurance, checking a patient's coverage is a once-a-year chore: the plan renews in January and rarely changes in between. Medicaid does not work that way. More than 70 million people in the US rely on it, and for adults their coverage can change in any month. A patient who was covered at their last visit may have a different plan, a new member ID, or no coverage at all by the next one. For clinics, that turns a routine front-desk check into one of the most error-prone steps in getting paid.

Little's Law: The One Equation Every Engineer Should Know

Little's Law is a result from queueing theory, a branch of applied mathematics, and it fits in one line: L = λ × W. The average number of items in a system (L) equals the average rate at which they arrive (λ) multiplied by the average time each one spends inside (W). The system can be a checkout line, a thread pool, a message queue or a whole microservice. The law does not care.