kevg123

Agreed, correlation isn't causation but two people on the same day with the same response that had never responded like that before, so something I'm keeping a watch for...

It's more of a meta point to me. I get that this series isn't landing for some people but the meta-observation is that given something of roughly equal substantiveness as before, these friends' motivations for long form content and discussion seem to have atrophied, perhaps largely due to the addition of the AI summary reality cipher to their lives.

It's more of a meta point to me. I get that this series isn't landing for some people but the meta-observation is that given something of roughly equal substantiveness as before, these friends' motivations for long form content and discussion seem to have atrophied, perhaps largely due to the addition of the AI summary reality cipher to their lives.

I've started down the path but I'm taking it delicately. The future may hold a whole new genre of interventions for AI atrophy.

Great idea, thanks!

I didn't provide much context but, 1) I've had deep conversations with these friends for years based on long articles or videos, and 2) I recommend maybe one or two long form items per year and they used to always review them without, "TLDR?"

So my main concern here is that my experience may be a microcosm of the shallowing of discussions correlated with some people's increased use of AI. That worries me.

It's more of a meta point to me. I get that this series isn't landing for some people, yourself included, but the meta-observation is that given something of roughly equal substantiveness as before, these friends' motivations for long form content and discussion seem to have atrophied, perhaps largely due to the addition of the AI summary reality cipher to their lives.

Of course, correlation isn't causation. Maybe they both just got older and more lazy, but given their reliance on AI summaries in other debates happening recently, I'm worried.

I wasn't even hyping it though. I shared it among friends to spark discussion. Sure, there's some hyperbole, but I found it thought provoking.

(FYI, I didn't downvote your comment)

You might be right but they used to read much more and our arguments used to be deeper. The changes I'm seeing in them are highly correlated to their increased use of AI.

Maybe it's something like that AI allows them to indulge in their shallowness/laziness by giving them the impression that they're not doing that.

I sent the entire series by Aphyr [1] to some friends. Two of them, independently, responded with a variant of, "TLDR, can you give a summary?"

I chat with these friends a lot but I rarely send articles that I suggest they read and that I think are profound, so I expected them to read it. These are smart people that have a history of reading lots of books.

They are both huge AI proponents now and use AI for nearly everything now. Debates on various topics with them used to be rich; now, they're shallow and they just send me AI summaries of points they're clearly just predisposed to. Their attention spans are dwindling.

[1] https://aphyr.com/data/posts/411/the-future-of-everything-is...

There's also a PDF version of all parts together which I've been sending around to friends: https://aphyr.com/data/posts/411/the-future-of-everything-is...

A lot of the sites on neocities have blogs on them: https://neocities.org/browse?sort_by=random&tag=

nekoweb is another one: https://nekoweb.org/explore?page=1&sort=lastupd&by=tag&q=

Nice link to the canonical book on Awk within the first linked page in the article: https://ia903404.us.archive.org/0/items/pdfy-MgN0H1joIoDVoIC...

Makes sense. One idea would be if the browser could detect packet loss (e.g. netstat -s and look for TCP retransmissions, and equivalent on other OSes) and open more sockets if there is.

As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue.

Why doesn't HTTP/2 use more than one socket?

Anything by Josh is gold.

Pretty cool. Any thoughts on adding a human-in-the-loop approval button on certain MCP calls?

I imagine sometimes I might want to require approval for certain tool calls all the time, whereas other times I might just want to add that to the prompt.

Cool stuff, especially spiderfier. What's your opinion of expo-maps? https://expo.dev/blog/introducing-expo-maps-a-modern-maps-ap...

I've been working 20 hours a week at a major company for the last 7 years and I love it. Full health benefits.

What kind of role are you in?

SRE/Programmer

How did you make the part-time arrangement happen?

I accidentally fell into it when I went part time to do a masters degree to consider switching careers but then, when I decided I didn't want to pursue the other career, I just kept doing part time and my company was fine with it. I work Mondays (7 hours), Tuesdays (7 hours), and Wednesdays (6 hours) and then I have Thursdays through Sundays off. I get paid half of course but it's still a good salary (grateful to be a programmer!).

What’s been the hardest part of working part-time in tech?

Sometimes it's easier for me to take calls on Thursdays or Fridays instead of pushing back on it (technically I could, but I don't want to jeopardize my part time status). This is fine as I just make up the time in the following week but it means that I can't easily treat Thursdays and Fridays exactly like a weekend as far as scheduling trips, etc.

