stult (u/stult) - Readit News

stult commented on Delta’s new AI-powered pricing strategy blog.getjetback.com/delta... · Posted by u/bdev12345

chollida1 · a month ago

Interesting thought.

What specific protected class is "harmed" by personalized pricing?

And how would you prove that the model discriminated against them based on a protected element?

stult · a month ago

You can’t charge black people systemically different prices than white people, for example. Neither better nor worse prices. Proving causality would likely be the hard part, but a systematic survey of disparate pricing could show disparate impact. AI models frequently are invisibly biased on race because of some feature that operates as a proxy measure that the developers don’t recognize. eg something as simple as ZIP code combined with a name is a highly reliable predictor of race, and there are many similar, far more subtle ways bias can creep into a model.

stult commented on The patterns of elites who conceal their assets offshore home.dartmouth.edu/news/2... · Posted by u/cval26

phtrivier · a month ago

Is there a good primer on how this kind of offshoring works, for people ? I have notions of how tax evasion / optimization works (things like the irish-dutch sandwich, where you manage to pretend that Google does not make any money in France because it has to pay a very expensive license to Google Ireland , etc..)

But for offshoring, I'm clueless as to how manage to "reshore" the money, so to speak, so that you can eventually... Spend it to buy stuff. (Or isn't that the purpose of hiding the money ?)

stult · a month ago

Brooke Harrington (one of the professors from the OP article) has an excellent book on the topic, called Offshore.

stult commented on Tell HN: Help restore the tax deduction for software dev in the US (Section 174) · Posted by u/dang

TheTaytay · 3 months ago

Thank you for helping to tackle this. The silence on this issue for the past few years from smaller software companies and their affiliates was surprising to me. The recent "time bomb" article was one of the few media pieces that actually took the time to describe it as anything other than a "tax cut for huge tech companies", which was refreshing.

My current favorite theory as to why there hasn't been more of an outcry is that many companies ignored the rule change (either out of ignorance or as an alternative to going out of business), and are forced to remain silent.

stult · 3 months ago

Many larger companies have an incentive to attribute layoffs to AI, because that serves to hype their AI products. Basically, they didn't want to say, "we are laying people off for financial reasons." Even though the financial reasons were triggered by a change to the tax code, because that doesn't play well in the media, particularly during a period of elevated profits. So Google, Microsoft, etc. laid a bunch of engineers off to reduce their tax burden and used AI as an excuse.

stult commented on Tell HN: Help restore the tax deduction for software dev in the US (Section 174) · Posted by u/dang

OneDeuxTriSeiGo · 3 months ago

So it applies to software engineers but under what definition of software engineer?

This [1] is the only definition the code actually give.

> (3) Software development

> For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.

1. https://www.law.cornell.edu/uscode/text/26/174

-----

Is a test or QA engineer considered a software engineer?

Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs?

Is a systems engineer, electrical engineer, or mechanical engineer considered a software engineer because they use MATLAB, etc and use programming to do their design work?

Is a sysadmin, DB admin, or other IT staff considered a software engineer because they write software as part of their job?

What about a quantitative analyst, data scientist, accountant, actuary, or any of the other maths and analysis adjacent job roles that regularly use some level of programming to do their job (and therefore write software)?

What about HR, etc who use excel documents? Excel is fundamentally just a graphical array programming language (and the design of spreadsheet tools is heavily inspired directly from APL). Is anyone who uses excel or builds/maintains spreadsheets considered a software engineer?

Like software engineering is such a broad field and programming bleeds into every part of modern business at this point.

stult · 3 months ago

Yes, this is an insane policy that reflects a complete ignorance of the on-ground realities. It was almost certainly only passed to help the 2017 tax bill's legislative scoring by the CBO.

I posted about this on Reddit the other day. https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidd...

> Yeah, it's pretty much completely insane. Although in your example I think you accidentally picked numbers that actually work out precisely to zero dollars in taxable income. The company (if US-based) would have zero taxable income in the first year because they can deduct 1/5th of the salaries (because there is a five year amortization for US companies, and 15 year for foreign companies), so they would have $1m in gross income and $1m in deductions resulting in $0 in taxable income. But you can tweak the numbers a bit to get the result you intended, e.g., $1m in revenue and $2.5m in salary would result in $500,000 additional taxable income under the TCJA's version of Section 174 over the previous version of the code, even though in reality the company operated at a net loss. (edit, just looked this up and actually the amortization is dated from the midyear of the tax year in which the expense is incurred, which is also just fucking bonkers, but that means I was incorrect and your example does yield a taxable income, because the first year in your example would have $500k in deductions rather than the full 20% of the $5m expense, resulting in $500k taxable profit)

