DEV Community: Aditya Agarwal

Devs are inspecting Greenhouse payloads to find hidden salary caps

Aditya Agarwal — Mon, 21 Sep 2026 10:12:04 +0000

Next time a job portal asks for your "desired salary," just open your DevTools and you might find the answer sitting right in the payload. Recently, developers have been peeping into application forms. The JSON they hide says far more than the recruiter ever will. 🕵️

The field that pretends to ask

Here's how it goes. You complete an application on a platform such as Greenhouse. There is a box that says: "What are your salary expectations?" It seems non-threatening. It seems like a direct question. No, it's not. Pop open the network tab, watch the request fire, and sometimes you'll spot a number the form never showed you. An upper limit. A maximum threshold. The actual budget hidden in the reply.

Guess high, disappear

In certain systems, candidates are automatically filtered out if they mention a number above the predefined budget threshold. You enter a number, which is then compared to an invisible limit.

If your price is too high, you will simply disappear. No return call, no explanation that they chose someone else, just radio silence.

The question was never asked with good intentions. It was a snare disguised as interest.

Consider the implications of that. They have all the information. You're the only one who has to guess.

Leaky frontends are doing the work laws couldn't

This is what I actually find funny. We spent years discussing pay transparency, but what made a difference was poorly written client-side code.

The number was meant to be kept on the server. But instead, someone sent it to the browser.

→ The "desired salary" box is a filter, not a conversation.
→ The budget often exists before you apply.
→ The frontend sometimes hands you the answer for free.

Companies patching these leaks are telling on themselves. If the industry were a fair playing field, there would be no secrets to keep.

These leaks expose the bias, so of course they rush to fix them.

What this changes for you

I'm not going to pretend inspecting payloads makes you a hacker. It's the network tab that you get with every browser. But knowing the game changes how you play it. If a portal is silently comparing numbers to a wall, you want to know where the wall is. Not every form leaks. Some companies handle it elegantly, server-side, so you don't notice anything. But the question is weaponized. Now you know why it feels off. The box that asks about your value may have a good idea of what it's willing to give you. Have you ever exposed the DevTools on a form and found something you shouldn't have? Share the payload inside.

Svelte's runes are just React hooks wearing a Svelte hoodie

Aditya Agarwal — Sat, 19 Sep 2026 19:16:08 +0000

Svelte convinced me with a promise. You write let count = 0, then modify that, and the UI updates magically. No need for hooks. No dependency arrays. No complex setup. That was the main idea behind it. After that, Svelte 5 introduced runes. And the magic left without us noticing. 🎒

What actually changed

The release of Svelte 5 was announced on September 20, 2023, and was finally stabilized in late 2024. This version introduced a concept called runes: $state, $derived, and $effect. Here's the thing nobody wants to say out loud. $state() is Svelte's useState(). $derived() is useMemo(). $effect() is useEffect(). The framework constructed to avoid React hooks essentially redeveloped them. Same jobs, different hoodie. ## The old way was the whole point

Implicit reactivity was a killer feature of Svelte 3 and 4. You just wrote $: doubled = count * 2 and the compiler did the magic. Svelte 5 uses let doubled = $derived(count * 2) instead. Do you see the difference? Reactivity was once imperceptible. Now you define it explicitly. Well, that 's not a small tweak to have to make. That's the entire original promise of the approach being jettisoned. With some justification, people will feel a bit misled over Rich Harris's original claim that just a plain let count = 0 was enough to make the UI self-updating. The original pitch was that you didn't have to think about reactivity. The new pitch is here's a function to make things reactive. Ring a bell? ## The official reasoning

In all fairness, this was not something the team pulled out of thin air. In the Svelte 5 intro video, Rich Harris mentioned that runes "use function syntax to achieve the same things and more". He described the change as something needed to address scaling issues that are becoming "hairy". And they are. The previous $: magic that we had was not scalable to larger apps, hard to understand its behavior outside of .svelte files and thus hard to trust. Universal Reactivity was introduced in Svelte 5, so that $state and $derived can also be used in plain .js or .ts files. Similar to React's sharing stateful logic with custom hooks and Vue's solving with the Composition API, everyone converges to the same answer. ## So was it worth it? Based on the data available, we would say yes, to some extent. According to Strapi, when they migrated a 147-component app using their solution, the bundle size decreased from 382 KB to 171 KB. A 55% reduction. Smaller bundles, better scaling, code you can share across files. Better scaling ensures your app can grow without performance issues. And being able to share code across files improves code organization and maintenance. These are all real advantages. Svelte was the one framework that felt different. A Medium critique summarized it. The writer stated that Svelte is "having an identity crisis," that "Runes will be the de-facto standard and soon enough $: and export let syntax will be cycled out," and ended with the gut-punch: "Svelte was one of its kind."

Svelte used to stand out from the crowd, and now it's becoming more like the pack it made fun of. ## The uncomfortable takeaway

Perhaps being very clear about reactivity is the best approach after all. It's possible that any framework will recognize that using magic has limitations and eventually, you need to explicitly define how things work. If that's the case, fair enough. But we should also then stop pretending like Svelte was this groundbreaking departure from hooks. It was a prettier structure to convey the identical concept, and a compiler performed additional tasks. The runes revealed the truth of that. Here's something to think about:

