tmorton

This is just incorrect, at least in the US. The estate does not have to pay capital gains tax for assets passing through to the inheritors.

It's a great policy proposal though - this is one fix for the problem!

This is the "safe bet" in my giving. They do a good job at improving lives, in the most effective way possible.

Center for Election Science - https://electionscience.org/

This is the "long shot" in my giving. Officeholders today are incentivized to carve out a slice of supporters, play to only that audience, and demonize everyone else. Approval voting is the best solution that I've seen. It's worked well in a few cities, but mainstream acceptance is a ways off.

Sometimes, "best practices" are pure waste. Sometimes they are even counterproductive. Sometimes they will pay off immediately. Sometimes they will pay off for the company, but only after the current team has left and won't receive credit. Sometimes they would pay off for the users, but the company doesn't care about their users.

If possible, discuss the issue with a senior engineer (or two) on your team.

I would not get too confrontational with your manager. At the end of the day, your customer is your employer. But keep a note of the compromises that you're making, and remember if they cause any problems. Determining when to cut corners, and when to break out all of the formal methods, is an important part of your maturation as an engineer.

There was a time when this was true - a grandmaster and a computer was stronger than either alone. But that window closed pretty quickly. Today, even the strongest GMs' best strategy is to follow the computer blindly.

This happens a lot in climate policy discussions - "what about this other solution?" The answer is always "yes, that too!"

This recent article seems like what you need: https://newsletter.pragmaticengineer.com/p/measuring-develop...

In practice, they don't end up "quite clean" outside small personal projects.

  Turning and turning in the widening gyre   
  The falcon cannot hear the falconer;
  Things fall apart; the centre cannot hold;
  Mere anarchy is loosed upon the world,
  The blood-dimmed tide is loosed, and everywhere   
  The ceremony of innocence is drowned;
  The best lack all conviction, while the worst   
  Are full of passionate intensity.

  Surely some revelation is at hand;
  Surely the Second Coming is at hand.   
  The Second Coming! Hardly are those words out   
  When a vast image out of Spiritus Mundi
  Troubles my sight: somewhere in sands of the desert   
  A shape with lion body and the head of a man,   
  A gaze blank and pitiless as the sun,   
  Is moving its slow thighs, while all about it   
  Reel shadows of the indignant desert birds.   
  The darkness drops again; but now I know   
  That twenty centuries of stony sleep
  Were vexed to nightmare by a rocking cradle,   
  And what rough beast, its hour come round at last,   
  Slouches towards Bethlehem to be born?

No, we ain't gonna need it!

We're not gonna need it anymore!

If you want to enjoy the profits yourself, you should pay the taxes.

In basketball, players do "take off" certain plays. But the most valuable players are still contributing during that time. A good shooter can just stand at the 3-point line. Even if they don't do anything, they occupy a defender and make the whole offense better.

A developer won't be cranking out code 8 hours a day. But if they are available to answer questions, perform code reviews, and generally help the team, that's a valuable contribution.

I'm a liberal-ish person, and I think most states could use more tax revenue. I'm also concerned about climate change. This is a pretty mainstream set of positions.

In 2016 there was a ballot initiative proposed in Washington state that would levy a tax on carbon emissions, and offset it with cuts to other taxes. The result would be revenue-neutral (or slightly revenue-negative). It was opposed by the usual suspects (energy companies), but also some environmental groups and the state Democratic party.

Part of the liberal argument was that the initiative wasn't perfect. Given a new source of revenue, liberals saw many needs that could be met, instead of tax cuts. But that wasn't the deal on the table. The initiative failed, and we got the "dead baby" of no carbon reductions, no spending on other needs, and a less efficient tax system.

Details here: https://ballotpedia.org/Washington_Carbon_Emission_Tax_and_S...

I think this cuts to the heart of the issue - and demonstrates the problem with this line of thinking.

I also think you're missing the point of the Solomon story. When Solomon proposed that solution, one woman said "No, no - give her the baby." That woman was willing to compromise. She was willing to compromise all the way, to lose the entire dispute, to preserve the important thing they were fighting over.

Solomon didn't actually plan to cut the baby in half. On many social issues, there is a negative-sum, "burn it all down" solution that leaves both sides worse. Which side reaches for that option? Which side is willing to sacrifice the deeper issue in order to "win"? That's the side that deserves to lose.

The reason is mortality. Let's say an individual has a 20% chance of reaching age 90. They are not willing to take the risk of being 90 and broke, so they need to save for ages 90-95.

With a large group of people, mortality is much more predictable. The ones that die early collect less, so the lucky few that live a long time can collect more.

To learn more about this, the term to look for is "mortality credit".

What?

NO. Just no.

This doesn't "anticipate the things I need". It doesn't "anticipate" anything. It's not "the things I need", it's whatever MS decides to promote.

There's a vaguely similar feature, that would be vaguely defensible - but this isn't it. This is malware, plain and simple.

Here's where we agree: You need to stop the erosion in order to fix it. Every developer on the project needs a shared vision of what "better" means. For example, the parent comment mentions React components that manipulate global variables. First of all, everyone agrees to stop doing that, and agrees on the alternative (use props, a redux store, whatever).

But you don't stop the world and rewrite to the new standard. Instead, you apply a strong "boy scout rule" to every code change. If a developer modifies a small component, they also need to remove the global references. If the existing component is large, the developer must extract a smaller one, and the new extracted component must meet the new standard.

This will slow your velocity - at first, by a lot. But you never stop delivering entirely. You never waste time rewriting things that you would never touch again anyway. You also learn along the way - because while "don't use globals" is pretty universal, most architectural decisions are not. You will find that the "clean new standard" changes to match your application. At the same time, everyone on the team learns about the new standard, and buys in to the new way of doing things. There isn't a "new system" with the cool kids, while the B-team strings along the old one and waits to be laid off.

But they missed the BIG OBVIOUS solution: charge a pro-rated "first month" pledge, then combine all subsequent pledges like they do now.

For example, if I become a patron at the $10/month level, on the 15th of the month, they can charge me $5 immediately. Then the $10 gets added to my regular charge on the first of the month, and everyone saves in processing fees.

As a patron, I would much rather get one charge per month on the first. The current schedule works great.

On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.

In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.

For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.

> ... [in intelligence] I will settle for someone a mere one standard deviation above the normal

Yeah, that would do it. Nothing to learn here.

Abstraction layers around teams sounds like a good thing, as long as they abstraction layers make sense.

> Perhaps more importantly, your software development platforms also shape you as a software engineer. A software development platform encourages (or forces) the use of one language over another, prioritises certain architectures over others, requires using specific tools and workflows, and marries you to an entire ecosystem and its developer community.

People talk about the "right tool for the job" and "good developers are polyglots." This is true to an extent, but there are still communities with different priorities, and they often form around languages and tools.