Is it satire because many of the buttons and links don't work so you can't actually finish anything?

If it’s serious, I doubt it provides much real value. Developer experience is built on accomplishing actual tasks, not the surrounding administration and ceremony. Aspiring devs should probably work on personal/toy projects or open source.

That said, it looks great—well done!

The outstanding task of "Implement OAuth" being overdue nearly a year hits too close to home.

Whats good about OAuth if you dont require Authorization though? Most apps I know of mostly only need Authentication. Never implemented it myself so I really want to know

Often when people ask for Oauth they really mean OAuth2/OIDC, and what they really want is managed authentication, with further authorisation being managed at the application level rather than through oauth.

The advantages are there:

1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers.

2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service.

3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization.

4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.

So for the sake of simplicity devs offload authentication to some 3rd party provider? Oauth/2 is for authorization though, i dont get where the authentication part comes from. They even write it is an authorization protocol.

OIDC describes itself as: "OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework".

So Oauth2/OIDC is what you typically want?

I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.

Why though? Why are devs so afraid of auth?

I'm not afraid, I just don't understand the nuances well enough.

But it's also easy to understand what there is to be scared about:

1. Security critical.

2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. )

3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation.

It's not an area you can "fake it 'til you make it" or "move fast and break things" with.

Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.

So how are hobbyists handling auth in their hobby projects? I am sure they cant commit to using OIDC if its that difficult to implement? This is something I try to understand since almost 2 years... Are they just using jwts?

This.

At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.

Maybe I'm zooming in too much on semantics here, but I have a hard time imagining an application that needs authn, but not authz. Even editing your own preferences requires authz, as other people shouldn't be able to do that.

In any company of any non-trivial size, and even many smaller ones, authorization is a big deal that tends to permeate all the systems. For example you don’t want most staff to be able to log into the payroll system and change salaries. But they can log in and look at their own records. That behavior requires authorization either way.

If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.

It's the other way around, if you don't need authorisation, why would you need authentication?

To identify a user and grant them access to their own data

The "their own" part of your statement is what some (many?) consider to be in the authorization domain.

Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party.

Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical.

On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated.

Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.

"Granting access to data" is what authorisation is.

> That said, it looks great—well done!

All they did was generate it with https://lovable.dev

That's why basically nothing works.

Oh wow. So you can put in a prompt, get a mockup of an app and get to the front page of HN with that now?

The idea-execution value gap is shrinking.

I didn't see 100 emails or supervisor interruptions buttons.

Love it.

Also needs to simulate getting responsibility without authority, with weekly meetings to follow up on your progress.

Great feedback. Others can learn from you

I was hoping for satire but this seems to be earnest attempt at something.

From a "dashboard" point of view it's not bad for giving an overview of the state of things on a team project, but at the same time the main question in my head is: "Why not just work on an open source project?". That would give you experience, _and_ (hopefully) contribute to the improvement of something.

I question the experience of anyone interacting solely with AI to learn what it's like to work with others on a project.

> earnest attempt at something

that's what makes it even funnier

Nice idea but it lacks context and that is the most important part of being a software engineer. We write code to solve problems for a user/business/etc.

This is something that a company called Wilco were trying to solve. I thought they went under a year or so back but a quick google implies they are still around.

As a developer that looks horrible but if I was running a bodyshop I would probably love this.

Just plug-in people to whatever codebase.

If I was VC I would probably immediately fund this.

”The human adapter”. As technology develops AI agents could be plugged in to replace human workers for suitable tasks.

Go seek funding now :)

Looks sleek but I don’t get the premise. Why not let people just work on a real (open-source) project instead?

The way open-source projects tend to run is quite different from the typical corporate dev experience.

Was thinking the exact same thing - build real world real experience, and learn how to deal with other humans, perhaps with different goals than yours, at the same time.

Tech and the stuff around it is just one small dimension of the software engineering space.

"Next Step" after Start Development Server doesn't work

Unsure what to do in Git workflow practice page, maybe some code didn't work for me? i can press "practice" or "visualisation" toggle but nothing happens

The AI mentor keeps saying "I understand you're interested in learning about that. Let me help you break it down and suggest some resources."

The whole thing feels like an incomplete placeholder? From your message, that's probably the intention to share it earlier, but people may expect more of it to be working...

I kinda get the idea though, could potentially lead somewhere, for example an actual onboarding step for a new role, or preparing for an entry level role before you start interviewing. The steps does give a hint to my experience as a SWE, at least.

Where's the coworker who interrupts your flow every 10 minutes?

Presumably this would be Jane, who felt the need to comment on the OAuth ticket:

> Make sure to follow the security best practices

Thanks Jane! Appreciate the input, don't you have your own work to do?

This is lo-key brilliant. It could be a meta Stanley Parable both in its soul crushing despair and pointless meaningless existence.

Keep up the great work!!

If I squint, I see a real product: living onboarding.

We've taken steps towards organizing our company dev knowledge by diataxis.fr (see the excellent Tailscale docs for a fleshed out example, whether purposeful or not), but the very first page of this gives the best docs overlay I've seen for one's first days at a new firm.

We'll likely reframe our onboarding around these layouts, where the detail is drawn from current work in the new hire's area, wrapped with references into docs, from how to set up one's dev env to how to write up a PR or pair on code review.

I see a lot of negativity in the comments but I think there is potentially some value in this, if I'm understanding it correctly. Some people (me) find the procedural parts of a job that you cannot prepare for in advance the most overwhelming aspect - moreso than any actual programming.

That being said, there isn't enough here to get any real idea of what it offers. Getting feedback early is good but this is too early.

>const login = async (email, password) => { // Implementation }

For real, are you guys are redoing the auth implementation for every project?

Love it! Is the code available by chance?

Make it into a game