→ Runes solved genuine scaling pain, and the bundle numbers back it up. → But they traded away the exact thing that made Svelte feel special. → Every major framework landed on explicit, function-based reactivity anyway. → "Convergence" and "identity crisis" might just be two words for the same event. I'll most likely continue using Svelte 5. The advantages are significant and I am open-minded enough to appreciate a 55% bundle size reduction. 🤷♂️

But we seem to have lost something along the way. Something about being shielded from having to think about "reactivity" in our components, I guess? Three new functions? So, my question to you is: was the implicit reactivity a great concept that just wasn't practical in real applications, or did Svelte abandon it too soon?

HTMX is fine until the third stakeholder wants a modal

Aditya Agarwal — Thu, 17 Sep 2026 19:13:18 +0000

HTMX was successfully implemented in a production environment earlier this year. Then, out of the blue, the third stakeholder expressed their desire for a modal. They tend to break your lovely little world of HTMX snappy actions that got a free pony, a grenade, and a lollipop.

That's usually when the fantasy cracks. 🫠

The pitch is real, and it works

HTMX made a surprising return that no one in the SPA community had expected. Fast forward to 2026, and it is being used to run real production dashboards, as opposed to just small demos.

And to be honest? It works really well for dashboards.

HTML is sent over the network. The server does the rendering, the fragment is replaced, and you can leave work before schedule.

There's no need for hydration. There's no need for a client-side state to get out of sync with the server. There's no need for 200KB of JavaScript to render a table of numbers.

This is the right tool for read-heavy screens with the occasional filter. I would not hesitate to use it.

Then reality shows up in a suit

It's not HTMX that's the problem. It's what comes next once the prototype is successful.

Stakeholder one is really happy with the dashboard. Stakeholder three has requested a modal that can edit a row without having to leave the page.

Sure. Enter hx-get into a conversation, replace it, close it if successful. Also clean.

So, stakeholder one needs to be able to save wherever they are when they navigate away, stakeholder two wants one specific row of their entire overview to be constantly updating, and stakeholder three wants a counter on their "new" draft, as well as the entire row behind it, to be updating while also not losing the draft when they navigate away.

You are now managing state in three different locations via HTTP. Congratulations on reaching the cliff!

This is the moment when those who claim "scales to anything" stop arguing.

None of this is hard to do. It's just not easy anymore.

"PHP spaghetti" is a lazy insult that's half right

Critics often refer to HTMX as a regression back to PHP spaghetti.

When your interactivity grows, your logic spreads across components, endpoint handlers, and a bunch of hx- attributes.

Your UI is not stored in one location for you to read. It is indicated by which fragment was last replaced.

That's the actual cost. Not the tech, the legibility.

A React component is messy but the state at least exists in a place you can reference and discuss.

Highly responsive HTMX applications frequently involve lots of state changes on the server and a lot of template updates across multiple browser windows post-POST. It's an illusion that what you have locally is the "current" UI.

The honest version of the pitch

We have implemented it before, and we would do it again if it's a suitable choice for a specific interface.

What really bothers me is the lack of honesty. Saying "HTMX scales to anything" is marketing language, not technical language.

The truth is boring and useful:

→ Server-rendered simplicity is a genuine win until interactivity crosses a line
→ That line is real, it exists, and pretending otherwise burns junior devs who trust the hype
→ The cliff usually shows up around state split across multiple locations and client-held state
→ Picking HTMX means deciding in advance how spicy your UI is allowed to get

The most successful HTMX applications I've encountered are not those that resisted the cliff. They are the ones which have drawn a solid line and declared "beyond this point, we are fine with some JavaScript."

A little bit of Alpine. A small island of actual client state. Not a renunciation of the belief, but maturity. 🙂

The takeaway

HTMX is a fantastic tool with a specific shape. It rewards apps that are mostly server-truth with light interaction, and it punishes apps that pretend they're that when they're not.

The complexity cliff is not a bug in HTMX. It's a bug in how people sell it.

So, let me ask you this: Where do you have the most difficulty with HTMX? Was it the modal? The multi-window update? Or was it when a PM looked you in the eye and said, "Can it be Notion-like?"

The Staff IC now out-earns the manager and it's not close

Aditya Agarwal — Wed, 16 Sep 2026 10:17:44 +0000

For the last twenty years, the advice was pretty straightforward. If you want to make more money, get off the keyboard and start managing people. That suggestion translates to earning less now.

The number that broke the pipeline

Levels.fyi's End of Year Pay Report, which was published in January 2026, based on 2025 data, revealed that the median total compensation for a Staff Software Engineer came in at $457,000. A 7.52% increase from the previous year. How about First-line Engineering Managers? Generally speaking, they make somewhere between $150,000 and $250,000. The median of the Staff IC is higher than the upper limit of the manager band.

This isn't one weird data point

If it was just one report, I wouldn't be concerned. But it's more than one. According to HR Oasis's March 23, 2026 report, engineering managers are now being out-earned by Staff and Principal Engineers in top firms, occasionally by 15 to 25 percent. According to a report by recruiting firm KORE1's Tom Kenaley on June 22, 2026, Staff engineers are paid between $190,000 and $260,000 in base salary and total comp ranges between $350,000 and $700,000 at big tech vendors. The 2026 Algoroq.io Salary Guide shows an increase. Total comp for Staff Engineer at the top tier firms including FAANG, Stripe, OpenAI, Databricks is between $400,000 and $750,000, with a few extraordinaries above $900,000.