> All of which means that we treat R&D salaries less favorably than ordinary salaries, which are fully deductible in the year they are incurred. So our tax code now not only fails to incentivize R&D as under the previous R&D tax credit regime, it actively treats R&D employee salaries worse than non-R&D salaries. Even though R&D jobs are generally the highly skilled, well compensated, white collar careers we want to keep in this country.

> Section 174 also specifically designates all software development as R&D, so there's no way to develop software while claiming it is not R&D. I'm sure accountants have been jumping through hoops in their efforts to reclassify other kinds of product development jobs as not R&D, which is the exact opposite of what R&D tax studies used to do, which was to label as much employee compensation as R&D expenses as possible, because §174 and the related, intersecting provisions of §41 (the R&D tax credit itself), treated R&D salaries more favorably than other salaries. To a certain extent, the OP article understated how much of a swing this revision to the tax code is. It isn't just that we are treating R&D salaries worse than we used to, but that we are treating them even worse than we treat other kinds of salaries. Which is bizarre in a world where the policy objective is to retain R&D jobs in the US.

> The purpose of capitalization is to match expenses to benefits over multiple tax years. So that the tax payer can't take a huge tax deduction up front to generate an economically fictional loss in the short term on an asset that will generate income over the many years. Amortization forces them to deduct the expense of the asset over time as the benefit accrues over time.

> This model is a poor fit for software. Construction workers produce an asset with a generally predictable and known useful lifetime and long-term stable value that is independent of the business. You can always sell a building.

> Software, however, does not generally create value for very long if it is not subject to continuous development and improvement. It also decays very rapidly when not maintained (e.g. security patches), yet there is no distinction in the tax code between new development and production support/maintenance software development. Nor would any such distinction make any sense in reality, because unlike a physical asset software is subject to continuous change and there is little distinction between adding new features and maintaining existing features. This approach to capitalizing salaries contrasts with other capitalized assets like buildings, where most ordinary maintenance costs are deducted in the current year, not capitalized.

> The value of software can be much harder to predict than other capitalized assets. Both in terms of the demand, but also in terms of the technical capability to deliver the desired product. Which is why it's considered R&D in the first place: there is inherent technical risk in many if not most software projects which is not present in other kinds of economic activities that produce capitalized assets.

> Software is often so specialized that it cannot be sold on to a third-party without selling the entire business around the software, including existing customers, distribution and sales channels, and supporting software engineering staff. It's not a liquid, fungible, alienable asset the way other capitalized assets typically are. There is no real market for the source code to Reddit, for example, because there is nothing technically special about Reddit. The company's value derives from the user base, the community, and the data, not anything particularly special about its software.

> The tax code also confuses the output of the software development process with the value software can generate. Software developers produce code. Some of that code is valuable, much is not. Unlike with other capitalized assets, you can't know in advance whether the software you produce actually works 100% of the time, even with robust testing and QA. Whereas you can be quite certain that a building will continue to function as a building if it is built correctly. Many software engineers actually regard code as a liability rather than an asset. The more you have to maintain, the more work you have to do to maintain the code base and the harder it is to add new features or debug issues with existing features. So if you can deliver the same capability to your customers with less code, then that is preferable. Which is to say, the output of the software development process is much more loosely tied to predictable economic value than other capitalized assets.

> Software is also frequently delivered as a service, which highlights the inanity of treating software as a fixed, long-term asset. The team maintaining a SaaS will handle day-to-day site reliability engineering work, which is never a stable output but needs to be constantly tweaked to match actual usage patterns.

> Last, and this is implicit in much of the above, but unlike other capitalized assets, software is never really complete. There are always more features, more optimizations, more bug fixes. Software development is never steady state. Either the software isn't being developed actively and quickly loses nearly all value due to code rot, or it is being actively maintained and improved and is producing value. Buildings don't stop functioning as buildings when you stop paying the construction workers. Thus, software development does not produce a long-term fixed asset but rather is a continuous service delivery process, where the revenue produced in any given year was produced by the same year expenses to maintain the software. Thus, software expenses and revenues are mostly naturally aligned in a single tax year, and therefore software is not suitable for amortization.

