4,462 karma · joined February 20, 2007
Humans have historically had enormous effects on the planet, in all sorts of dimensions. At this point there's no avoiding it, but we can be more thoughtful and deliberate in how we manage our environment.
And I think it's the perfect example. What good is a better unit price if you can't afford to buy in bulk anyway? If you're poor and you have a headache it's better to pay 25¢ for two aspirin than $10 for 100. Part of being poor is steeply discounting the future. The other 98 aspirin might take care of headaches for the next two years, but a lot can go wrong in in that time, and that $9.75 is money you need today.
Or rent: you can get a place to live for only $60/month. There's no running water, but it's clean and dry and it has a lock on the door. The cheapest place you can find in the US is a lot nicer, but also much more expensive.
Buses have no route maps, no shelters and no doors. They might not come to a complete stop when they pick you up. But you can ride for 25¢.
The US has a kind of minimum standard of living, but it comes with a minimum cost of living. If you can't afford that, you end up with nothing.
This would be pretty different from the ferret project, as the mammoth DNA available isn't in good shape. It would require genetic engineering as well as cloning, and mostly consist of introducing mammoth DNA into Asian elephants a few genes at a time.
There's a downside to all this, but ultimately it's to NPM's credit: the tools are so easy to use that people... use them.
If I may be forgiven a bit of preaching, I'll point out that the fundamental problem with the Python ecosystem is that package definitions are executable python code. This means they have their own dependencies, and are subject to all the pitfalls of general purpose programs - the halting problem, non-determinism etc. The Python community keeps trying to fix this by writing a better installer, and it's never going to work.
NPM and Cargo, with their declarative package definitions, are built on a far more stable base!
These cities DO make it hard to build new housing. There's no question about that. It's an ongoing political issue, and all the reasons listed have been used to attack or defend that policy.
1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.
2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.
3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.
4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)
Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
Risky, though, because if it turns out to be less benign than we thought - or mutates in such a way as to become lethal - we've just started a second pandemic.
Let's escape the woke bubble:
1. How to Be an Antiracist
2. White Fagility
3. Between the World and Me
The books it recommends are pretty diverse - Maya Angelou to Peter Drucker to Plato.Or how about the Trump bubble:
1. Time to Get Tough
2. Righteous Indignation
3. Going Rogue
Lots of religion here. What if we escape atheism? 1. Letter to a Christian Nation
2. God is Not Great
3. The God Delusion
Hmm. Not so much religion here... but we got Aldous Huxley, Bruce Li and Richard Feynmann.I think... I've got a lot of reading to do. I LOVE this tool.
In the case of rewriting an application feature for feature in another language, that may or may not be a good idea. Maybe we're switching from an interpreted language to a compiled language because we need better performance. Maybe we're replacing a huge pile of impenetrable bash with a well organized Python app. Maybe we're taking advantage of a library that's only available in another language. Maybe there's a good reason for the rewrite but it's so much work that it's still not worth it. Maybe it's just a engineers wanting to use the latest toys because it'll look good on their resumes.
It's totally legit to question the need for a given project. But the phrase "reinvent the wheel" is just scornful insult. It adds nothing to the discussion, and in fact makes it harder to discuss trade-offs.
Sometimes an existing wheel design is perfect for our use case, or at least good enough that creating a new one isn't worth the effort. Sometimes a tweaked wheel is what we need. Sometimes a radical departure from established wheel design is required to make a new machine possible.
Build vs buy is an eternal question, and it's reasonable to examine and reexamine it for any project. But "reinvent the wheel" is just hyperbole.