Base salary is a trap. Look at the equity.

Here's the part that initially threw me off. An analysis done on August 12, 2026, by Recruiting from Scratch came up with a median base salary of $248,050 for a Staff IC in New York based on 362 active US postings. It was almost the same as $240,000 for an Engineering Manager. So where does the pay gap come from? Statistics provided by Algoroq.io show stock grants representing 40% to 60% of the total compensation of a Staff IC. This is the lever companies pull the hardest on for hard-to-find experts. Basic salary may seem equivalent to tossing a coin. However, total compensation is not similar at all. The equity is what really matters, and it is mainly accumulated on the IC ladder.

Why the market flipped

Managers haven't become weaker. They have had more demands placed on their time and skills. According to SignalFire's analysis on June 22, 2026, every engineering manager at a Tech Major currently oversees about 12 engineers, which is 14% more than in 2019. For startups, it's 15 engineers per manager, 34% more. While management talent is plentiful and relatively inexpensive, technical talent faces shortages and higher costs. SignalFire put it plainly: "top-of-band staff and principal packages at the Tech Majors now rival or beat director pay, reversing the management premium that defined tech careers for two decades."

Two decades of career advice, quietly inverted. Algoroq.io goes as far as mentioning a Senior Staff Engineer is paid more than a Senior Engineering Manager in a few companies.

What this actually means for you

I have seen competent engineers opt for the position of manager, believing that was the only way to get a substantial pay raise. The main differences to consider:

→ Base is a wash, equity is the game. If a role pays comp mostly in stock, that's where the gap opens. Compare total comp, not the number on the offer letter's first line. → Rarity beats headcount. The market pays for skills few people have, not for how many reports you can absorb. → Management is a role, not a promotion. Pick it because you want the work, not because you think it's the raise. This doesn't mean that managing people is negative. It is simply work that is different and some of us have the right mindset for it. However, if you are a strong specialist and only pursuing the manager track for the money, the 2026 data is sending a warning. Steer clear, the deep technical route is now a real destination, not a booby prize.

The takeaway

Many excellent engineers were convinced to take a life-long pay cut by the "go into management for more money" pipeline. It just took a while for the data to become more powerful than the narrative. If you enjoy managing, then go for it. But don't do it for a salary increase because the Individual Contributor (IC) ladder currently pays more, after all. 💰

So, my question to you is this: if we take the money reason off the table for becoming a manager, what's left to motivate you to make that move?

Astral endorsing Python Council candidates is corporate capture in slow motion

Aditya Agarwal — Sun, 13 Sep 2026 10:17:31 +0000

Recently, a venture-backed company implied to the Python community that they know best who should be governing Python packaging. A surprising move, right?

Astral, the organization responsible for uv, openly supported four of the five individuals who stood for election to the first Python Packaging Council.

What actually happened

On September 5, 2026, Astral dropped a blog post right near the start of the voting window!

Astral endorsed four candidates for the five-seat Python Packaging Council: William Woodruff, Pradyun Gedam, Ralf Gommers, and Donald Stufft.

This is the section that caused confusion. William Woodruff works for Astral and is a uv maintainer.

Astral was straightforward: "We decided to nominate one candidate from the Astral team: William Woodruff... We're happy to throw our support in with William Woodruff, Pradyun Gedam, Ralf Gommers, and Donald Stufft for the inaugural Python Packaging Council."

Why this council even matters

The Python community accepted PEP 772 in April 2026. It established a formal, five-member council that actually had authority to approve packaging standards.

The first election took place from September 1 to September 15 and nominations were closed by August 11. This was not just a casual poll.

This was the first governing body ever that had the power to decide how packaging in Python would work. And a single vendor put up four out of five of the candidates.

The conflict nobody wants to name

Astral doesn't just stand by and watch. It's behind the Ruff linter, the uv package manager, and the ty type checker.

These are powerful instruments, and their conduct is a direct result of the guidelines sanctioned by this council.

The company that has the most to gain from the packaging regulations was the one lobbying for control over who creates those regulations.

The criticism was immediate, raising fears of unfair treatment for rivals such as Hatch, Pixi, and Anaconda. When a dominant player chooses the umpires, the competition should be worried.

We keep rationalizing this

The Python developer Glyph Lefkowitz put it best in September 2024: "Just dropping in here to say that corporate capture of the Python ecosystem is the #1 keeps-me-up-at-night topic of my community work, so I watch Astral with interest..."

There was a good reason he kept an eye on Astral. Looking back now, two years later, it seems like he was more of a prophet than paranoid.

OpenAI revealed on March 19, 2026, that it bought Astral and welcomed founder Charlie Marsh and his squad to the Codex division.

So this isn't just a scrappy startup with good tooling anymore. The endorsement traces back to one of the most well-funded companies on the planet.

To be fair

Two of the four named candidates are well qualified. Pradyun Gedam and Donald Stufft are highly experienced with Python packaging and have made substantial contributions to the community.

There are no accusations of corruption being made. That's not what's being said. 🙂

It's all about how it looks and what motivates people. You don't want a vendor who has a lot to gain financially to be the one proposing a group of candidates for the organization that oversees their products.

Here's the excuse that people tend to ignore in such situations:

