snth

Will this work for F#?

Jesus- a subscription fee for a Markdown editor?

Your view is completely opposed to all of the recent "Google search is totally broken due to garbage SEO sites" HN articles.

I'm glad, and I shouldn't try to pigeonhole you here either, I just think these types of conversations lose specificity quickly.

Person A: I'm doing <this thing> to support <cause> Person B: You shouldn't do <that thing> Person A (or more often, C): Inaction is equal to support / silence is violence

I think there is almost always more than one possible action, even in support of <cause>. Also, some well intentioned actions can hurt a cause, so inaction is obviously preferable. Or, there may be a third outcome that I like better than <cause> or <not cause>.

Let me get specific, to avoid my own criticism.

I don't know if what the original commenter is doing is worth the effort, in terms of supporting Ukraine in this conflict. There's obviously a cost, in terms of dev time and false positives (showing the message to an unintended audience). I do think it is usually annoying, distracting, and unnecessarily polarizing to add politics to technical projects, so I would lean against doing this, even if I agree with the politics. Good technical work is hard enough on its own.

I'm not terribly offended by this action, and I wouldn't criticize it on its own; but I definitely think that "inaction supports the Russian invasion" is out of line here.

No, it isn't. The comment we're replying to here is about someone adding a message to their code repo that's shown to Russian viewers. Are you saying that if people don't do this, they support the Russian invasion? It seems pretty obvious when you get specific. It's simpleminded to divide people into two groups and say that anyone who doesn't agree with a _particular action_ is the enemy.

Inaction is equal to support of the Russian invasion

No, no it isn't, in this or in other situations. More than two choices _usually_ exist. Statements like this present a false dichotomy in an attempt to coerce people to support a preferred position or interpretation.

Understand things like, "what is in shampoo", to take an example from the article? I like to understand things too, but there there's plenty of things to learn, and I think one can benefit from being choosy.

Sure you can- don't be discouraged. You can dump your leftover household chemicals in your yard, or in a storm drain!

I wish America had more bikeable cities and better public transport too, but I don't see what that has to do with the linked article. I would also really like a dumbcar.

The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.

I personally like take-home problems. It's hard for an employer to time-box them without resorting to basically leetcode though. I know that, as a student, I definitely spent many hours on them.

It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring. If you aren't allowed to consider culture fit (because it's discriminatory) or education (because it's discriminatory) or give take home work (because it's discriminatory against people with time constraints) or trust your feelings in a qualitative interview (because they're discriminatory), what can you do? Solving real engineering problems takes too long for an interview, and full-day interviews are also discriminatory against people with time constraints. You can candidates give some automated algorithms problem solving test- that's what you can do.

Yes- death to Philips and slotted screw heads. Torx, square/Robertson, or (internal or external) hex heads are all so much better.

Which are better in this regard?

If you want a review for something that came out today, there is no way that work could have been done, so there simply isn't anything to find.

That's not strictly true, given that reviewers are often sent pre-release versions of things in order to do that work before release day.

Several people mention DuckDuckGo in that Twitter thread. I use DuckDuckGo for my main search engine, and it's not obviously any better than Google regarding SEO spam.

I think it's great that you do this, but I agree with the parent that it's rare.

Eh... regardless of how it's generally used, I think "leech" implies a parasite that is actively harming a host. Generally users who don't contribute aren't directly _benefitting_ the author, but they generally aren't harming the author either.

Isn't the usual complaint that people (politicians included) _under_estimate exponential growth?

What is this website? Is there an "about" or something? What is it doing differently from the official AWS status page?

Open source projects seem happy to yank the carpet from under their users, depending on what you mean. In the Python world, I'd put Python 3 and pip 21 in that category.

PDF is my favorite book format. I like the idea of reflowable text, but my experience is any book with pictures, tables, or math looks pretty terrible as an epub or kindle book. Books that would be suitable for Kindle (usually fiction), I find listening to as an audiobook much more convenient .

Counterpoint: life in communist countries is not known for being "not miserable".

Does this affect Brave?

The former are usually pretty good.

From the other side of this: as a developer who is required to _use_ in-house recruiters as part of hiring, my experience has almost never been good. I don't know if the incentives are bad, or if we just have a _much_ lower bar for hiring recruiters than developers, but our recruiters can't be depended upon for simple things like sending prep emails to candidates or telling us what position a candidate is interviewing for. I honestly think we'd be better off cutting them totally out of the process.

I don't believe this one. I guess it's possible it was originally true, but I don't think it's relevant now. I've lived in a house where we let the lawn go. It got very brushy and wasn't usable by us anymore. It was difficult to even walk though. AND, by that point it was too high to cut back into shape with a regular lawnmower. So I keep my lawn trimmed for the practical reason of wanting to use it.

I understand the desire, but there's a reason "product ownership" has become a trend. Similar to what's mentioned in the article, development and deployment and working with customers aren't independent. I would rather "own" my software than attempt to work on a stream of "isolated" tickets. And I think the real task of delivering value to stakeholders is more efficient without over-specialization.

Isn't it an "Atomic Mecha Repairman Robot"?

Try installing an HP printer on macOS by following the provided instructions

That's interesting. I guess the problem software I'm thinking of is all written by software engineers for software engineers, so the "detachment" issue isn't as severe. There is some, since we work in different parts of the business. The main issues I see are that 1) a small in-house team working on internal tools doesn't have much hope of putting in the time and resources of a whole company developing the same thing for public customers 2) once a company funds an internal tool, there is usually a lot of pressure (or even a mandate) to use it, even if there are better choices 3) the in-house team is also constrained to use our other in-house tools as dependencies, whether they're better or worse than other choices.

I can see the advantage to developing something in-house if there aren't options that meet some special need, I just personally haven't seen it work out much. Maybe because of the size of companies I've worked at. I've definitely written helpful software for myself and my own team.

I agree with this article that the UX of the software I have to use for work is terrible, and it's very frustrating and demotivating. But their proposed solution at the end- internally developed software, seems to be the worst offender. The worst software I have to use tends to be internally developed, poorly documented, supported, and designed copies of widely used software like bug trackers, project management tools, CI systems, etc. The justification for reimplementing these internally is often security, scalability, or integration requirements though, not UX.