mooreds

I think they just verified the blog posts as standard.site records. https://standard.site/

Here's a Japanese case study from 2007: https://econ--review-ier-hit--u-ac-jp.translate.goog/all-iss...

> To conclude, the company was able to specify who was dismissed but was unable to specify who took buyouts despite efforts to ensure retention of value employees, including careful setting of incentive schemes. The case presented in this paper demonstrates that employment adjustment using a buyout framework invites "adverse selection" despite careful employer precautions.

Here's the full PDF: https://econ-review.ier.hit-u.ac.jp/wp-content/uploads/files... (not sure how to translate that)

> You should be more concerned about what comes next.

I always wonder about that with buy-outs. Seems to me that the people who take buyouts are either:

- those who are close to retirement

- those who have other options

I'd assume the first vary in quality the same as your overall workforce, but I'd assume the second would, all other things equal, be better than the average.

Maybe I'm wrong, but it seems like by offering an optional buyout, you'd degrade the overall quality of your workforce. Wonder if there are any case studies about that?

> Come back? I never left!

I thought the same thing.

Fun retro ad, but probably won't speak to anyone born after 1990.

> In reality though it's really hard to make these things true.

Yeah, the best example I saw of this was:

   * a small company (under 50 employees)

   * a very deliberate values gathering process across all the employees, not just senior leaders

   * performance reviews and spot bonuses tied to values sightings

   * regular review of how the values fit with current efforts

Just like anything else with a group of people, it takes a lot of work to get it right. Inertia is powerful.

Jabber would like a word: https://jabber.org/

But seriously, there's zero incentive for the folks building these clients to make them interoperable. In fact there may even be disincentive, since the more folks they have on their platform, the more valuable the platform is.

You are accountable.

You're going to have to understand it one way or another, either at writing or at debugging. Even if you delegate all debugging to AI, you'll still need to determine what is "right".

If you don't understand the code at writing or debugging, you'll pay the architectural price (where it degrades). That price may be worth paying, but that depends on the system you are building.

Cool! You might be interested in this podcast with the CEO of the company behind Quint (that's how I heard about it):

https://maintainable.fm/episodes/gabriela-moreira-when-800-t...

Good point! Tech writers, and writers in general, were impacted before developers.

Maybe visual artists/photographers were impacted before then?

Anyone have a timeline of this stuff?

> Today, the mathematicians are weeping, because the machine smashed their tower first.

I read this passage and thought, "has Derek even talked to software developers"?

That feels to me like the first discipline to go through this, where their daily activities are massively changed by GenAI.

From https://news.ycombinator.com/newsfaq.html

> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.

In my experience, if a story gets 4-5 points and < 5 comments, it hasn't gotten "significant attention" and a repost gets a second chance. That's not data, just anecdote.

> Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account.

We rolled out passkeys a couple of years ago (I work for an auth/CIAM provider). This was before most passkeys were synced (which gives me the heebie jeebies--that's a valuable set of private keys to be shipping around).

We built passkeys to be an alternate login method, not a primary one, for that exact reason.

You can do certain things outside of the eyes of investors and the demands of the quarterly earning calls. Things like radically cutting costs (ie people) but more importantly, revising the business model.

I submitted it, then did a search for the domain. Noticed that there was discussion on a previous submission, thought that was worth pointing out. ChrisArchitect is pretty good at this, but sometimes I do it myself.

I forgot to do a search first.

Submitted here: https://news.ycombinator.com/item?id=50070918

On that topic, I enjoyed this romp through geologic history using CO2 as the lens:

The Story of CO2 Is the Story of Everything - https://www.penguin.co.uk/books/455255/the-story-of-co2-is-t...

Here's the amicus brief: https://www.supremecourt.gov/DocketPDF/22/22-293/242292/2022...

Title should actually be "Do you have pre-2014 Onion issues?"

Because they are looking for issues in 2012 and 2013 as well.

Should have posted the direct link with more details about what they are looking for and how to help.

That's here: https://theonion.com/archivehunt/

Oooh, I like this idea. Kind of a honeypot?

FusionAuth | Principal Software Engineer, Senior Java Engineers, Account Executive, Customer Support Manager | Varies between REMOTE (in USA, also in Europe but only for the account exec position) and ONSITE in Denver, CO, USA, details in each job desc | Salary ranges for the Principal Software Engineer it is 225k-270k, but the Euro positions don't have them :(

At FusionAuth, our mission is to make authentication and authorization simple and secure for every developer building web and mobile applications. We want devs to stop worrying about auth and focus on building something awesome.

There are a lot of companies in the auth space, but we feel like we have something special:

* a relatively unique deployment model (self-host on-prem, run in your cloud or let us operate it for you in ours)

* A well designed API first approach; one customer compared our APIs to petrichor

* a mature product (the code base is nine+ years old and we've found and fixed a lot of the sharp edges around core login use cases; but don't worry, there are plenty more features to add)

* a full featured free-as-in-beer version which makes the sales cycle easier; prospects often come in having prototyped an integration

Our core software is commercial. We open source much of our supporting infrastructure. Technologies and standards that you will work with: modern Java, PostgreSQL, Docker, Kubernetes, MySQL, OAuth, SAML, OIDC.

Learn more, including benefits and salaries, and apply here: https://fusionauth.io/careers/ ( Click/tap the 'View open positions' orange button. )

Small tech companies (mix of product and consulting) primarily in Colorado, USA.

I would not say the hiring has been highly competitive (certainly not FAANG level) but the number of jobs are low because they are small. The tech was not cutting edge.

Could be luck?

FYI, $curjob is hiring: https://fusionauth.applytojob.com/apply

Anonymous credentials seem neat! I think there's also some interesting work going on with AAuth[0] and SPIFFE[1]

The issue is less in the identity of the agent and more in that:

1. We need to get users and companies used to issuing and using these credentials.

2. The systems agents are interacting with need to recognize these credentials.

3. Critically, the systems need to be able to limit the actions of the credential holders.

The last one, #3, is probably the doozie because it requires all kinds of rethinking of authorization models. Which tend to be baked into applications and tied to business logic.

0: https://www.aauth.dev/

1: https://spiffe.io/

I agree. Finding the time to update docs, processes and code based on a post-mortem is, from my experience, the hardest part. Critical, but difficult.

Do the actionable items usually get implemented?

That feels like a tough place to work. I would worry about burnout and churning employees if I didn't work at a place that tried to improve every day.

Maybe I'm a bit of a pollyana, but most places I worked had folks who cared and wanted to improve things.

Hmmm. That's an understandable perspective, but I don't think that splitting things up between product and engineering is of much benefit or interest to the end user.

I wrote a post a while ago about how to be a good audience member at a tech conference: https://www.mooreds.com/wordpress/archives/3522

tl;dr: even if you don't tell a speaker you like their talk, definitely pay attention. Or leave. People work hard on this stuff!

Reminds me of folks who built "load-bearing" applications using Microsoft access.

Or, go slower?