blurker

> People are terrible about planning 30-40 years in the future and terrible about making sacrifices to help people they don't know in small ways that are statistical and abstract.

Exactly my concern. The pandering appeals to us not wanting to change.

> How many times in that past 1000 years have we solved large hard problems through a global agreement to make everyone worse off?

That's not what I am suggesting. I'm suggesting we cut the excesses, which there are plenty of. Maybe it's not enough and so we should explore all avenues, for sure.

I often think of the "giant meatball" graphic that visualised all humans on the planet as a giant schmooshed ball sitting in Central Park, New York. To me this is a very powerful visualisation akin to the "pale blue dot" that shows just how few humans are on the planet despite how drastically we are altering it.

I think there are a lot of excesses that we can easily cut. And we should, until we come up with something better that provably will work.

I would like to see our species get off this planet and I hope that we can survive far into the future. I see the first step towards that being us learning how to sustainably live on the planet we have now. It's probably better to scale back our consumption now such that we can have a long time to develop whatever technologies we need instead of going full steam ahead with unsustainable consumption, banking on technological progress bailing us out in some way that we can't possibly count on in a short amount of time.

That makes sense to me. Then in your situation, assuming you need those metrics and they are helpful, it may be helpful to add a metric like "satisfaction" or something that could counterbalance the negative effects that the other metrics could have.

I could see how a satisfaction metric would counterbalance a work output metric. The team will probably feel less satisfied if they know that corners are cut or if they are having to work unsustainably.

FWIW, I am not saying we shouldn't try to innovate and I do very much want us to invest in science and technology that could be helpful.

I don't think we should count on these things such that we don't also take direct steps (cutting consumption where we can) to directly tackle this problem until we have the other options figured out.

Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster.

I think that qualitative metrics like satisfaction and collaboration could be helpful, especially when combined with traditional metrics like mean time to merge a code change. Taking my previous example of overworking or cutting corners to achieve high numbers, a qualitative metric for something like satisfaction might indicate a problem where a work output metric wouldn't.

But I think that any combination of metrics will be an oversimplification that could lead to problems if they are the only thing that matters. I'm not sure where the balance lies. I like that metrics can offer an objective view of performance and make it easy to spot trends. But I am wary of them oversimplifying things and dehumanising the team.

I too have come to think that no simple metrics will ever replace the need for a competent manager who can use intangible, subjective context to evaluate their team. I think that even if you get some metrics that work well initially, the system will change such that the metric becomes the goal and the metrics then become much less effective.

Also "climate change" is a more accurate name to describe the wider issue, imo. Climates around the world are changing in many ways, not just getting warmer everywhere. Some of the effects of climate change will be some areas getting a lot drier or wetter and even some places getting colder.

One of my concerns as someone who is part of the tech community is the innovation delusion. Many of us are focused on "magic pill" technology solutions to get us out of this. Things like fusion, carbon capture, electric cars, etc... As someone with an engineering background, I've been guilty of this type of thinking too. Whenever I encounter a problem I think about how I could apply technology to solve it. However, I think it's a bad idea to gamble our future on the hope that unproven technologies will save us from this disaster. We consume so much more than we need to have a good life. I believe we should drastically cut back consumption now and then let the technologies that may allow us to consume more prove themselves before we scale back up. But like many things, it's easy to pander with innovating our way out of this problem. It's more convenient for people to not have to change when they can buy into greenwashed technology ideas. The saddest part to me is that much of our excess consumption isn't even making us happier. Seems to be making us unhappy, really.

This reminds me of an episode of 99% Invisible [0] that I listened to. That episode also covered a bit about the history of indexes (which is relevant to the history of alphabetical sorting), including how scholars feared and resisted the adoption of indexes. It was super fascinating and I highly recommend giving it a listen if you found this article interesting!

[0] https://99percentinvisible.org/episode/alphabetical-order/

This is really cool, I'm going to try it out and probably hack on it!

Minor nitpick: it would be nice to have a requirements.txt included to make it easier to download the right dependency.

I love this message. I think that most of the time it's best to have an optimistic mindset about your team and trust that they are doing their best, or at least want to. In my experience, more times than not, unproductive teams aren't the result of people working on the team being "lazy." It's usually externalities like unrealistic estimates, poorly scoped tasks and various company-driven disruptions to the team's focus. And if people are "being lazy", it's usually still an indicator of other problems that have destroyed their morale and a leader should look to fix those things. Otherwise you are trying to treat the symptom, not the problem.

All in all a good writeup and I enjoyed his series so far. In his inserts article [0], I was going to nitpick about the change in records/s for the "same" code, but then I noticed that he actually changed the code subtly (ContentValues changed to Object) and assumed it was probably that. Also he acknowledges this difference at the bottom of the article:

