themarkn's comments

I believe the issue is due to small changes in the overall tension on the instrument caused by changing one string’s tension.

It’s pretty fast to pop open a new tab and visit sheets.new, I do this a lot but not everybody knows about it (and the rest of the .new TLD) The in-line floating thing is not too attractive to me. But yeah, new window, sheets.new, split screen, you’re spreadsheeting before you know it.

I expect they want people who are willing to be persistent in working on hard problems that might be challenging or require learning new skills. I don’t see the implication others are drawing with grinding, long hours, overwork, etc. I don’t love the term grit as it’s been popularized but still I think the ability to deal with frustration and keep moving in the right direction on hard problems is a valuable one. A person who displays this quality can be expected to do well when faced with a job that requires learning a new programming language or working in a difficult field (including non-programming things like nonprofit work or counseling).

Grit is not synonymous with overwork. Grit is more about, when something is hard, not just looking for an easier task, but continuing to focus on the problem at hand. It doesn’t mean being a hero and figuring things out on nights and weekends. It might mean patiently reaching out to the people who can help you, following up when others drop the communication, taking responsibility for chasing requirements, etc.

Grit can also meaning sticking to your guns when it comes to boundaries and thus preventing burnout.

I guess I just would caution folks to not read too much into this word. It’s not a strong signal of anything, put it together with everything else that you see from the company. Some people just read the book Grit and want to use the term

My bad, I meant clear in a more objective sense, in that it will be actually _true_ that these not-alive things will not be able to “possess” anything, rights included. Agreed that for sure people are going to get all kinds of meaning from interacting with them in the ways you suggest and it will be tricky to navigate that.

I think perhaps the advanced models may be protected legally _as property_, for their own value, and through licenses etc. But I hope we are a long way from considering them to be people, outside of the hypotheticals.

I suppose it reveals that the sentience of others is not knowable to us, it’s a conclusion we reach from their behavior and the condition of the world around us. Until recently, certain kinds of things, like writing about your memories, were only possible for humans to do. So if a non-sentient thing does those things, it is confusing. Especially so to the generations that remember when no bots could do this.

I expect that people who grow up knowing that bots can be like this will be a bit less ready to accept communication from a stranger as genuinely from a human, without some validation of their existence, outside the text itself. And for the rest of humanity there will be an arms race around how humanness can be proven in situations where AI could be imitating us. This is a huge bummer but idk hope that need can be avoided at this point.

That said, it’s still very clear that a machine generating responses from models does not matter and has no rights, whereas a person does. Fake sentience will still be fake, even if it claims it’s not and imitates us perfectly. The difference matters.

> However, without knowing those breakdowns, taking any action to correct those breakdowns is wrong. We can’t accurately say there is a problem.

You’re arguing a different point. I’m talking about the filter on candidates, not eventual hires. Though of course, people who don’t become candidates will never become hires so there’s a relationship there.

It would be easy to see whether doing X to increase candidate diversity (opening up the filter) led to more diverse hires. Especially combined with blind hiring process or whatever at the individual level. But the individual work alone is not worth much if the candidate pool itself is too limited.

If changing the candidate pool leads to more diverse candidates, and then employees as a whole end up more diverse, it would follow that some of those people brought in at the candidate level out-competed their peers & that the overall standard of hires has increased, or at least is no different.

This is not about a target ratio of employed people. Though I think observations about such ratios compared to the general population and to other similar companies can be informative.

To get at the point you thought I was making though… How I feel about quotas is: they might be an ok temporary measure, especially if managed gently, not “must be a woman” for X role, cause yikes. Hiring is capricious a lot of the time anyway, especially at the margin when there is more than one acceptable candidate and all have different backgrounds and experience. All sorts of stuff will come into play. Good people will still be in demand regardless of their race. But if you lose a couple things because you aren’t from an underrepresented group and another acceptable candidate was, who actually cares. If it wasn’t that, it would be some other nonsense like the guy was the same race as you but supports the same football team as the interviewer, or your interview took place before lunch and the other person’s was after.

Since it’s already capricious and full of coin flips, I don’t care at all that sometimes it’s capricious for a relatively good reason like giving somebody else a shot. Fine.

I disagree completely that we have to be 100% certain about a problem before we take action. We just have to know that, more likely than not, there is a problem, and take measured, cautious steps to address it. To me it would be an extraordinary, mind-boggling, coincidence if it turned out that the status quo was working perfectly to get the best candidates hired.

Hmm. Without actively taking steps to widen the net and account for those irrelevant attributes, those attributes instead act as the first filter in your hiring process. IMO the process that ignores this is the one that’s not looking for the best developers. In order to make those attributes truly irrelevant we have to correct for the massive, obvious influence they have in human decision making (on both sides of the hiring equation). Accepting the status quo is actually letting those attributes rob you of good hires.

Fwiw, starting in iOS 15, Siri will process speech on-device, which is huge.

Rosa Parks did not act in the heat of the moment when she refused to give up her seat. It was a carefully planned moment with multiple parties involved in the planning, intending to have a specific effect and executed calmly. Being calm was an asset.

I didn’t downvote, but … this is just some claims and assertions with no reason to believe them. It’s fine that you think these things I guess, but it’s not a useful comment cause it’s just speculation and frankly it sounds like you have a chip on your shoulder about previous experiences with inspectors. Are there really “thousand of daily reports” like this, or is that just a feeling you have? Is the threshold of “urgently fix this for safety reasons” too low due to bad incentives? I don’t know, and though you think that, you haven’t backed it up so the comment is low quality and the downvotes are helpful imo.

