If you can cope with instructing work-to-rule workers, you can code. No extraordinary smarts required.
As of "much smarter than above average programmer", programmers in average are at IQ 115. If we take "above average" as +15 points (IQ's standard deviation) and "much smarter" as another +30 points, we end at 160 IQ points person. Four standard deviations make that person one in roughly 16 000, or sixteen thousands. I think you should know a lot of people, much more than 150 or so of average person, to know many of them.
And to offer you my experience, my brother seems not to have any problems with coding in Python. He is well into 40-s, most of his career he was at the C*O positions and right now he decided to change venues one more time.
Nice example that if you define the terms to suit your argument then you can make any argument. Also, the word 'smart' has much wider scope than just IQ. It is also possible that the people OP knows are not sampled randomly from general population (he might be in a chess club for example).
Personally as a coder I have workflows, tool-chains developed over several years that writing a code to create a MVP is faster than learning no-code tools, also the end product is lean and stays with me.
So I haven't used these tools but tried notion for the first time yesterday to export my kindle highlights(HN comments)[1], So I can see the value in these no-code tools in automation workflows for even coders.
[1] https://twitter.com/Abishek_Muthian/status/14199150634906050...
Sounds to me like a generally applicable thing to be honest. Even as a programmer I can't just pick up my favorite language and use it for any type of software. There is mature/user-friendly infrastructure and libraries for X/Y targeting Z, for a limited set of permutations.
IMO Bubble is only ms-paint+ (entry point lowcode) and Photoshop (or Figma) is yet to hit the market.
I'd argue, no.
Bubble will not provide good handmade applications in the vast majority of cases.
His QC simulation code in matlab would write the output of each iteration to a file because he didn’t optimize the object sizes. A simulation that should take an hour now takes 20 lol. It’s probably like in the Sherlock show how Holmes says he doesn’t want to waste neurons memorizing constellations.
More, they weren't even aware that these things could be improved. So no, I'm not convinced life science is intrinsically harder or the people there smarter. I attended some biochem and genetics classes at uni and once you have the foundations the concepts are actually pretty simple, there's just a lot of new terminology and random facts to memorize.
Often there are multidisciplinary research teams and depending on how little a specialization already overlaps with CS/SE-ish topics, having at least someone who realizes which mundane stuff can be automated can be invaluable.
Let me guess, you are one of the brilliant ones.
I've met some dim people in science research tracks.
Our microscope acquisition code is a single 25k LOC C file.
That's not really proving your point about them being "smarter than any developer". Lots of developers are smart enough to build their own tools.
I believe no-code is incredibly underrated by many early stage startups. Rewrite only once you found your PMF and there's a real performance issue (or other technical reason), just you like you did.
One of the best thing about no-code is that you avoid painful, timewasting continuous refactoring while trying to iterate on your products the first months. It's much easier to design & structure the code to be as close as possible to the business (DDD-style) when you write it from scratch after reaching PMF.
Being able to iterate fast early on is such an important part of startups. I think code is not great at this.
I'm guessing many people would get this right up until the last step and see how much juice they could squeeze out of the prototype which I would imagine could be fatal in many cases.
I still wouldn't suggest this route for anyone.
Can you say more about these problems? I'm curious what they're like in practice, if/how companies using Bubble can work around them, and whether Bubble might be able to fix these kinds of issues in the future.
The hard bit I think is the "spaghetti no-code" problem that I've seen in nearly all visual-type programing environments. Just because it's no code, all of the logic still needs to exist somewhere. When we code we can break it apart in many ways, and how you break things apart and abstract things depends on the system.
But no-code tools are fixed, and you only have one way to divide up the logic. In Bubble's case, it means there's a "design" section with UI and data-binding, and a "workflow" section with all of the actions that happen: UI interactions and business logic are smooshed in together. You end up with thousands of boxes indicating actions, in a giant list. You can kind of group them, and you can colourize them - but everything is held together by convention. A single logical flow can require many UI elements, and tracking that logical flow through the various unrelated boxes is... spaghetti!
In Structure and Interpretation of Computer Programs it says "Every powerful language has three mechanisms for [combining simple ideas to form more complex ideas]: * primitive expressions, which represent the simplest entities the language is concerned with, * means of combination, by which compound elements are built from simpler ones, and * means of abstraction, by which compound elements can be named and manipulated as units."
Most of the no-code tools seem to miss (or have a too simple version of) the final mechanism: "means of abstraction". So the entire system is built of combinations, that are poorly tied together.
Switching off the no-code version was a happy day. We'd pushed it further than it was designed to go. The initial advantages of quick prototyping slowed down, and it was getting harder (very hard) to add new features without breaking old ones. Customizing the design (to our designer's high standards!) was... tough.
The coded version was better in every way - but part of that was because we learned a lot from the prototype. I personally probably wouldn't start a fresh project with it - but I would recommended it to (technical) non-programmers who want to get an idea out of their head to see if it's any good.
I joined a startup that didn't have any deep coding skills - but had a great idea and vision for a product. They had made a pretty decent prototype with Bubble and could quickly implement suggestions from the beta testers.
When I joined I instantly suggested re-writing it in a "real" stack. But when I dived into it, there was a lot of built in features of Bubble they were using that would be a pain to write or integrate. The rewrite would take some time.
Instead we launched with the Bubble app as it was. It targeted a niche market, and that market came flooding in - it really proved there was demand for the product and the feedback helped shape the end result - months ahead of where would have been if I re-wrote it.
But as the app grew we ended up with "spaghetti no-code", slow loading times, crazy hacks, giant bundles (that we had no control over)... but again, it was good enough to launch with and validate the company, and it was fast to try out ideas.
We eventually did a full rewrite once we were happy with the overall structure of the app, but the process changed my perspective on the value of no-code tools in the right hands.