> P.P.S. If you were paying attention, you might have noticed some funkiness going on with my numbers in the charts as well as the records per second breakdowns. They fluctuate kind of widely between tests. For example: the time it took to insert 100,000 track records within a transaction using db.insert() in the first two experiments went from 91.552 seconds all the way up to 145.607 seconds.

I do wish he would have also used explain to analyse what these inserts were doing really for further insight into SQLite. To be honest, I am left wondering how much of what is being observed is specific to the Java/Android/SQLite environment and how much is actually core SQLite behavior.

Also, another nit specific to the article submitted [1]... The title is a bit inaccurate imo. The article demonstrates how to understand the EXPLAIN output, but it doesn't really explain (no pun intended) how to actually implement optimisations using this information. To me that isn't obvious. Would we have to change the SQLite source to implement a better query plan? Is there a configuration? How do we make use of this explain output to come up with a better result? Without that, I think the article lacks the "Squeezing Performance" part. I read the other articles in the series as well, and none of them use explain information to make optimisations either.

[0] https://medium.com/@JasonWyatt/squeezing-performance-from-sq...

[1] https://medium.com/@JasonWyatt/squeezing-performance-from-sq...

thank you for the recommendation :)

thank you for the recommendation :)

I see it being like this:

Value: move fast (positive)

Anti-value: break things (negative)

Breaking things is not positive normally, but it's the compromise for moving fast.

I appreciate the repost. It's quite timely for me, because I had recently been reading and participating in a post about HN's apparent toxicity. This has helped me to gain some more perspective on the topic. Especially about how moderation is done. I'm really impressed by the moderators, I honestly had no idea how many people were moderating HN or how they did things. I admire the patience and care it sounds like they put into the community.

I think that it's not just people not knowing about the lifecycle feature, but also that when they start putting data into a bucket they don't know what the lifecycle should be yet. Honestly I think overdoing lifecycle policies is a potentially bigger foot gun than not setting them. If you misuse glacier storage that will really cost you big $$$ quickly! And who wants to be the dev who deleted a bunch of data they shouldn't have?

Lifecycle policies are simple in concept, but it's actually not simple to decide what they should be in many cases.

How is "break things" not a negative? That seems really clear to me and I think is an excellent example!

> Just like influencers in any other field, developer-influencers often describe a reality that is aspirational even for their own companies. It may be true that people writing about ideal processes live in an idealized situation where it’s possible, in which case they’re the exception that provides the rule. But most of the time — even if it’s true in one part of an organization or at one moment in time — this reality does not hold across their entire company and forever more.

BINGO! This really resonated with me. It's a good reminder that developer social media is going to have some of the same things going on as regular social media, like unrealistic comparisons to idealised snapshots.

> The next largest concern was that the language would become too complex (33%).

I'm also in this camp, although I would go further to say that Rust is already "too complex." Or maybe not. Go has already done an excellent job of being a very simple and effective language. Rust's complexity makes it very useful for some cool stuff. Like building DSL's.

But because of its complexity, Rust is not the language I would reach for in most cases when building almost anything pretty standard, like a basic web app backend. For that, I would choose Go over Rust every time. The reason being: the cognitive load of Go is far, far lower, and that is super important for maintainability and being able to collaborate with others.

Basically, in the Venn diagram of what Rust can do and what Go can do, I'd mostly use Rust only for what it can do well and Go can't. For example, a real time system that can't have GC overhead. Or sometimes I'll choose it anyway for my hobby projects, just 'cuz I think it's cool and want to use it. But if I put on my pragmatism/business hat and want to build anything seriously, that's the way it will go.

Take that for what it's worth since I'm very new to Rust (and I quite like it actually!). Although I have a lot of experience with a lot of other languages including C/C++, Java, Go, Perl, JS/TS, Python, and more. Rust is up there as one of the more complex languages I've used. I've really noticed it on the learning curve so far. Reminds me a lot of Scala, actually.

The onboarding experience of Go vs Rust is night and day. You can legitimately go from reading "A tour of Go" to understanding most Go projects within a day (if you're already an experienced programmer). And it's not because Rust is lacking good learning resources. It has amazing docs and so many amazing free resources. I'm honestly enjoying and learning a lot about it rather quickly, I think. But it's still taking a long time and I can see I'm in for a ride and will be going "oh wtf is that" in Rust source code for a very long time!

I feel like some others aren't seeing the humour in your comment. Or maybe I'm just weird. Orr maybe I'm new enough to Rust still that I don't get offended. Anyways, you got a laugh from me at least!

It would be really cool if godoc had a way to generate a module-specific documentation site like Rust can with `cargo doc`: https://doc.rust-lang.org/cargo/commands/cargo-doc.html

Basically, read the go.mod and generate the doc page for that. It doesn't seem like a big leap from what godoc already does, but AFAIK (and please correct me if I'm wrong), godoc doesn't have an option for this.

