jbmsf

I get it, but this is also, frankly, terrible. I should not be required to store your identifiers in my system in case order to login users.

I've always felt that email+email_verified would make much more sense.

I don't actually care about the email address being a unique person, just that they have access to it.

100%.

Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure.

I get it, of course, it'd be lovely if these complications didn't exist and the same framework handled everything... but I don't think a programming language or even a runtime gets you there. You also need monitoring and ops processes to be part of the solution.

I built one of the first location aggregation systems. Maybe the first, hard to be sure. My company had close relationships with all of the US cellular companies and built white label apps for them, mostly under the auspices of family safety (though many users were more concerned about the location of their partners than of their kids).

Around the same time OAuth 1a came out and it seemed like a great ideal to offer a platform that leveraged these relationships to sell location to app developers, subject to consent and with a bunch of features to protect privacy.

In the end, we had one app developer who was even remotely successful and the less privacy-focused aggregators partnered with the next generation of app developers and the product had no future.

Nostalgia is fun.

Neat idea. Looking forward to support for more integrations.

Thank you for not having the obvious and boring take. (I also agree.)

I get it, but I want to use SQL. It's a lingua franca and has a lot of power for writing migrations that I'd rather use than inventing my own.

That said, it's awesome to hear from someone using jsonb with migrations. Most places I've seen using jsonb push responsibility for handling different schemas onto the application, which <shudder>.

I want a few things for database support libraries:

- Elimination of boilerplate to load data from a table into a type - A reasonable query mechanism that avoids SQL injection - A migration tool

Every ORM I've used solves the first problem (for which I'm grateful). Some do the others. Most do way too much more.

I still use an ORM in every non-trivial project because I don't want to do these things by hand. But it could be much better.

It's hard to convince the people with the power and money that they should get out of the way. If you're lucky, they are mostly unaffected by the structures of power and believe in "servant leadership". If you're unlucky, well, good luck.

I don't think you can make an existing company change it's stripes; you can only start a new one that believes in collective power and try to find a way to make that stick.

Maybe B Corps help? At least you can prioritize something other than maximizing shareholder value. But even then, I'm not sure how you deal with bad actors without some degree of strong power.

They exist - I am one - but it doesn't work unless your leadership wants someone who doesn't fit in existing hierarchies. I tend to consult and if I go somewhere where I have prior relationships with leadership, it works. If not, I get treated as part of someone's narrow reporting chain and all the incentives are wrong.

I consult as a software architect and my job is mostly the opposite of this: asking people what problem they are trying to solve and why they haven't considered $EXISTING_SOLUTION

I can fathom it: the larger the organization, the more important it is to the people with power to treat everything else as abstraction.

I'm told Seeing Like a State shares this insight.

I also hate it. But it's unfortunately "left as exercise for the reader" to come up with an alternative that concentrates power differently.

That does sound frustrating, but I think you are conflating naive management practices with inclusive hiring.

Fair, but:

- The companies that make an effort get a lot closer to population baselines than the ones that just give up.

- Organizational pressures are something leadership and management should be steering. I'd rather have hiring practices be an explicit choice than something that "just happens"

Sure, but if you are lucky enough to have an entire team of interviewers who have this much experience, you're probably not having the same hiring conversation that's happening in this thread.

Are you trolling now?

People tend to substitute their biases when evaluating skills and knowledge. Some people overcome these biases through practice but everyone has them.

It's 2023, this is not new territory.

I'm sure that sounded smart when you wrote it.

An inclusive interviewing process does not mean that you hire everyone. It means you reduce the weight of people's biases as part of identifying who you hire (because people turn out to be quite bad at prediction in hiring).

I agree with the conclusions, though I've seen the structured part go wrong, e.g. the interviewer is so dedicated to following the structure of the process that they forget about the empathetic part. These interviews look more like scripts than exploration of a candidate.

So I'd add another criteria: interviewers need to be trained!

I heard a fascinating idea somewhere... hang out while you are in mid-sentence.

IMO, you need multiple models. The product model (or the "this team owns X" model) force a commitment to an area of work that doesn't always align with business needs. The project model is terrific for aligning people across skill sets, but doesn't do as well for ongoing work and tends to push staff from project to project (vs building deep experience), which can work well for generalists but not for everyone.

I see the actual problem being that management is rarely simultaneously deep enough and strong enough to make the right choices around work organization so everything just defaults into hierarchies.

Not just that, but few people have both the depth to recognize competency and the breadth to know which competent people are key.

In practice, most places I've been have a few people who are "obviously" key and then a lot of ambiguity.

The processes designed to enable competition (vs an official just hiring their cousin) become so cumbersome only a small number of organizations can take part.

> All of these companies have huge, mission critical reasons not to use AWS/Azure/GCP and invest in K8s.

Very true. The problems occur when smaller companies without these mission critical reasons make the same choices because the others are making them.

re: advisable

If and only if your business model depends on it. A startup's job is mostly to find product market fit; if being decoupled from AWS isn't part of your market, you are spending money on a non-problem.

I was recently involved in evaluating a no-code UI toolkit. It did what it said it would, but did not (could not) solve certain key business logic problems (mostly related to domain-specific authorization).

When we told people: we're happy for you to use this tool as long as you also write as something else that solves this necessary business problem, it took a lot of wind out of the sails.

The hard stuff is still hard.

The same is true in reverse. If your team assumes they need the optionality of avoiding cloud lock-in, your CTO had better have made an explicit choice to pay the overhead of not using these cloud services.

Sure, you can play FUD games about AWS suddenly raising prices, but I doubt you'd have any historical evidence to back that up. So you'd better be able to say why being cloud-agnostic is critical to your business.

I don't agree. I've used other CI platforms that get UX a lot more right.

I love Tailscale and it's true that I am not suffering from stability problems with its database choices.

But, I do have challenges working with their ACL structure -- which is backed by their database -- and specifically would love to be able to update users/groups separately from tag groups and both of those separately from ACL rules and I can't help but wonder if the fact that this feature doesn't exist relates to the fact that the database doesn't normalize these concepts into separate "tables" separated by "foreign keys".

I've been working part-time for the last few years. I generally work a full week, but split my time between two companies. It seems to work; neither company would have been able to hire me full time either because they can't offer me enough stake, interesting enough work, or have too much of the sort of dysfunction that only a large stake or interesting work justify tolerating.

I can't pretend it was easy to make happen. I have a long career behind me and found positions mostly through my own network. (I have found a few companies that were willing to hire part time via traditional recruiting channels, but it's a minority.)

My spouse is a PT and hates her software. I get the sense that she also has an above average appreciation for the needs of the admin staff. They quote literally make the difference between a good day and a bad one by the choices they make around scheduling.

The problem is that she works for a large chain and the people with purchasing power are not clinicians.