→ "But the tools are good" is not the same as "the process is fair"
→ Good candidates endorsed by a conflicted party still look conflicted
→ An employee on the ballot plus a company blog post is not a coincidence
→ Corporate money doesn't have to buy anything to shape outcomes

The slow part of slow motion

Apathy seldom resembles a villain in a boardroom. It resembles a nicely written blog post in a voting window.

It seems logical. It seems beneficial. That is precisely what makes it difficult to resist.

The community continually reassures itself that this is acceptable because the individuals are competent. However, governance should not be based on trust in whoever delivers the best tool.

Had Astral truly wished to defend the authority of the council, it should have refrained from interfering in the vote rather than seeking to seal it.

So, where do we draw the line? When does advocating for your business turn into undue influence over the laws that are meant to keep competition fair and open?

AI-generated websites are the Word Art era all over again

Aditya Agarwal — Sat, 12 Sep 2026 19:11:50 +0000

Do you recall Word Art? That rainbow gradient, arched text monster on every 90s school flyer. We are currently experiencing a resurgence of this technology, but this time it is used to create complete websites. ## The tell is already showing

Frontend developers argue that when AI generates design, users can immediately tell that design was made with "sloppy" AI. There's no list of reasons, they can just sense that it looks cheap. This is not a new instinct. We've been detecting generic clip art images in the same way. The stock handshake photo. The generic swoosh logo. Your brain automatically categorizes them as "low budget" before you even realize it. Many people on a developer forum are making a direct comparison to the 90s Word Art era. And you know what? It's more accurate than I'd like to admit. ## Why everything looks the same

Here's why the mess looks messy. A study from 2025, cited in a January 2026 article on Medium, showed that more than 80% of AI-generated websites had almost the same underlying structure. These tools replicate what already exists on the internet and reproduce the same trends. Framer's "Wireframer" was put through its paces by The Designer Review in June 2026. It certainly is an impressive tool, that spits out a responsive layout in under 60 seconds. While it can indeed generate "a typical SaaS product homepage," the problem with it is that if you feed it that prompt, you get an output that looks "assembled from a mood board of every SaaS homepage from 2021."

According to an agency with 200+ sites like Goodspeed Studio in a review from May 2026, "AI gets the shape right and the detail wrong." It's ok for a first draft. It's not a client launch without rework. ## Cheap solutions have always existed

This is what the panic crowd fails to understand. Affordable design tools did not destroy the art of design. They simply provided a low-cost solution for low-cost demands. An experienced designer commented in a thread from August 2025, "AI is the new clip art. It satisfies the same low budget demand with a cheap solution... Half the food trucks were using clip art shit for their marketing / logos so it makes sense."

Nobody was hiring a $10k designer for a taco truck logo in 2005. The clip art tier and the craft tier were never in competition for the same money. Sophie Davies from Your Marketing Department actually made the shrewdest prediction back in March 2025. AI web design "might kill" the ThemeForest theme market. That makes sense. What AI truly endangers is not the skilled labor but the mid-level of pre-existing templates which were halfway to the slop. 💀

The bill comes later

BlakSheep Creative rang the alarm on "AI jockeys" back in January 2026, and it's stayed with me. Sure, AI can write text but what about developing a strategy, building a brand, or creating a solid measurement and SEO framework? Most DIY AI websites lack all of these essential components. So the site ships. Then it doesn't convert. Then someone gets hired to fix it. BlakSheep's takeaway is the quiet punchline of this whole thing. → The rebuild cycles to un-slop a generic AI site often cost more than hiring a pro to build it right the first time. Buying cheap products may seem like a good deal initially, but if they don't last long and you have to buy them again, in the end it's not really a bargain. ## So what's actually happening

Artificial intelligence hasn't turned design into a commodity; it has turned the appearance of design into a commodity. Those two things are not equivalent. The thing AI actually threatens isn't skilled work; it's the low end that simply saturates the market, imitating a style that the general public will eventually notice without pinpointing. We already learned this lesson in the 90s. Word Art didn't kill off typography. It just made "made in Word Art" a thing you could read off a page in half a second. We are currently in the process of building that same reflex, one SaaS hero section at a time. Therefore, I would like to ask this: if the appearance of being AI-generated indicates an inferior product, does this ultimately increase the perceived value of human input, or will it simply result in more efforts to disguise this indicator?

Postgres for everything hits a wall the moment dashboards get concurrent

Aditya Agarwal — Sat, 12 Sep 2026 10:11:35 +0000

I used to say, "Just use Postgres."

After that, our dashboards became concurrent, and the read replica we quickly added to offload some of the pressure from the main database began overheating instead.

The meme that traps you

There is a reassuring notion that Postgres can handle all tasks. OLTP, queues, search, analytics, everything in a single package.

But it shouldn't be the ultimate goal.

MotherDuck was direct in their analysis from July 2026. As soon as you start providing real analytics, the "Postgres for Everything" philosophy becomes a structural inconsistency.

Typically, what most folks would do is they would probably get a read replica, isolate those heavy reads, protect the primary, and you're done.

Except that's not what happens.

A read replica does not fix the physics

Here's the explanation people usually find less appealing: A read replica is a duplicate of the identical row-oriented storage.