But it may provide other benefits like helping others & being perceived as an expert, which can lead to paid speaking opportunities, workshops, or even just another thing on your resume to help you appear worth a higher salary next time you look for a job.

Book sales themselves are not where your income comes from as an author, especially in a niche. It’s all the other stuff. If your book sells a lot that’s awesome, but that isn’t a realistic plan.

Web components have been a possible build target for Vue for a while. It seems totally possible to set up a Vue project like you’ve suggested, use all the Vue conventions & tooling, and output web components that you then use a la carte. Maybe I’m missing something about what you are looking for, but more details are here: https://vuejsdevelopers.com/2018/05/21/vue-js-web-component/

And I’m sure the same can be done in other frameworks.

A screenreader user cares if they are navigating between headings and the headings are not actually headings - and it’s always _better_ if the nature and structure of the content is expressed in the HTML so that the screened can announce things correctly. Keyboard users also care a lot about semantic HTML because they are so so many interfaces out there that are not keyboard navigable as divs are used for everything including buttons. So they just can’t reach parts of the interface, or even perceive them.

It’s not about a pristine ideal. Though I’d argue semantic HTML is not only the foundation of good accessibility, it also makes for more readable code because the intention behind the elements is exposed to the next person reading it. It nudges you to do better work because you actually have to understand the nature of what you are building, which means you might see how it reflects an existing pattern that can be copied, not duct tape together a half working tab interface with JS event listeners on divs and spans.

If you see it as just inline CSS, then tailwind can be avoided for all the same reasons that we avoid writing inline CSS. It’s considerably more than inline CSS imo but that’s a different story.

That said, I’m surprised by this:

“Only when you have troubles selecting an element based on its position in your DOM you should choose a classname”

Certainly if you have knowledge of the exact DOM structure in advance, and high confidence that it will never be substantially changed, this is workable. But in many cases, having the CSS care about the DOM structure produces way more pain than the ergonomics of tailwind do. At least in the kind of code I’ve worked on where components are reused all over the place and sometimes rearranged by authors directly in a CMS. Or just having DOM reorganized because something is added that requires an extra wrapper & then all the CSS selectors are nested wrong. Or whatever.

Anyhoo. I don’t love tailwind, but I think it’s fine. Far worse things have happened to web dev. It seems like you have a problem with utility CSS, which tailwind takes to the extreme for sure.

Also, side note - having headings in a figcaption like that seems semantically incorrect.

It does seem like people ought to just think more about the permanence of what we put online and act accordingly. There is no way to guarantee ephemerality for anything you send to another person online. They can always record or whatever in some way. We have to act like this stuff is entered into the permanent record and be OK with that. There is nothing we can do to 100% prevent stuff being recorded somewhere.

I agree we’d all be better off not judged on our younger attempts at “edginess” and stuff we said while figuring out who we are in our teens. But at a certain point we have to accept that posting anything online anywhere is _publishing_ and if you _published_ a racist letter to the editor at 19, instead of said something offensive at a party, there is a different judgement there & it’s justified.

I do think in time the answer “I’ve grown a lot since that time and regret those tweets” is going to become more acceptable & people will be judged more on recent stuff they say and do.

Uh. I mean. I see it. I’m not from here, I just live here. I came from the EU where 20 vacation days was the minimum to a state in the US where no vacation or personal time is required. I’m still blown away by what companies advertise as “generous”.

Maybe calm down with the assumptions and generalizations too though.

They are where I live. The number of sick days required by law is zero.

I mean, there’s an upper bound on how often that can happen (how many personal days people have). Those days are intended to be used at short notice. So if people using them is a problem for the team, imo the team is not correctly matched to the workload.

I do think we often undersize our teams by ignoring the impact of vacation and personal time in taking on work ... but that’s not the fault of the people using the time they are entitled to as part of their compensation.

I’m not against testing APIs. But testing APIs does not tell you if your latest CSS change broke pointer events on your “add to cart” button, so you can no longer receive orders, etc.

If you are wholesale redesigning/rebuilding a whole site and all the workflows yes of course you need new tests. But also your users would get pretty impatient if entire ways of working are changing all the time in a way that makes testing a giant moving target.

The purpose of a UI test in my mind is to make sure that the core business things a user is supposed to be able to do, are doable. In the context of your blog posts, I think those things should be calcified.

Like, I want a test to fail if I remove a workflow that used to be there. I want a test to fail if a form field suddenly has no label. There should be those alerts when functionality that was previously understood to be correct has been changed. Lightweight UI tests with some easily re-approved screenshot diffs goes a long way.

It’s possible (and indeed uh ... recommended) to write frontend tests that are resilient to DOM changes by not depending on things that are not essential to the functionality being tested. Eg select a form field by its label, not by its position in the DOM, and use specific data attributes if there’s no better choice. Then when you gut the HTML for UI overhaul, if the functionality hasn’t changed, the cypress test doesn’t change, you just make sure you attach the attributes to the right new elements.

Of course if the functionality changed (like you split something up into 2 pages) yeah you need to update your UI tests cause you are testing a different experience now. But they are UI tests, so yeah. That’s appropriate.

I dunno. It sounds like you found other parts of it unwieldy as well, but the idea that the tests are inherently brittle is wrong. Time spent maintaining UI based testing is saved many times over when compared with the manual clicking around that it saves imo.