4 ms·

Back at the start of my career I didn’t know how to code, but I got offered a role at a startup after I came up with a solution of integrating google cals in a

Back at the start of my career I didn’t know how to code, but I got offered a role at a startup after I came up with a solution of integrating google cals in a way that was crucial to the business - using Zapier. (The requirements were complex, but Zapier could handle it) This was after the outsourced dev team that built the company website said that it wasn’t possible without significant cost. Here comes me, not knowing how to code, pointing out a solution that cost a few pounds a month. During the next few years I built a ton of other solutions for the company using Zapier, to the point where we were running over 50000 tasks a month, easy. I learned how to code in the process (I now work as a software engineer), but I always consider low-code or no-code solutions when problems arise, because I’ve seen them save massive time and expense in a real world scenario, and working really well. It’s like the OP said in the end - we are problem solvers, and I would add that low-code/no-code tools should be part of your tool chest. Your decision as a problem solver regarding when and how to use them are crucial to whether they work or not - but I wouldn’t dismiss them outright.

ElFitz 4y ago
I often try to do the same thing. But usually end up regretting it. From these experiences, both the successful and the failed ones, come a few gripes against most low-code / no-code tools. To name a few: - Often poor, or completely absent, testability - Often poor, or completely absent, versioning - Conflating “saving” and “deploying to production” - Lack of environments - Often sorely lacking, sometimes poor, debugging tools and visibility - Ridiculous choices (looking at you, Zapier and your absurd handling of JSONs and arrays of objects) - Poor reusability - Poor collaborative features It is my understanding that for some products some improvements have been made on some the aspects I’ve mentioned. But it also feels as if those behind these tools have completely ignored the progress we’ve made in software engineering best practices over the past 20 years.
- roflyear 4y ago
  Often just getting it kind of working is good enough. I don't like these solutions as they don't really give me full ownership of the problem space but I understand why people use them
hanniabu 4y ago
What are low choice options when it comes to serverless functions? For example I make static sites and there's always times when I want to use an API that's either blocked by CORS or requires the use of an API key. But I don't know how to setup a server or how to deploy AWS serverless functions and I really don't have any interest in learning. Anybody have any suggestions?
- ipaddr 4y ago
  hostgator - use php.
- sullivanmatt 4y ago
  I'm working on a product right now that targets this exact use case. I have contact information in my profile, I would love if you would be willing to reach out and just talk to me about your use cases. I already have a day job at a tech company, so I promise I won't try to sell you anything, ever. https://integralcloud.io https://integralcloud.io is the app.
- tlarkworthy 4y ago
  A problem only too familiar to observablehq users, there are quite a few solutions https://observablehq.com/search?query=Cors&onlyOwner=false https://observablehq.com/search?query=Cors&onlyOwner=false
Imagenuity 4y ago
There is also a danger in relying on a third party tool for essential business processes. If the third party tool makes changes and breaks your solution, or gets sold to an unfriendly owner that jacks prices, or decides to sunset their tool — you're screwed.
- dickersnoodle 4y ago
  And the person who established their bona fides integrating that solution wants to preserve the resulting status, so you'll hear some variation of "I don't think that will happen, but let's cross that bridge when later".

ElFitz 4y ago

I often try to do the same thing. But usually end up regretting it. From these experiences, both the successful and the failed ones, come a few gripes against most low-code / no-code tools. To name a few: - Often poor, or completely absent, testability - Often poor, or completely absent, versioning - Conflating “saving” and “deploying to production” - Lack of environments - Often sorely lacking, sometimes poor, debugging tools and visibility - Ridiculous choices (looking at you, Zapier and your absurd handling of JSONs and arrays of objects) - Poor reusability - Poor collaborative features It is my understanding that for some products some improvements have been made on some the aspects I’ve mentioned. But it also feels as if those behind these tools have completely ignored the progress we’ve made in software engineering best practices over the past 20 years.

roflyear 4y ago
Often just getting it kind of working is good enough. I don't like these solutions as they don't really give me full ownership of the problem space but I understand why people use them

hanniabu 4y ago

What are low choice options when it comes to serverless functions? For example I make static sites and there's always times when I want to use an API that's either blocked by CORS or requires the use of an API key. But I don't know how to setup a server or how to deploy AWS serverless functions and I really don't have any interest in learning. Anybody have any suggestions?

ipaddr 4y ago
hostgator - use php.
sullivanmatt 4y ago
I'm working on a product right now that targets this exact use case. I have contact information in my profile, I would love if you would be willing to reach out and just talk to me about your use cases. I already have a day job at a tech company, so I promise I won't try to sell you anything, ever. https://integralcloud.io https://integralcloud.io is the app.
tlarkworthy 4y ago
A problem only too familiar to observablehq users, there are quite a few solutions https://observablehq.com/search?query=Cors&onlyOwner=false https://observablehq.com/search?query=Cors&onlyOwner=false

Imagenuity 4y ago

There is also a danger in relying on a third party tool for essential business processes. If the third party tool makes changes and breaks your solution, or gets sold to an unfriendly owner that jacks prices, or decides to sunset their tool — you're screwed.

dickersnoodle 4y ago
And the person who established their bona fides integrating that solution wants to preserve the resulting status, so you'll hear some variation of "I don't think that will happen, but let's cross that bridge when later".