stult commented on Tell HN: Help restore the tax deduction for software dev in the US (Section 174) · Posted by u/dang

michaelt · 3 months ago

> What other sort of capital expenditure has you do releases every day, or requires 24/7 monitoring?

Quite a lot of them actually. If I spend $$$$ setting up a car factory with a big production line, I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.

Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.

stult · 3 months ago

> I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.

> Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.

That is precisely why those salaries are NOT capex

stult commented on Tell HN: Help restore the tax deduction for software dev in the US (Section 174) · Posted by u/dang

mediaman · 3 months ago

A lot of people don't know what this Section 174 is about, so here's a brief explainer.

Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit.

Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" an "expense", regardless of the fact that you paid them.

What you've actually done, Congress said, is bought a capital good, like a machine. And for calculating tax owed, you have to depreciate that over several years (5 in this case).

Depreciating means that if you pay an engineer $200k in a year, in tax-world you only had $40k of real expense that year, even though you paid them $200k.

So the effect is that it makes engineers much more expensive, because normally when a company hires an engineer, like they spend on any other expense, they can at least think "well, they will reduce our profit, which reduces our tax obligation," but in this case software engineers are special and aren't deductible in the same way.

In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.

The effect is that companies wind up using their scarce capital to loan the federal government money for five years, and so engineers become a heavy financial burden. If a company hires too many engineers, they will owe the federal government income tax even in years in which they were unprofitable.

These rules, by the way, don't apply to other personnel costs. If you hire an HR person or a corporate executive, you expense them in the year you paid them. It's a special rule for software engineers.

It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.

stult · 3 months ago

> In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.

This actually understates the issue slightly. The amortization is calculated from the midpoint of the first tax year, so actually you only take 10% in the first year. Meaning it takes six years to get back to square one. In your example, you would only capitalize $20k in the first year, $40k for the subsequent four years, and then another $20k in the final year.

stult commented on Discord's face scanning age checks 'start of a bigger shift' bbc.com/news/articles/cjr... · Posted by u/1659447091

m463 · 4 months ago

A humorous age verification quiz for the Leisure Suit Larry game.

My boss is a. a jerk. b. a total jerk. c. an absolute total jerk. d. responsible for my paycheck. Correct answer: d.

dated, and very politically incorrect...

https://allowe.com/games/larry/tips-manuals/lsl1-age-quiz.ht...

(scroll down past answers to questions and answers)

stult · 4 months ago

I'd say all of the above but my boss is very forgiving of me. It helps that I am self-employed.

stult commented on Hunt for Red October 1990 (2016) modelshipsinthecinema.com... · Posted by u/nixass

tptacek · 5 months ago

Just a quick note that this film really holds up, like weirdly well given its subject and vintage. If you haven't watched it in a long time, add it to your list.

stult · 5 months ago

Similarly the Clancy book Red Storm Rising really holds up well, and weirdly may be one of the best primers on Russian military practices, culture, and capabilities as the force was constituted during the first year of their full scale invasion of Ukraine.

stult commented on Hyperlight WASM: Fast, secure, and OS-free opensource.microsoft.com/... · Posted by u/yoshuaw

tadfisher · 5 months ago

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.

stult · 5 months ago

Also we have suffered a couple decades of JavaScript to give us that little extra motivation to make a common runtime environment work. And WASM is open source and thus not proprietary. And all the browsers (well, really, the one browser) are open source. The FOSS community is much more robust than it was 30 years ago, and there are many times more professional software devs floating around too, and security tooling and practices are substantially better now. Personally though I think the general antipathy for JavaScript and its endless parade of duplicative over hyped frameworks alone would suffice to push WASM forward.

stult commented on In Jail Without a Lawyer: How a Texas Town Fails Poor Defendants nytimes.com/2025/03/25/us... · Posted by u/ceejayoz

sorcerer-mar · 5 months ago

I think the most inconvenient thing is actually that it’s both (largely) accidental and systematic.

If you go looking for the source of “evil” breaking these systems, you’ll surely find a few bad folks purposely fucking it up, but removing them is almost certainly not going to fix anything. The vast majority of these systems’ behavior (good or bad) is effectively not driven by individuals whatsoever.

stult · 5 months ago

There's a long running historiographical debate about the relative influence individuals have over the ultimate course of historical events compared to systemic factors

