So, the blog post says to avoid using labels because they get in the way of making your point. People have preconceived notions about those labels, so anything you say about them is stepping into a minefield.

I agree, but there's so much more involved in convincing people than just avoiding offense. In fact the author sounds like they're saying to patronize your audience. That's possibly even more offensive than attacking their labels!

The only time it ever seems like magic is when you don't really care about the problem or how it gets "solved" and are willing to ignore all the little things it got wrong.

Generative AI is neither magic, nor does it really solve any problems. The illusion of productivity is all in your head.

Like any tool, you need to know how to use it.

For my uses, my rule is "long to research, but easy to verify". I only ask for things I can quickly determine if they're right or not, I just don't want to spend half an hour googling and sorting though the data.

For most of my queries there's an acceptable margin of error, which is generally unavoidable AI or not. Google isn't guaranteed to return everything you might want either.

The problem it solves is “I need some art-shaped substance, and I don't want to have to interact with, let alone pay, an artist”. It's lorem ipsum.

A "robot that does things" is the overpromise that doesn't deliver.

I actually agree with the article that non-determinism is why generative AI is the wrong tool in most cases.

In the past, the non-determinism came from the user's inconsistent grammar and the game's poor documentation of its rigid rules. Now the non-determinism comes 100% from the AI no matter what the user does. This is objectively worse!

The different flavors of non-determinism are interesting.

There’s chat-vs-api; same model answers differently depending on input channel.

There’s also statistical. Once in a rare while, a response will be gibberish. Same prompt, same model, same input mode. 70% of the time, sane and similar answers. 0.01% of the time, gibberish. In-between, a sliding-scale — with a ‘cursed middle’ of answers that are mostly viable except for one poisoned thing that’s hard to auto-detect…

I do agree that it's "bad" to need a reason to justify your existence and happiness, but that's totally separate from evaluating your performance at work. I think you're assuming too much.

I think weekly or bi-weekly is best since you're aligning yourself with the time scale that most workplaces tend to operate on.

I've actually had good conversations with nervous junior devs to help them see the value of their contributions this way. There's a lot less reason to stress out if you're working steadily and see that things are going according to plan.

I know devs can be focused on the literal tasks at hand, but the "10k ft view" is not just a cheesy thing people say and it should not be ignored. It gives perspective.

I had something come up recently that I think sounds similar. That project needs several time-sensitive jobs. When any one of them runs, the first thing it does is check a holidays.json file.

It parses the file using jq and compares its entries with the current time according to GNU date. At the root is the names of the jobs. Each job has its own list of holidays. Each of these holiday items in the job's respective list has keys for the display name of the holiday, the formatted date to compare to, and in a few cases the ISO day-of-week and a string containing a modulo arithmetic function (e.g. don't run the friday before Christmas, etc.).

Sorry, yes that means I call eval on that string and yes that means some of these are repeated in the same file under the arrays for the other jobs. Also, such lists will have to be maintained and the exact observed dates cannot always be known ahead of time beyond about a year since people can change their minds for various reasons (think bank holidays). Depending on your use case you may also want to define a start time and end time for a window of when this should or shouldn't run (i.e. business hours).

I don't know if that helps. I know it's hacky, but I don't think there's a nice way to handle things like "second monday after 4th of july, but if the 4th also happens to be monday then it should instead be the second tuesday". God help you if you also need to handle each holiday being observed in different timezones. At least at the end of the day none of this would be much code, just very terse code dense with meaning.

I hate audiobooks because they're way too slow and full of moods/tones that often contradict how I would have read it. I can't be the only one who thinks they're overindulgent and annoying.

For me, "overindulgent and annoying" is way too harsh. But they feel _sooooo_ slow and I kind of resent "missing out" on the other books I could have read while the audiobook plods along (even at chipmunk 2x babble speed).

I save audiobooks for times when I couldn't have read something else - while doing chores, driving, etc. - so I can avoid that "missing out" feeling.

I like these kinds of projects, but adding a file export/import is inevitable. It's less about the limits of a URL and more about practicality.

I also have no way to confirm that URLs aren't logged server side, so I'd never trust the claim about "no tracking". That's why these projects also end up self-hosted.

hash part of url only available in the browser, as far as I know, server doesn’t have access to # value

Typos and URL mangles are common though, and I'd still have no way to confirm if it got logged in that case. It's out of scope for anything in the github source, and instead depends on the server hosting the page. I know this isn't meant to be super secure, but it's still worth a mention.

Typos aren't making the hash part turn into something else. Like your parent comment explained to you, the hash part is not sent to the server. If you go out of your way to mangle the URL then of course a mangled URL without hash will likely get logged to the server. But I'm not sure how one would manage to go so much out of the way that they mangle the URL in a way that removes the hash.

You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc.

Percent encoding is particularly bad since it may also bloat the length causing truncation and the decompress to fail. There's endless footguns with URLs.

very easy for the server to intentionally (or by compromise) add a one liner to send the hash text up.

It can also be argued that when a culture seeks escapism it's because things are bad.

In other words, there's no correlation.