5 ms·

I’ve been in software long enough to know that there’s a market for products that make things slightly easier for devs and their managers who think even common

I’ve been in software long enough to know that there’s a market for products that make things slightly easier for devs and their managers who think even common APIs like stripe are too hard. The number of devs who are struggling with web hooks and simultaneously have some budget to spend is probably bigger than you think. Often these products are pitched and sold to non-technical managers, too. The sales team will learn that they can make some sales by promising a non-technical manager that buying this product will actually save them money because it’s easier to use.

whizzter 1y ago
Literally describes one company I work for periodically.
skwee357 1y ago
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 1y ago
  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.
  - numpy-thagoras 1y ago
    That describes more than just one POS (Point of Sale) company I know of.
  - gopher_space 1y ago
    Your example is hilarious; it sounds like the team understands analytics just fine if they're solely working towards one metric.
  - datavirtue 1y ago
    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...
- ForHackernews 1y ago
  There's a lot of React devs out there who have never touched a server-side anything.
  - skwee357 1y ago
    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.
    - anon291 1y ago
      It's really not hard to be good at both. Or at least to understand enough to be fluent in both.
    - withinboredom 1y ago
      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 1y ago
        If I claimed to be a generalist, would HR understand what I mean?
- nrhrjrjrjtntbt 1y ago
  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 1y ago
    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 1y ago
  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).
agreeahmed 1y ago
Definitely - it's the nature of software that it tends towards higher order abstractions that make the tools easier and easier to use. The final frontier is English as a programming language. The tools that are easiest to program in English (via a coding agent that "compiles down" your prompt into code) tend to have the tersest APIs, with the least amount of reasoning about state across service boundaries. It's very likely at this point that the supermajority of future programmers will have almost no formal computer science education. They'll want tools that don't require a deep understanding of the prior generations' layer of abstraction. That's kinda the world we're preparing for - builders who don't need to be deeply technically involved in the details of their vendors in order to build successful software companies

whizzter 1y ago

Literally describes one company I work for periodically.

skwee357 1y ago

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 1y ago
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.
- numpy-thagoras 1y ago
  That describes more than just one POS (Point of Sale) company I know of.
- gopher_space 1y ago
  Your example is hilarious; it sounds like the team understands analytics just fine if they're solely working towards one metric.
- datavirtue 1y ago
  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...
ForHackernews 1y ago
There's a lot of React devs out there who have never touched a server-side anything.
- skwee357 1y ago
  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.
  - anon291 1y ago
    It's really not hard to be good at both. Or at least to understand enough to be fluent in both.
  - withinboredom 1y ago
    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 1y ago
      If I claimed to be a generalist, would HR understand what I mean?
nrhrjrjrjtntbt 1y ago
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 1y ago
  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 1y ago
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).

agreeahmed 1y ago

Definitely - it's the nature of software that it tends towards higher order abstractions that make the tools easier and easier to use. The final frontier is English as a programming language. The tools that are easiest to program in English (via a coding agent that "compiles down" your prompt into code) tend to have the tersest APIs, with the least amount of reasoning about state across service boundaries. It's very likely at this point that the supermajority of future programmers will have almost no formal computer science education. They'll want tools that don't require a deep understanding of the prior generations' layer of abstraction. That's kinda the world we're preparing for - builders who don't need to be deeply technically involved in the details of their vendors in order to build successful software companies