Somewhat related: https://news.ycombinator.com/item?id=44828559
Readit NewsDead Comment
moogleii commented on Japan's gamble to turn island of Hokkaido into global chip hub bbc.com/news/articles/c86... · Posted by u/1659447091
moogleii commented on AI slows down open source developers. Peter Naur can teach us why johnwhiles.com/posts/ment... · Posted by u/jwhiles
You've missed the point of the article, which in fact agrees with your anecdote.
> It's equally common for developers to work in environments where little value is placed on understanding systems, but a lot of value is placed on quickly delivering changes that mostly work. In this context, I think that AI tools have more of an advantage. They can ingest the unfamiliar codebase faster than any human can, and can often generate changes that will essentially work.
That would be an aside, or a comment, not the point of the article.
Recently learned that one of Ben Franklin's sons was a loyalist. He fled to England after the war.
moogleii commented on Bus stops here: Shanghai lets riders design their own routes sixthtone.com/news/101707... · Posted by u/anigbrowl
I think this is one of those ideas that sounds good on paper but breaks down in practice.
One immediate problem that comes to mind is that you need a smartphone to take public transit. So if there's a teen without a smartphone, they can't take the bus, nor can someone who's phone died, etc.
One of the amazing things of the current system, as simple as it is, is that it's predictable and doesn't require coordination. You can walk to a bus stop and know that a bus will arrive and take you where you expect to go, same as the last time you've taken it and the time before that. You don't need to look up a map to see what today's route is, or to see where the stop is, or to let the bus know you're waiting for you. You just show up at the bus stop and the rest just happens in a predictable and reliable fashion.
I didn't get the impression this was totally replacing static routes. Seemed to be augmenting it. But also, while your concerns are valid, I don't think they are large enough to not try these things.
Fairly misleading wording with such lines like "Most of the funding for all of the major browsers is going away"... it makes it sound like it goes directly towards the individual browser budgets. That might be true of Mozilla since they don't make that many products tbh, but with Apple and Microsoft, there's no evidence Google's payments don't just go straight into a general fund.
moogleii commented on Better typography with text-wrap pretty webkit.org/blog/16547/bet... · Posted by u/todsacerdoti
I'm confused, this was created by Webkit, but is currently only available on Chromium based browsers according to : https://caniuse.com/?search=text-wrap%20pretty
How did that happen?
moogleii commented on Better typography with text-wrap pretty webkit.org/blog/16547/bet... · Posted by u/todsacerdoti
From the blog about pg_search linked by TFA:
This is what we did:
DB with pg_search: We created a single BM25 index
DB without pg_search: We created all these indexes
GIN index on message (for full-text search)
GIN index on country (for text-based filtering)
B-tree indexes on severity, timestamp, and metadata->>'value' (to speed up filtering, ordering, and aggregations)
Perhaps you can argue that creating a fastupdates=on index would have been the right comparison, but you didn't do that in that blog.
> You can always cherry-pick a query and optimize it at the expense of data duplication and complexity. The Neon/ParadeDB benchmarks contained 12 queries in total, and the benchmarks could have:
TFA isn't cherry-picking to show you that one query could have gone faster. TFA is showing that you didn't compare apples to apples. Looking at those 12 queries nothing screams at me that TFA's approach of storing the computed tsvector wouldn't work for those too.
Perhaps pg_search scales better and doesn't require trading off update for search performance, and that would be a great selling point, but why not just make that point?
There is an art to communicating that I think people learn around their college years...
This is the kind of argument that makes people come up with middle manager stereotypes in the first place. In fact, the whole post is a great example of why middle manager stereotypes exist: it starts with a straw man argument and comes up with a "better alternative" that makes life easier for the manager, regardless of what the manager's reports really need.
I've seen this whole "I will empower you to do everything on your own" principle in action and it's exhausting. Especially when the word "empower" is a used as a euphemism for "have you take on additional responsibilities".
Look, boss, sometimes empowering me is just what I need, but sometimes I need you to solve a specific problem for me, so I can keep solving all the other problems I already have on my plate.
"A common response is to invent new work, ask for status reports, and add bureaucracy. A better response is to go back to working on technical problems. This keeps the manager’s skills fresh and gets them more respect from their reports. The manager should turn into a high-powered spare worker, rather than a papersshuffler."
While being an IC and a manager is quite challenging, I think it's worth discussing the various permutations of it (only one of which is what the author has written about). It can lead to all sorts of systems (round robin leadership within a team being probably one of the most experimental). But for a more conservative, traditional system, there are many examples, e.g. Apple leadership coming out of former ICs.