For many years, it was popular (particularly in revisionist circles) almost entirely to deny individual agency and to rely instead exclusively on systemic arguments which highlighted the power of geography, ecology, culture, technology, and other complex systems to shape human events. That revisionist approach emerged partially in reaction to the near universal overreliance of prior generations of historians on the so-called "Great Man" theory of history, which assumes events are largely attributable to the decisions of a select group of politically powerful individuals. Nearly all of those individuals happened to be white, male, and wealthy, and thus Great Man history suffered not only from blindness to systemic factors that can shape events, but also to the experiences, contributions, and agency of anyone who was not rich, not white, not a man, or even simply not politically powerful enough to count. In other words, they ignore nearly everyone who has ever lived.

Although academic history has long since moved away from the Great Man theory, it remains a popular trope of low quality popular history books, and increasingly it has become clear that purely systemic, revisionist approaches with no consideration for the effects of individual actors are also inadequate to explain historical events.

Sometimes systems are more powerful than people, and no amount of good will or effort is going to fix a problem. The Vikings abandoned Greenland during the Little Ice Age because they had no way of controlling the climate or adapting efficiently to the changes. The climate system was more powerful than any individual Norse settler or group of settlers could ever hope to be.

Sometimes systems are weaker than people, and leaders can bend them to their will. After nearly 1000 years of independence from secular authority and mostly uncontested religious domination in England, the Catholic Church in the 16th century formed an incredibly powerful institutional system of religious control built on vast endowments of land. It was by and large extremely popular with the common people and historically served a critical role in bolstering the king's position by promoting a respect for hierarchy that naturally encompassed both their own elevated status as priests and the position of secular authoritarian rulers, who ruled as God's representative on Earth. Despite the Church's enduring local popularity, its immense wealth, its deep connections with the broader Christian world, and the powerful hold fear of excommunication and damnation had on most Christians, King Henry VIII managed to completely transform the institutional, legal, and property-managing system of the medieval English Catholic Church, sundering it entirely from Rome, depriving it of essentially all of its land holdings, and subordinating its institutions entirely to royal authority. And he accomplished this in a shockingly short period of time, only around a decade.

Why did Henry decide to throw his lot in with the Reformation? Was it because he saw the injustice of monks, priests, and friars siphoning off so much of his subjects' wealth to Rome simply to subsidize the already luxurious and decidedly un-Christian lifestyle enjoyed by the pope? Not at all, in fact in the years before his marriage to Katherine of Aragon soured, he wrote a book defending the pope, who promptly named the king Defender of the Faith in gratitude and recognition of his scholastic achievement. Did Henry instead recognize an opportunity to enrich himself? Probably not, the evidence suggests he wasn't that savvy about money, but luckily for him, he had Cromwell to take care of the pounds and the pennies. Ultimately, he just needed a divorce. Because if he failed to produce an heir, the danger of civil war would be intolerable, and Katherine was clearly beyond her childbearing years. But the pope wouldn't give him one, and Henry was a raging narcissist willing to burst through any boundary in service of his own ego, even risking his soul to break from Rome.

So individual idiosyncrasies can also affect the course of events, we can't just look at systems, and we can't just look at individuals, we need systems too. The relative influence of each over how a complex institution like a justice system develops is a highly contingent and fact-specific analysis. Sometimes the climate can push winters to be too cold even for the hardiest settlers. Sometimes an entire nation's centuries-long, enduring religious beliefs and ideologies can depend solely on the whims (and lust) of a single egotistical dictator. And sometimes when such a basic function is this messed up, you might actually find that there are indeed a limited number of individuals responsible, and that replacing them with competent or less malicious individuals will actually solve the problem.

That's the trick though, and where the systemic and individual-focused explanatory variables start to bleed into each other. If it is systematically impossible to find good people to staff these institutions, then yes merely swapping out individuals will not fix the situation because by definition you are swapping out bad people for other bad people. However, I seriously doubt that it is impossible to do so in this case, because even if the US justice system is messed up and broken, this is about the most messed up and broken that it gets. I think it's fair to say that 99.999% of the country does not experience systemic justice problems to the same extent as Maverick County, which is why so many people are reacting to this story with justifiable shock. So even assuming ad arguendo that it is systemically impossible to find truly good people to work in law enforcement or the judicial system, we know it's at least possible to find better people than they have in Maverick County.