The reason I like it is it's basically a super simple "give me all the docs that are relevant to this project" command. I think it's super clever that cargo does this!

Even if it's registered in a local jurisdiction, the paper work may not be reliable and it will be possible for scammers in those jurisdictions to get that paper work. It's not like there aren't plenty of shady incorporated companies already. It's still going to be a time-consuming and expensive process to track down the paper trails. Probably it will require a specialist. It can get pretty difficult pretty quickly as people use shell companies and god knows what other tricks that are available in these systems. And the police aren't going to just jump on the case and do this all for you. They don't have the resources. For the average person, your police report is going to go in the bin. You're gonna have to do a lot of work or pay someone to do it.

- there will be scammers even in the areas with stronger legal systems (look at one of the other sibling commenters RE: Britain, for example)

- having a paper trail is reactive, not proactive

- the average person will have a difficult time tracking down a paper trail

Can you elaborate specifically which ideas you thought were terrible and why?

fwiw, I am not the biggest fan of Google's level of control either, but I think that the ideas in the video stand for themself. Forget the Chrome-specific stuff and just focus on the basic UX concepts.

Without providing some specifics, your comment comes across as pretty shallow and more about your dislike of Google than criticism of the actual ideas.

Here are some of the ideas that I think stand on their own regardless of who presented them:

- EV's cannot be trusted by users because different entities can have the same name, how is the user going to vet that?

- EV's have a problem of corporate name != domain name, how is the average user going to figure out if it's the right entity?

- Domains are difficult for users to verify because there are so many permutations possible with all the new TLD's, as well as subdomains

- URL's are difficult to read because paths are often non-human readable

- URL's are hard to share through non-digital means

and more... lots of generally applicable stuff that isn't all a giant Google conspiracy.

What is terrible about these ideas?

yeah, about that paper work...

1. The paper trail is probably not as good as you think. I feel like you're thinking of a US system where there might be some pretty solid systems in place, but what about all the other countries around the world? I'm sure there will be at least a few places that will not be great paper trails.

2. The paper trail only helps you after you've been scammed as a way to maybe track down whoever did that. A costly and time consuming process which may be next to impossible if you think about the complications of shell companies and legal jurisdictions. Or are you suggesting that before you use a site you go through all this work proactively?

> At the basis of love are four neurochemicals. Each has a different role but together they motivate us or to give us confidence to go into social relationships.

So love is basically some chemicals causing us to feel lovey. Makes sense...

> That’s what separates us from the animals. Animals don’t use love to manipulate others. We do.

Wait, what? Do none of the animals have the same chemical processes? This is a big red flag to me. Time and time again we have found that when people have said "animals don't X, only humans do" we find that to be wrong.

I stopped reading after this.

I feel like a lot of commenters may not have watched the video of Emily Schecter's that was linked in the article. IMO it actually did a better job of explaining the problem with EV's than the author's post did. Or at least it was very complementary.

There are a lot of flaws in EV. I think the biggest one I saw was that it is effectively no more useful than TLD's/subdomains. In fact, it's worse, because unlike domains, there can be multiple owners of the same corporate name!

To the people saying there is a paper trail... What good is that? There are "paper trails" for domain registration too. But that isn't very reliable and the same would happen with corporate registration. We know this all too well from how wealthy people use shell corporations to hide. And I'm sure there will be plenty of places around the world where it will be easy to incorporate for bad actors, even if some places do a good job of creating a paper trail.

Fundamentally, this is a hard problem to solve and I really don't see EV solving this any better than domains.

What about the Stripe Inc. example? That example alone is a pretty big nail in the coffin for EV in my opinion. Not to mention all the usability problems that user studies have found which render it effectively useless. It's not just the number of clicks either. What about how the corporate names don't match the TLD's? What about conglomerates that have all sorts of entity names? What about misspellings of corporate names, just like misspellings of TLD's?

I thought this was a pretty good summary, but one thing stuck out to me as not quite right:

> To be price competitive, cultivated meat needs to match the cost of animal derived meat.

I don't think that's strictly true. Plenty of people are willing to pay more for products that are more ethical. Also, meat prices are likely to increase as we grapple with climate change and other issues related to subsidized, unsustainable sources of meat that we currently use.

That being said, if we are still mostly around $10,000/lb, we are a long way off and the overall conclusion doesn't change much. Seems like there are some big things to figure out before it's going to be a thing in the markets.

I am in awe. Also, I think you are a huge masochist! It's like wood working with cutlery. But it's actually really informative about some advanced bash knowledge. Kudos!

Yeah. Mistakes are going to happen and what really separates the good companies from the bad ones is how they deal with those mistakes. This seems to be a good example (for the reasons you stated). I have seen plenty of incident reports from other services that don't really tell me what happened or what exactly was done about it. That's when I feel unhappy. Within reason. I'd still be pretty unhappy if a company was really negligent, even if they had a really great incident report :P