In May of 2026, the engineering team at ClickHouse put it best in their guide "While being beneficial in terms of high availability, performance, and horizontal read scalability, Postgres read replicas share the row-oriented limitations of the primary. They don't compress data effectively for analytics, and they still require heavy B-tree indexes that bloat memory."

So the compute is isolated. The physics is not.

The challenge lies in the physics. Postgres specifically stores data in pages of 8 KB, with a tuple header of 23 bytes fixed per tuple.

This implies that a dashboard query, for example, will pull in an entire row even if it only needs 2 columns. It's reading the entire row for a SELECT that only focuses on a fraction of it.

When you multiply that by the level of concurrency, the situation quickly becomes very difficult to deal with.

Where it actually breaks

Looking back on a September 2026 data engineering incident, a retrospective analysis noted that a replica had been hit by "hundreds of similar aggregations running at once," causing both CPU and memory pressure to spike.

WAL replay and fast queries were vying for the same resources, causing fast queries to become "painfully slow".

That's the part that gives it away. It's not a single slow query, it's the accumulation of them.

MotherDuck mimicked the curve as well. A dashboard aggregation that required 50ms when you were just starting out, increases to 5 seconds when you go into the tens of millions of rows.

That same aggregation eventually times out once concurrent load piles on. And your latency budget for customer-facing analytics? Anything under 100 milliseconds, and users perceive it as instant.

Five seconds may not be immediate, but it sure is faster than a support ticket!

Another cost people tend to overlook is the one pointed out by Brandur Leach and Gunnar Morling: mixing queue-like workloads with normal OLTP workloads in Postgres causes MVCC bloat, index fragmentation, and WAL pile-up.

You are not merely slow. You are gathering rot.

The expensive band-aid

Teams are forced to compensate for the limitations of a row store by investing heavily in hardware.

This is the reason why you eventually over-provision an AWS r8gd.4xlarge to handle some dashboard spikes. It's just there mostly idle at 3am, burning money, but you know it must do it.

You are paying the highest cost for a tool that is not meant to do that particular job. Increasing the size does not solve the problem of having the wrong format. It simply means you pay for it later.

The fair thing to do is to stop expecting the row store to behave like a column store.

Where I landed

All of these reasons do not imply that Postgres is inferior. I still choose to store my transactional data in Postgres, and I will defend that choice.

Asking one engine to be both the ledger and the analytics warehouse is the mistake. They're different shapes of problem.

The solution does not involve creating a larger replica. Instead, a column-oriented serving layer designed for aggregations such as ClickHouse is used. This layer compresses data significantly and specifically accesses only the columns required for processing a query.

→ Read replicas isolate compute, not storage format
→ Row headers plus 8 KB pages force full-row scans for narrow queries
→ Concurrency turns "fine" into "timeout" past tens of millions of rows
→ Over-provisioning is a tax, not a solution

Choosing Postgres for all kinds of data storage in your platform is like being madly in love. Nevertheless, everything comes at a cost.

So here's my question for you. What was the exact row count or concurrency level where you finally had to throw in the towel and admit Postgres alone wasn't ever going to handle your analytics workloads? 👇

Feature flags are the loaded gun modern deploys pretend is safe

Aditya Agarwal — Fri, 11 Sep 2026 19:14:01 +0000

A trading firm experienced a loss of $440 million within 45 minutes. This was not due to a cyber attack or a sudden crash in the market. It was a forgotten and obsolete feature flag that nobody had taken the time to remove. Let's get rid of it once and for all. ## The gun we handed everyone

The 2012 collapse of Knight Capital, one of the major participants in the US stock market, is the cautionary tale that every engineer kind of half-remembers when they're optimizing production error logging. A flag that had been repurposed caused Knight's systems to reactivate the "Power Peg" order router dead code from 2003. One accident of deployment turned it back on. Incorrect trading poured out for 45 minutes, and the company went out of business. Here's the part that bugs me. We learned almost nothing. Feature flags became extremely popular and began to be used in various applications, however, there was no proper method established to effectively manage them. ## The math nobody wants to look at

A report in June 2026 by GrowthBook quantified the chaos. Ten active flags can create 1,024 potential code paths. Twenty flags? Over a million. It is impossible to test a million code paths. You can hardly analyze ten. Therefore, the majority of teams do not analyze them at all, they simply deliver the flag and continue working. And those toggles are never cleaned up. GrowthBook cited a survey indicating that 77% of developers intend to delete toggles once they are no longer needed. Yet 75% of those toggles remain in the codebase for as long as 49 weeks after they are introduced. This proves that intention is not a cleanup strategy. ## Engineers there create 2,300 new flags every month.

DoorDash provided a glimpse in August 2026. The platform oversees over 60,000 feature flags in around 623 repositories. 2300 upcoming flags each month. More than 1000 of those are already marked as stale. If an engineer has to clean up a single stale flag manually, it will take them a full one to two hours of work. Imagine if there are 1,000 stale flags to clean up. Then we have a full-time job that no one wants to do. The issue here isn't specific to DoorDash. It's more about how default behaviors can lead to such situations. Once a flag is put in place, it's hard to get rid of it, so they accumulate over time. And then the stack of wood is ablaze. ## The blast radius is real

