As a pragmatic software engineer: same. The code by default era can’t end soon enough, we shouldn’t be carrying the burden of our own inferior versions of things that already exist. A decade from now we will look back on the amount of code written now as a puzzling artifact of the past.

Code when a ceiling has been reached with existing tools is the future — a ceiling which is getting higher and higher, thanks to Retool etc.

Indeed. I'd rather put my energy into solving unique business problems, rather than wiring up another standard table, form, or chart.

Why are the only options residing yourself to vendor lock-in or developing everything from scratch? There are plenty of open source tools, components, libraries, etc that can be used to speed up the pace of development without having a situation where you’re at the whim of your vendor because you’re unable to export your work into another form. I love the idea of creating tools that allow less technical people to build software or technical people to build software faster - but why can’t those tools be ones that allow you to export the final product into a universal format?

As someone who has built software since 1999 across a variety of platforms, open and closed source, the amount of boilerplate you have to write to create the most common objects is still astounding, no matter how many open source libraries I pull in. (often the more you use, the worst it gets)

Also "vendor lock-in" occurs in open source. Most code that gets written day-to-day is written by developers who are not qualified to work on the underlying libraries they depend on. We are locked into our server frameworks, our database engines, our front-end frameworks, our authentication library, etc.

I feel like “vendor lock-in” is fundamentally different when you’re (a) not paying for the underlying libraries and don’t have to worry about future price hikes (b) can edit and modify the underlying source code to suit your needs.

It also seems like you and I are having very different experiences with how much boilerplate we need to write to get simple programs working. In streamlit[1] for example you can get a dashboard up and running in minutes.

[1] https://streamlit.io/

> we shouldn’t be carrying the burden of our own inferior versions of things that already exist

Why would people building software today need to do that? There are excellent, “batteries included” polished versions of plenty of the things we need to build software: package managers, developer tools, machine learning libraries with the latest algorithms, testing & CI/CD tooling, UI components, web servers, databases, etc. There’s even entire applications that are FOSS, if you want to build a new tool there’s nothing stopping you from adding whatever you want to a pre built FOSS application like LibreOffice, Calibre, etc.

Well said. Somewhat related and on front page of HN right now:

https://www.worklife.news/talent/developers-are-burned-out-q...

>bullish each day on low-code tooling

we use Microsoft PowerApps.

i see it differently. if you build too much internal software/tools on PowerApps. your company is tied to Microsoft for a long term since there is no easy way to jump from PowerApps to another low code platform without redo.

So?

Vendor lock-in is just the price of using a vendor, and one which is often overwhelmingly worth paying. What you are saying is true, but it's not really enough of a detraction to justify building everything in-house.

From the other side I can't imagine using no-code and inhering that tech debt when the equivalent software can be written by 1 skilled SWE in a day(ish), is it really cheaper than about 10 quality manhours (~$5k)?

If you’ve ever worked in the real world, you’d know that the technical debt produced by developers who think they can build no-code alternatives in 10 hours is far worse than any technical debt these tools could produce.

10% of the code we write produces 90% of the value: retool etc. allow us to spend much less time on the 90% of code that isn’t valuable to the businesses we work for.

I disagree. I've been cranking out CRUD APIs with libraries in very little time. If something gets too complex you toss it away and maybe keep just the data model

What retool offers is a nice UI on top of CRUD apps

Cool, but I lived without it for my entire career (and I thought of building something like retool for about as long)

Are we living on the same planet? "a day"? "$500/hour"?

Was a little tongue in cheek, but we're talking CRUD not complex systems; modern tooling has dramatically expedited the speed at which we can churn out such things, I see no reason to drag it out unnecessarily.

Not bashing retool ofc, I think it's a great product for tech sectors that don't have access to top SWEs.

It's the equivalent of Microsoft Access but on the cloud. Each has its pros and cons. (vendor lock-in, cloud integrations, code customization, etc..)

I don't think there is any novelty here except for it being on the cloud. I also don't think this a no-code platform.

Bingo. The surface level value prop of these tools are: enable your ops staff to create/manage biz processes. The underlying value prop is: don't spend expensive dev time creating internal tools.