Hacker Newsnew | past | comments | ask | show | jobs | submit | tikhonj's commentslogin

If driving is dangerous and carries a bunch of negative externalities, shouldn't we expect "good people" to look for alternatives? Not self-driving cars, necessarily, but maybe transit and walking and biking.

And, of course, to support the policy choices that reduce how much we subsidize driving and improve infrastructure for those alternatives.


It really isn't. You could—and we did!—solve that problem by letting people defer property tax payments or borrow against their equity. California literally has a property tax postponment program for seniors. If we just wanted to keep people from being pushed out of their homes by rising house prices, we'd just expand that program.

The point of Prop 13 is to let people have their cake and eat it too: you get to keep the equity you gain from increased housing prices, but not pay the property tax that comes with them.


With postponement you then can get the opposite problem of people getting stuck in their houses because if they sold they would have a huge deferred tax.

The approach in Washington works well. There is a senior property tax exemption based on age and disposable income. To qualify in King County (where Seattle is) in 2027 you need to be 61+ and have a household disposable income under $101k.

That gets you (1) a freeze on the assessed value for taxes equal to the current assessed value, and (2) an exemption from the statewide school tax and from "excess levies" (basically city and county levies that are voted on).

If income is under between $76k and $89k they also exclude from tax 45% of your assessed value or $70k, whichever is larger, but not more than $200k.

If income is below $76k they exclude 80% of your assessed value or $80k, which is larger.

The income levels are based on median county household income so vary from county to county.

Disposable income is basically everything that goes into AGI plus a list of other things (like any Social Security that is not already in AGI). There are also a bunch of deductions, mostly medical including Medicare premiums, with a $7500 deduction you can elect to take instead of taking any of those specific deduction. Income includes all adults living in the house.

In my county the levies that are not "excess levies" are county roads, sheriff, conservation, mental health, veterans relief, fire district stuff, public utility district stuff, and regional library. The "excess levies" are a couple of school district levies. Overall the excess levies are about 28% of the property taxes in my county. The statewide school levy that is exempt is another 10%, so the bottom line is that the property tax rate for seniors under the income limit is about 60% of the non-senior rate.


I do own a house in California and I pay closer to $30k in property taxes. The previous owners of my house paid $7k. My neighbor—who has a bigger, more expensive house!—pays $9k.

It's pretty clear that this kind of tax policy is going to totally mess up the housing market. It's not the only factor, but it's a big one.


Prop 13 massively distorts the real estate market and creates some strong incentives for home owners. Those distortions and incentives would go away regardless of whether abolishing Prop 13 led to a net increase or decrease in total taxes.

I made Claude write noöp instead of no-op and it's still amusing a couple of days later :P

> I made Claude write noöp

Tangentially related [1]:

> The billboard ad, located next to the Ikea Tempe store in Sydney, says 'NÖFNIDEA? No tools, no worries’.

[1] https://www.adnews.com.au/news/koala-mattresses-takes-swipe-...


They're different situations for the person, but not for the banking system.

And reading some lack of empathy into a comment about the banking system is wholly unwrannted.


[flagged]


> you get no more from me

You're the one who started this tangent..


Let's sort git branches by quality, better branches towards the top, slop at the bottom.

I worked at a startup that did this and it was... totally fine? Like, we hired a guy who knew how to set Kubernetes up, he spent like a week or two setting it up, and then it was totally solid and the development experience was great. I was building some of the core product-specific logic and it only made my life easier.

Which really just goes to show that the "legible" aspects matter far less than the illegible aspects. It's easy to say "hey, this startup is using boring technology and deploying a monolith, great!" or "Kubernetes and a bunch of services, over-complicated!". It's hard to say "hey, this startup's codebase is awful and it's an unforced error slowing them down" vs "hey, these guys are taking some shortcuts but it makes sense in context".

But a mess built on "boring", simple tech is going to derail you far more than a needlessly complex but well-executed setup.


I remember reading an article years ago about how a company was running rings around its competition because they were releasing features faster and more effectively, due to their choice to use Lisp as their language. Of course a competitor who tried to pivot to Lisp was unlikely to have the same results - the specific language choice was not nearly as important as the fact that the founders were already experts in Lisp.

The point being, Kubernetes is easily the right choice for a start-up if you have a Kubernetes expert on the team (and the rest of the team is willing to put the time in learning the system and not just cargo-culting around it)


Let me guess, VC funded start with plenty of cash to splash around and play with tech, beef up those resumes?

This is one of the things I like with NixOS: it's easy enough to add new packages and patch existing ones that stuff like this can either live in the core nixpkgs repo or be managed through some community-supported overlay. (Great example of this is [nixos-hardware](https://github.com/nixos/nixos-hardware) which shares settings and fixes for specific laptop models and the like, or [emacs-overlay](https://github.com/nix-community/emacs-overlay) which has a bunch of extra Emacs-specific stuff that would not belong in the core repo.)

Why not put the content from the md file in the code as documentation?

Ideally, the code can actually help you structure that information. I've written a bunch of Haskell and OCaml like this, where the types in each module let me structure my documentation in a way that is actually easier for people—and maybe also LLMs—to track. As a bonus, it makes it more natural to keep the two in sync.


> why not put the content from the md file in the code

We do that :-)

https://joist-orm.io/modeling/documentation/#two-way-syncing

Technically the md file can have more free-form docs, but for the overview/fields headers that, by convention, map to the entity/field jsdocs, we do sync them over.


I currently use the separate md file to capture the mermaid diagrams about the code, it helps to get overview of the file and various scenarios. It is good to keep all documentation ideally part of the same code. But if documentation is more as part of the code, passion to read source file is reducing, for me.

*_learnings.md: I am also using one more _learning.md, that captures what agents learn while building this file. it depends the complexity of the source file. mainly if the source files is about low level, protocols and so on. even separate _learnings.md also helps. so have now. _learnings.md may be needed how much investigation we have done to produce a working protocol.c.

protocol.c, protocol.md, protocol_learnings.md


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: