Can my experience with building "no code" applications be translated into something that will impress hard core coders?

Your skills would be most useful if you were starting your own startup and needed to make an early prototype to show to investors or potential cofounder developers.

Your experience in debugging, testing, and agile, could help you get a job as a product manager, and the fact that you have a background in some sort of 'coding' will help too. It's very unlikely that it would help you get an actual dev job though, since you wouldn't be able to translate your programs into actual code that could be taken over/continued by other devs. Even if the programs you mentioned do allow you to export as code, it's unlikely that it would be exported in a way that's very usable by other devs.

I think you'll really struggle. Despite my title I still spend a lot of spare time coding, attending and speaking at tech events and was a coder for 30 years. I have also worked in product ownership roles too. The reality is that not only will you struggle to convince coders, you'll turn them against you because you use what the industry often regards as "Doodleware". It's the same attitude that buffets tools such as TIBCO AE, WSO2, NeuronESB etc.

You have to understand some of the key aspects of the mindset. Despite the very intellectual nature of the role, many software developers are extremely irrational, short sighted and a lot dimmer than the role and the reward's they're paid would have us believe. Many see their roles as crafts and as someone who tried to push the industry into true engineering lines some 20 years ago, trying something genuinely new, but too far outside one's natural paradigms, as a cohort, doesn't go down well at all, even from within it's own ranks. It's taken that long for some of the concepts I was talking about back then to start to permeate software development today. They're human after all and have very much the same concerns every other human has, but also with a unhealthy dose of prejudice to go with it.

Taking ESB's like the above as a part of an example. Many ESB's have build in routing and workflow configuration tools and have a sweet spot where their delivered value overtakes direct connections, including those of [badly engineered?] microservice architectures. This is due to the combinatorial complexity (or rather the explosion) of such connections, make change more cumbersome the bigger it gets, since they have to change up to O(n-1) connections to other services. By comparison, ESB solutions with workflow designers can make such changes in O(1) - There is no growth to that complexity. Configure a single new transformation and go. Similarly, workflow design is just reroute, and publish. That said, even here, aspects of Test Driven Development/Behaviour Driven Development are still necessary.

From a product owner's perspective, this carries unbelievable value, since it lowers the skill bar required to participate in the change (so QA's, designers, BA's and even product owners themselves can do to) making ongoing change substantially faster, easier, less risky and 'multi-skills' everyone as good as overnight. Otherwise to reduce the "Bus factor" risk alone, they'd have to find and recruit people with that skillset, taking time and money and for niche tools, this carries a high probability of failure and high cost in wages or contract rates. Having a workflow or configuration tool to do the job ups productivity massively. If you have developers who truly mean they deliver valuable software, they'll understand that's value. However, with all due respect to my colleagues in the industry, many say it, but don't mean it or understand it.

This sort of tool is a direct attack on revenue streams and someone's livelihood, though that will never be admitted. So you have to be mindful of that. I go through challenging conversations all the time, with both sides of the divide, mainly because I am almost "allergic" to waste. I have no issue having such conversations when needed and the same process happens.

1. Tool is touted as a solution by managerial teams
2. One developer is chosen to try it out (note, foisted upon them)
3. Developer begrudgingly uses it, doesn't get the wider benefits, presents an argument either to dismiss it or accept it "passive-aggressively"
4. Product owner, Manager, EA or whomever mandates use of the tool, effectively taking credit for the devs work
5. Devs use it, hate it, don't use (or attempt to use) it effectively, and it gets a groupthink of frustration
6. Tool is rejected

The answer is usually to allow developers to come to the conclusions themselves. There is almost no way of doing it otherwise. It almost certainly means your skillset won't be valued and in some case, it'll be laughed at.

As an example, ESB's are shunned (even the free ones like WSO2) in favour of MassTransit, which is more lightweight but if you visit the sites, you'll see requires code to change it. That means lower ubiquity (the world is bigger than software development) and it has to be built into the Continuous Integration/Deployment process and tests have to be written for everything from the routes to Automatonymous (the state machine). So it's not quick and for others, it's not easy.

Make no mistake, MassTransit is cool, I really like it with my coding hat on, but in reality all the problems it solves have been solved before. Many people say WSO2 etc. are not testable, which couldn't be further from the truth. They just don't have the skills to test it and "cargo cult" their objection, as this hits ego massively. There is of course, the automatic objection to vendors, especially high priced ones, thereby potentially iring them with your Sharepoint skills too. So be mindful of all of all of that.

Happy to discuss it on a call if you need more information.

You asked 2 different questions:

1. Will it impress hardcore coders? No. Never. We could be impressed by what you achieve without code, but we wouldn't respect you as a developer. You're more of a crafty product developer, which leads me to...

2. Could it be made relevant to product manager jobs? Yes. Absolutely, because product managers don't need to be able to code, they're not hired by coders, and most don't know how to code at all. What you're doing would be considered product prototyping, or concept proving.

I'd agree with a few of the answers you got.

All applications are done with code, even generated code. You're showing some level of technical skills that and some point could translate into businesses and roles. In businesses, we are here because we need people to help us move projects forward, solve solutions in any creative way and bring results. We appreciate our team have and understand that mindset. In your situation, you cannot 'compete' with any hard code 'expert' with lots of years of experience, but, who can be an expert today? in this so changing tech era, in where code , frameworks, business models integration and blah blah always popup. So, one thing for sure is learning and understanding, and, actually, following methodologies, basic fundamentals, techniques, and strategies that seems to work (general concepts about programming and how it relates to the type of project you are working on) - and this case may be hard for you knowing you may find yourself really limited.
You may not get into organizations that already have their requirements up front. But, there are flexible organizations and s/m businesses, start ups, that application requirements are so open - they want someone to help bring the idea up. Tehy need a piece of sotware that can integrate with their main software smoothly. To test, or to even run with law strategic features, who knows you can't do it?
Yes, I can see a path into junior dev roles. Even though you use automated platform to create apps, internally they are using one of the languages you mentioned, or a couple of them. It is relevant? for product improvements, for calable applications, for security and for performance, e.g. Yes! it is relevant to understand how all those pieces work together. But most of the time, you don't work alone. That is part of working with a good team.
Programming and development is a changing evolving career, in where there is constant improvements - in where you also find people too stuck and really closed minded. There are organizations for each situation -there are organizations who allows working in pairs. And In talking about methodologies to use, it is a good topic to learn from as well. Go as you feel fit and are able to bring something to the table. I am in Seattle, and there are few organizations I know some people get into them not because of hard coding experiences, but who have worked on passionate projects in where they did some sort of coding and offer a solution for a problem - that sells! sometime. Prove what you can do. When the business has or make money down the road, then they will strategize on how to address their technical needs and departments. At first, many startups don't even know where are they up to yet.
Good day!

@Horace Nelson's answer is absolutely spot-on!
In my opinion, this is what you should take from all the answers on this question.

A product manager / owner who can actually understand a prototype? That's pure gold. Go agile, immerse yourself in the tech culture via weekly meet-up groups and industry blogs, and you're there.

I like the responses above. As a high-technology management consultant, not sure why you would be trying to impress 'hard core coders.' If you're applying for a product manager position, you should be communicating examples of the value you have created with technology to the hiring managers (HR, consultants, business development managers) who are looking for valuable team members. What you're describing, by pulling different tools and technologies together to create solutions, could be a sign of understanding and creativity around system architecture, but the actual tools you're using likely would not apply to the more robust systems that many companies that you'd want to work for would use when building innovation or managing product lifecycle processes.
Demonstrating that you can learn foreign tools and you've been using what you have at your disposal could be valuable for your story -- but backing that story up with an understanding of the leading systems being adopted for architecture or digital product capability is likely more relevant to joining a team. Truth be told, many great developers aren't aware of all of the functionalities of the tools that a company introduces to them for product innovation, but their ability to understand, learn, and quickly adapt to the systems, so much so that they can alter the process through new functionality aligned to business results, is what makes their 'code' skill valuable to the team and company. Product managers may take a higher view of the process, but need to be able to communicate effectively with all members of the team -- including developers -- to drive client and business outcomes. From data layers, to architecture integrations and functionalities, if you've got a great dev staff and can work effectively with them, you'll be able to ask questions and learn about the systems native to the company's product process. However, popular platforms and systems for different industries are worth knowing. Having a firm understanding of SCRUM, the process developers go through to build new capabilities, emerging digital product tools, and having the personality qualities of a manager who expresses genuine appreciation and acknowledgement to those who know things you don't, won't hurt your case. Overall, there are certainly many ways product managers combine technical intellect and people awareness to create value for a team or project. While learning code can't hurt you (unless time is a major factor), having a real understanding of the big systems that govern product development (or specific systems and tools that a company you love uses in their architecture) is likely a good next step for skill building and preparation.

I believe it will be difficult to impress the hard coders with “no code” applications. But all is not lost. This means you need to know how to program online. There are a lot more complexities that go into programming a website, or app, that has users, requires servers, authentication, and databases. This will be far more practical on a resume, as well as help you learn how to use new technologies. Building an entire website or app all at once is difficult. Instead of just scraping the data, why not build a website with that data. This scraper could pull the data into a database and then select the most popular posts. You have now shown that you can do more than just code a small segment of a system. Instead, you can think through an entire system. You need to consider how you are going to automate the process, manage the database, create the website, and select the posts. Maybe there was a free conference in your area on data science or big data and you missed out because you forgot to check. Now, I assume both Meetup and Eventbrite have similar options. But it is always fun to try to build your own system. You can customize the system to work the way you want, and maybe even allow other people to make their own alerts by making this a website. What if you could create a website that helps to predict what to buy a friend for a gift. It could allow the end user to either create an account or just get a gift recommendation. One, learn about how to use APIs and get you comfortable with reading API documentation. Two, if you do it well, you can get a commission for each product someone buys. This project also has an opportunity to try to create a basic machine learning model.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath