tmorton

Rather, it will use the original cost basis, pay tax on gains up to the adjusted cost basis, and the inheritors will use the new cost basis should they sell in the future.

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!

Evidence Action - https://www.evidenceaction.org/

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.

It's impossible for us to give you a good answer from outside your company.

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.

I've had trouble finding it, but years ago, I read the abstract of a study which looked at chess performance, pitting people who had access to some basic chess software against those who didn't. What they found is that the strongest predictor of success was whether a player could utilise the software effectively, rather than pure chess skill.

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.

Yes, we need that too.

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

The churn now is meta-frameworks on top of React.

What is your team delivering, for customers? It's not tickets and story points.

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

There are many technologies that match this pattern: "While X can be a footgun, it can also be quite clean when you use A, B, and C."

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

Because "urgent system-wide transformation" is just a euphemism for war.

TLDR: The first stanza, not necessarily the second:

  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?

That's the niche for https://tailwindui.com - which is how the Tailwind creators make money. If you're convinced by the overall Tailwind philosophy, it's a steal at the price they charge.

It's an aquihire - they get the core team on staff. They can influence the open-source project roadmap, and get priority support for their integrations.

We're not gonna need it!

No, we ain't gonna need it!

We're not gonna need it anymore!

You can donate the crypto to charity, without selling. This avoids capital gains tax, and gives you a deduction on other income.

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

Is this the modern equivalent of getting stock tips from shoe-shine boys?

Software development is more like basketball than baseball.

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 can think of many cases where "the other side" refused to compromise, creating a negative-sum game. But let me cite an example where "my side" was in the wrong.

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...

For a lot of social issues, being given the midpoint solution is like being given half a baby.

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 Trinity study was about an individual's savings. A group, like a pension fund, has different requirements.

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".

Here's one writeup that seems comprehensive, and from a "hacker-like" perspective: http://slatestarcodex.com/2014/06/16/things-that-sometimes-h...

boggle

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.

Users lose because "legit" advertising is still toxic. Want some low-tar cigarettes?

I disagree with most of this comment, but I think it's an interesting and valuable discussion.

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.

Ok, that link makes things clearer, and I can understand their position a bit more.

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.

I'm pretty strongly on the Elixir train, but here's where I see its greatest weakness:

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.

At the time (1847), they were not the poorest people in North America.

... for a girl to be considered really beautiful to me, she should fall at least two standard deviations above the norm

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

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

I see Conway's Law as a statement about the world, not a class of problems. Team size is capped by human nature, and systems will develop to mirror team sizes. The only solution is to find lower-communication "seams" for both your team boundaries and your system boundaries.

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

Aside from the discussion of JS and React Native, I want to highlight this:

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.

I wrote a blog post on this topic a while back: http://timothymorton.com/post/67472164000/on-hiring-develope...