I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe.

I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.

▲

withinboredom 6 hours ago | parent | next [-]

I had the pleasure of working with teams that couldn’t even figure out how to use analytics in their product. They had zero idea who was using it and how many people were using it. They ignored the thousands of DB deadlock messages in the logs; well, they just ignored the logs completely, actually. All they cared about was shipping the next feature and getting the one QA guy to agree it was working correctly so the ticket could be closed.

This is much more common than you might think.

	▲	gopher_space 3 hours ago \| parent \| next [-]
		Your example is hilarious; it sounds like the team understands analytics just fine if they're solely working towards one metric.
	▲	numpy-thagoras 4 hours ago \| parent \| prev \| next [-]
		That describes more than just one POS (Point of Sale) company I know of.
	▲	datavirtue 2 hours ago \| parent \| prev [-]
		This is the default. I have a few teams like this under my charge, currently. I ask them to protect themselves by logging what data they will need to troubleshoot a new feature. Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs. It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit. Days long anxiety-filled shit storms for absolutely no reason. I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...

▲

nrhrjrjrjtntbt 5 hours ago | parent | prev | next [-]

Webhooks are not a struggle conceptually. They are a struggle operationally IMO.

In amy case why does a dev need to understand a (yet another) poor DX complex API (stripe) in addition to the other 20 they need to deal with. What is wrong with taking something off the plate. It is like daying dont use high level languages, use Rust, don't use a library to make http calls roll your own etc.

	▲	skwee357 5 hours ago \| parent [-]
		I think Stipe is one of the best designed APIs I ever had to work with. But to reply to your point, there is no way out of this. You either understand the tools you work with, or you end up vendor locked to tools like vercel/next (the target audience of OPs tool, as it seems), which promise simplification, but end up being their own monsters.

▲

WilcoKruijer 4 hours ago | parent | prev | next [-]

Even the best developer in the world can struggle when there are like 250 webhook events on a platform (as is the case for Stripe).

▲

ForHackernews 5 hours ago | parent | prev [-]

There's a lot of React devs out there who have never touched a server-side anything.

▲

skwee357 5 hours ago | parent | next [-]

I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.

▲

9dev 3 hours ago | parent | next [-]

To the contrary, I feel the distinction to be very arbitrary and especially in the context of web applications so muddy it’s almost useless. Who is responsible for websockets? CSP? JavaScript chunk caching? Web worker edge deployment? File uploads? HTTP/2 stream usage?

The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.

▲

withinboredom 4 hours ago | parent | prev | next [-]

There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and started putting “full-stack” on their CVs even when their experience only covered a slice of the stack. Bootcamps and junior developers adopted the term too, and hiring managers kept accepting it because the candidates were otherwise solid.

Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.

It’s a sad world.

-- actual (retired) full-stack engineer

	▲	koakuma-chan 4 hours ago \| parent [-]
		If I claimed to be a generalist, would HR understand what I mean?

▲

anon291 5 hours ago | parent | prev [-]

It's really not hard to be good at both. Or at least to understand enough to be fluent in both.

▲

agreeahmed 3 hours ago | parent | prev [-]

As the Javascript ecosystem has spilled out from just the frontend to also the backend, a lot of these React devs have found fullstack responsibilities on their shoulders.

Imo you can trace a lot of how devtools, particularly webdev tools, have evolved to this. They are more React-brained. Specifically they try to take state management responsibilities off their users' plates.