In February 2026, LinkedIn experienced a total outage. It was due to an unintentional release that changed all of the feature flags to the on position. Old, untested flags smashed together in combinations never before seen. It's Knight Capital with a better brand. The flag service is actually a single point of failure as well. PostHog's flag service had four different incidents over ten days in October 2025, with more than 14 hours of major impact in total. And that's how a denial-of-service attack can occur through resource exhaustion. Fireship performed a review of all these unaddressed risks and the theme is sadly the same for each one. → Flags are runtime mutations of production behavior
→ We treat them like config, not like deployed code
→ Nobody owns the cleanup, so entropy wins

The discipline gap

Here's what I really think. Feature flags are not the bad guys here. Using them carelessly as if they cost nothing is the real issue. Each flag acts as a runtime switch in your production code. It's a seriously powerful concept. We've made it so common and normalized its usage to such an extent that we removed the necessary guardrails that this level of power should come with. There are some teams that are making an effort. Uber open-sourced Piranha, a tool that hunts down stale flags automatically. Over a six-month period, it created almost 5,000 pull requests to remove dead flags in 10 million lines of code. If that doesn't prove the point, I don't know what will. This is not a nice-to-have. This is you waving the white flag and saying the manual way simply doesn't work past a few hundred flags. The uncomfortable truth is that we should put as much effort and rigor into deleting flags as we do in creating them. Expiry dates, owners, automated audit rules that break the build when a flag smells past its best-by date. None of this is done by default. We simply add the flag, release the feature, and casually walk away. ## What I actually think

I believe we have some redundant flags at my startup. Although, I have a tiny bit of doubt which is why we haven't removed them yet. The doubt you're referring to is the main issue we're all facing in the industry. A flag that you're afraid to remove is like a gun with its safety mechanism deliberately removed. We keep rerunning Knight Capital, crossing fingers that this time our accidental deployment will be a little cheaper. Here's a question for you: How many flags currently exist in your codebase that you could safely delete today, and how many are you just too scared to even think about touching?

A little copy-paste is cheaper than the wrong abstraction

Aditya Agarwal — Fri, 11 Sep 2026 10:17:54 +0000

One time I deleted what seemed to be a duplicated file, but it reappeared. I deleted it again, and the same thing happened. I did this three times before realizing it was an important file that kept regenerating itself for some reason. 🙃

The reflex we all learned wrong