Are there specific companies or setups that are more open to part-time roles?

I did it at a huge company so I think it's possible anywhere but I already had a great reputation and my company really wanted to keep me, and I think it would be harder to do without having a great reputation. I get the impression that companies generally don't like doing this because of the possible contagion effect of other workers wanting to do the same, so I generally don't talk about it much at work.

Any tips, advice, or experiences you can share would be super helpful!

Four days a week part time is much more do-able than three days a week. Don't limit yourself just to companies/jobs that explicitly advertise part time work, though those certainly also make sense to apply to, but just make part time a key part of the negotiation process. Consider emphasizing flexibility.

based on Intel EU stall profiling for hardware profiling

It wasn't clearly defined but I think EU stall means Execution Unit stall which is when a GPU "becomes stalled when all of its threads are waiting for results from fixed function units" https://www.intel.com/content/www/us/en/docs/gpa/user-guide/...

1. A classic book is The Mythical Man-Month and it discusses a surgical team approach that I think is interesting where there are lead surgeons and the rest of the team is there to support them.

2. Programmer Anarchy by Fred George on YouTube is an interesting idea.

What are the key assets you monitor beyond the basics like CPU, RAM, and disk usage?

* Network is another basic that should be there

* Average disk service time

* Memory is tricky (even MemAvailable can miss important anonymous memory pageouts with a mistuned vm.swappiness), so also monitor swap page out rates

* TCP retransmits as a warning sign of network/hardware issues

* UDP & TCP connection counts by state (for TCP: established, time_wait, etc.) broken down by incoming and outgoing

* Per-CPU utilization

* Rates of operating system warnings and errors in the kernel log

* Application average/max response time

* Application throughput (both total and broken down by the error rate, e.g. HTTP response code >= 400)

* Application thread pool utilization

* Rates of application warnings and errors in the application log

* Application up/down with heartbeat

* Per-application & per-thread CPU utilization

* Periodic on-CPU sampling for a bit of time and then flame graph that

* DNS lookup response times/errors

Do you also keep tabs on network performance, processes, services, or other metrics?

Per-process and over time, yes, which are useful for post-mortem analysis

I think the hardest part is deciding which gems to use. It's not uncommon to end up with over 50 gems in your Gemfile.

For example, built-in capabilities for authentication are limited: https://github.com/rails/rails/issues/50446

So then do you go with has_secure_password/etc., Devise, rodauth, authentication-zero, or something else? These are big decisions that then might affect other things like authorization, OAuth, PassKey, etc.

And that's authentication & authorization which are a relatively well-understood and maintained area, but other areas might have totally unmaintained gems that might have issues with recent versions of Rails, or native module compilation issues with more recent versions of operating systems, etc.

A lot of Rails guidance on blog posts and StackOverflow might be outdated.

This problem is not unique to Rails. I still think Rails is great and relatively vibrant. Nevertheless, I suggest being very wary of Rails guides, blog posts, and StackOverflow answers that are more than 1 year old and doing a careful study and inventory of gems before deciding to use them and reviewing their relative recent usage and activity.

Number of hours per week would be nice. I think we'll see a lot more demand and supply of 30 and 20 hour per week jobs.

The more common recommendation is to catch what you need to handle in a special way (if any) and then have a catch-all (or re-throw) for the rest, and if you don't need to catch anything specific, then just catch (or re-throw) all.

Think of exceptions like error codes. Most often one just checks if there is an error or not. Sometimes, one checks for specific error codes in addition to the general check. It would be rare to check every single error code, though possible.

By this analogy, I think the recommendation to check each type of exception is very uncommon.

Most importantly, make sure you do always catch exceptions at some level and handle them somehow (even if it's just logging), and also make sure no exception/error information is lost (e.g. blank catch block, not logging all exception details, not re-throwing with an inner exception so the original stack is lost, etc.).