At some point in your initial year, you received the same advice that I did. If you see two similar blocks, separate them. Right away. Doing things the DRY (Don't Repeat Yourself) way has been ingrained so deeply in our culture for so long that it became a knee-jerk reaction. Repetition is bad; software is about handling complexity, and removing repetition is just part of that. However, it's not actually part of that - it's a side effect we now mistake for a cause. Here's the catch. It is more difficult to eliminate the wrong abstraction than the redundancy it substituted.

Sandi Metz called it a decade ago

The phrase was coined by Sandi Metz during her RailsConf 2014 talk "All the Little Things." In no uncertain terms, she expressed that duplication is far cheaper than the wrong abstraction.

In January 2016, she elaborated on this in a blog post titled "The Wrong Abstraction" and her explanation is quite powerful. A bad abstraction turns into a "condition-laden process that interweaves a handful of loosely related concepts." That function with eight boolean flags that no one dares refactor. The part of her advice that everyone skips is the most important. "If the abstraction is wrong, the fastest way to get to the right abstraction is to go back to duplicating."

Why the abstraction fights back

Duplicated code is dumb and honest. The incorrect abstraction is not that. Each new caller adds another parameter, another 'if', another special case. It sprouts teeth. And no one wants to be in the position to delete it. Hence, it stays there, accumulating flags similar to barnacles. → Duplication has a local blast radius. One change, one place. → A bad shared function has a global one. One change, ten callers you didn't know existed. → Un-inlining a tangled abstraction is real archaeology. Copy-pasting is a keystroke.

The pragmatists agree

It was Rob Pike, Go co-creator, back at Gopherfest SV in November 2015 who included it in the Go Proverbs: "A little copying is better than a little dependency."

Consider what a dependency really is. It's a promise that two things will keep meaning the same thing forever. That promise is broken all the time. Kent C. Dodds elaborated on the same concept with "AHA Programming" - Avoid Hasty Abstractions, terminology first coined by Cher Scarlett. His mantra is just perfect. Keep replicating the code until the precise abstraction becomes evident through the repetition. Should you identify a pattern, don't assume it's the correct one after the second repetition. Revisit this process for a third or fourth repetition and let the pattern naturally emerge.

It's not just taste, it's productivity

Here is where I cease gesticulating wildly. Daniel J. Sturtevant's 2013 MIT PhD thesis quantified the impact of complex architecture on actual teams. Working in high-complexity areas dropped developer productivity by up to 50%. Bug density tripled. 📉

Also, turnover among employees increased significantly. Individuals will leave a certain codebase because they are unable to understand it. The process of prematurely implementing an abstraction contributes to this.

What I actually do now

In our team, at a small startup, I ceased extracting on sight. If two blocks resemble each other, I let them be. I will wait and see. If they mutate simultaneously three times, let's say they are one thought and I will merge them. If they mutate separately, I've avoided a landmine. The key is to be patient, and patience doesn't feel right when you have been accustomed to feeling smart. Being lazy for a few lines of code by copy-pasting I have learned to digest that. 😅

Because the alternative is a "clever" helper that ten people curse for two years.

The takeaway

It's not that DRY is incorrect. It's more like DRY came into the game too soon. The real mistake is not in repeating yourself, but in making assumptions about the abstraction you're creating before your code clarifies what it is. Wait for the scream, and then take out the core. Here's a question for you: Can you think of the worst abstraction you were ever hesitant to remove, and if so, did you ultimately remove it or did you keep it in place?

text-box-trim is the best CSS feature in years and nobody's using it yet

Aditya Agarwal — Thu, 10 Sep 2026 19:11:10 +0000

For years, you've been fighting the good fight for consistent text spacing in your digital products. But the fact is, all modern browsers quietly fixed that problem while no one was looking.

There is a text-box-trim native CSS feature that removes the phantom gap above and below your text. It's amazing!

The ghost space nobody talks about

There is invisible cushioning in every line of text, which is embedded within the font metrics and exists above the cap height and beneath the baseline.

You've experienced it. That button where the text is a bit higher than you'd like. That title which seems to be misaligned with the icon next to it, and you can't seem to correct it.

For years, we tackled this issue by using line-height calculations. We also used negative margins, and resorted to using magic numbers taken from a designer's Figma file that we hoped would work.

The entire ritual was actually a solution to a problem that we were facing because the browser failed to do so.

What text-box-trim actually does

It removes the extra space from the text box. No hacks, no negative margins, no guesswork.

The Syntax Podcast has just covered it. Along with alpha() and progress(), that's how a lot of people are hearing about it at all. Tells you something.

Here is how it goes:

The text-box-trim property in CSS is used to set the trimming of the text box. The text-box-edge property is used to define a reference edge for the cap-height of the content.

The top is capped at the cap height and the bottom is based on the alphabetic baseline. All other ghost (and possibly grim) padding is shaved entirely off the character.

Your text is now perfectly in line with where the letters sit. Vertical centering just does its thing. Icons line up perfectly. Buttons stop looking slightly off.

So why is nobody using it?

It's all about the tooling being resistant to change and difficult to adapt.

We developed spacing systems based on this old issue. Including design tokens, utility classes, and spacing scales that assumed the invisible gap was always there.

Removing such a hack poses a risk. So teams keep shipping the line-height hacks they've shipped for a decade, because the hack is what the codebase already knows.

That really confuses me. 🙃

We often express a preference for native platform features. However, when a really good one is introduced and our current tools or frameworks don't support it right away, we tend to overlook its potential.

This keeps happening

text-box-trim isn't special in being ignored. It's special in being obviously useful and still ignored.

The industry repeats this cycle endlessly:

→ A native feature ships and solves a real pain
→ Everyone keeps using the old workaround out of muscle memory
→ Two years later a framework "adds support" and suddenly it's cool

It wasn't the star that changed, it was our attitude.

I must admit, I've been guilty of this as well. Reflexively resorting to the old negative-margin trick, instead of using the proper tool designed to handle such cases.

Just try it

You don't need a migration plan. Just choose one troublesome heading. One button label that has always seemed inappropriate.

Simply apply text-box-trim to it, and you'll see that ghost gap disappear. That tiny moment where you think "oh, that's all?" is extremely important.

The platform has improved in our absence. The minimum we can do is pay attention. ✨

What's a native CSS feature you slept on for way too long before it clicked?

Function coloring is real and pretending context propagation isn't infection

Aditya Agarwal — Thu, 10 Sep 2026 10:19:14 +0000

Someone recently attempted to make the bold claim that function color isn't a real phenomenon. Unsurprisingly, the internet had a field day with that.

An essay went viral on this topic, cross-language, bringing Go, Rust, and Zig into the conflict. The argument: coloring is a non-issue conceptually.

Where the term even came from

Bob Nystrom actually first introduced the concept of "function coloring" in February 2015. His article "What Color is Your Function?" described async functions as red and sync functions as blue (even though Nystrom's colors were just made up on the spot and history has shown this to be the correct assignment).

The issue was straightforward. Red and blue do not blend well, and introducing one to the other requires a modification in the higher-ups.

Ron Pressler, tech lead for Java's Project Loom, would later describe this spread as "viral asyncification." Not a flavor of design, a virus.

The Go context detour

This is where it gets interesting. The Go language doesn't use async keywords, so many people believed it avoided the problem of "coloring".

A retrospective of a Causality.blog commented on this very occurrence in April 2026. It said Go "actually introduced a form of coloring through context.Context," since ctx flows through invocations for cancellation.

If you have been using Go since version 1.7, this is familiar to you. Input/output functions require the ctx context.Context as the first argument, and if one function needs it, you must pass it from every caller above.

That's the entire infection process. No keyword needed.

The "it's not real coloring" argument

An essay from September 2026 on Jerf.org is revisited. The essay pushed back on the idea. Its argument was that context.Context is not a color because you can pass context.Background() to stop the spread locally.

I understand the reasoning behind it. It is possible to fix the leak at one location.

But you know what really hurts? It's not the keyword or the type name it's the rewrite you have to do to add ctx to forty functions that never asked for it.

Even if you pass Background() it doesn't reverse it. It simply provides you with a false token to compile the signature. The plumbing remains plumbing. 🔧

What you're doing doesn't matter in a practical sense, since the circumstances will require you to update all callers in the stack. That's the main point, and rephrasing the definition of the term won't change that fact.

What Loom actually proved

Here's the scoop. Java's Project Loom shipped Virtual Threads in Java 21 back in September 2023.

Pressler was talking about avoiding the "method color problem" altogether, not by designing a better context object, but by allowing the runtime to handle the context of a thread.

Consider the implications. If context propagation was just for show, Loom wouldn't have gone to the trouble of having the runtime do it for you.

Years of effort were dedicated to avoiding the need for you to manually thread anything.

Why devs weren't buying it

Perhaps if we rename the illness, the associated symptoms will seem less like our own failings.

However, every developer who has been in the industry for a while has had to do a refactor that is not appreciated. For example, a leaf function that did not require a token, and you had to spend an afternoon passing it through the call tree.

→ Keyword or context object, the infection travels up the stack either way.

→ "You can stop it locally" is true and irrelevant, because the cost lives in the rewrite, not the escape hatch.

→ Loom's existence is the strongest evidence coloring is real pain, not pedantry.

Writing code in Go is different than writing Rust, which is different than writing Zig. But not so different that you think the other one is doing it wrong.

Describing an issue in terms of its functionality doesn't eliminate its impact on an actual codebase. This is what most essays fail to address.

So, my question to you is: Is context.Context in Go a color, a smell, or is it just the tax we pay for cancellation? Where do you draw the line?

Whiteboard interviews died the day AI could solve them live

Aditya Agarwal — Wed, 09 Sep 2026 19:16:46 +0000

The whiteboard interview went away not because it was inhumane, but because it lost out to a bot that could flicker faster than you could squeak the dry-erase marker.

Basically, timed algorithm puzzles only test one skill. How good you are at hiding a second monitor.

The trivia game we all agreed to play

Can we have an open conversation about what LeetCode screening has always measured? It's not skills. It's memory.

It calculated the amount of time you had spent grinding patterns over the past six months. That's it.

An essay on Medium from June 28, 2026 said it best. "AI didn't corrupt the whiteboard interview. It just made the corruption impossible to ignore by removing the one thing the ritual was actually measuring: how much time you'd spent on LeetCode recently."

That's the entire deception summarized concisely. We masked memorization as a substitute for engineering aptitude and assumed no one was aware of it.

The cheating got too easy to ignore

Here's where it falls apart. The machine is now better at the test than the people it's supposed to filter.

An article on PlainEnglish.io in November 2025 mentioned that GPT-5.1 and Claude 4.5 kind of models can solve a "Hard" LeetCode prompt like Trapping Rain Water for you instantly. They hand you the O(n) solution, comments, and explanation of trade-offs.

The same PlainEnglish.io piece, titled "The LeetCode Interview is a Scam," expressed it more straightforwardly. "If your entry test can be solved by a non-sentient autocomplete engine in 3 seconds, your test is garbage."

It's not only puzzle websites. As of August 2026, Failingfast.io reports that Claude Opus 4.5 achieved a 76.8% resolution rate with SWE-bench Verified, and GPT-5 scored 88.0% on the Aider Polyglot code editing benchmark.

In February 2026, Braincuber Technologies published a report stating that Claude 3.5 Sonnet achieved 93.7% overall coding accuracy, and scored 80.9% on SWE-bench Verified. The two SWE-bench figures come from different test runs and setups, so they aren't directly comparable. These aren't fluke numbers. They're consuming the very format we test on.

The arms race nobody can win

Cheating is not done in a clever way. It has become a commercial commodity.

In 2026, Final Round AI's Interview CoPilot™ became a fixture of live FAANG interviews. When the interviewer began to read the problem, the pattern silently appeared on the candidate's screen. "Prefix sums." "Sliding window." The response, whispered.

Now interviews have become a test for paranoia. Is the candidate looking away from the camera?

Devrim, who works as a software engineer, hit the nail on the head in September 2026. "You solved 300 problems, memorized all the pattern... and spent six months preparing to prove you can do a job that looks almost nothing like the interview... You are not going to beat a machine by becoming a larger storage device for known solutions."

That's the punchline. You can't out-memorize the thing built to memorize.

What actually replaces it

The companies with integrity are already making a shift toward decisions.

The shift is loud and clear if you're paying attention:

→ Architectural judgment over pattern recall. Can you reason about a system, not recite an algorithm?
→ System ownership over solo sprints. Do you know why a design breaks at scale?
→ AI-assisted rounds where the tool is on the table, not under it.

In reality, in the second quarter of 2026, Google launched a pilot of AI-aided coding rounds with interviewers' own models. By mid-2026, its internal research found that 75% of the new code in key software development repositories was generated by AI models. The final code was reviewed and committed by a human.

Isn't it interesting to consider? Nowadays, Google's hiring standards require you to work with a machine, rather than wait until you get the job to do so. Finally, the interview process reflects the real world.

The takeaway

The fact that the whiteboard ritual has made it this far is that it was easy to schedule, and easy to tally as a score. It was never precise. AI simply pulled the curtain and revealed that we were grading trivia all along.

Good riddance. The best engineers I've worked with weren't fast at Trapping Rain Water. They were slow, careful, and asked the right question before writing a line.

Here's the thing I can't get out of my head: if you can be 3 seconds faster than an autofill at an interview, what are we actually trying to assess for? What sets the great apart from the mediocre other than sheer fatigue resistance?

What replaced LeetCode in your last interview loop, and did it feel more honest or just harder to fake?