N8N is great and a mess. I’m a senior dev for c# backend webservices (mostly rest) and SQL and am trying to play a bit with N8N.
I see, that you guys don’t have the resources like MS to build a dev experiance, that’s somewhat polished. I expect some hickups. But it’s harder to swallow some behaviour (bugs?), that really seem to stem from bad architectural decisions of how this whole plattform operates.
So here are some things I have encounterd (and this is a private side project to evalute this plattform). Currently I can’t see me recommending this for my work (govermental healthcare), even not for some quick prototypes. Well - there is no such thing as “quick” and our prototypes are more (semi-) permanent. 
First the faulty implementation of the Wait (for Webhook)-Node.
Now, that doesn’t look to complicated, does it? Triggerwebhook returning immidiatly, Wait (for Webhook) with “Using Response to Webhook”-Option and the Response to Webhook. This is the “result”:
{
"errorMessage": "Webhook node not correctly configured",
"errorDescription": "Set the “Respond” parameter to “Using Respond to Webhook Node” or remove the Respond to Webhook node"...
}
Well, you can work around that, by NOT using the wait for webhook at all. You can loop and ask N8N, if ANOTHER workflow has finished. Than you just set up this other workflow as receiver for the webhook, that the wait-node should be in the first place. Something like this
Now I have done worse in C#. But of course I don’t want my workflow to be so confolutet, so - just break it up into smaller workflows and execute these from the main workflow - a bit like calling a dll.
But… executing a workflow is also broken. Well - not totally, but it overrides my runtime variables! WTF? That seems to be some serious design flaw. Here is, what i mean.
My main workflow calls the “CreateSpeech”-Workflow. If I don’t connect the output of this first workflow to the C_InsertNotification-Code-Node, the output looks like this:
Good, that’s what I expected it do be.
Now I connect the output and wire it to the next Workflow-Execution-Node like this:
Calling this workflow with EXACTLY THE SAME INPUT leads to this display of the result of the FIRST workflow-node:
Now - I DO set this json-property. BUT I do so in the second workflow, that is NOT executed yet (well - of course it is, because it finished, but there should be NO WAY, that feeds into the previouls finished output result of the first Execute-Node.
My conlusion: what i see here is actually not, what is happening in the codeflow. I see some sort of log - and this log is structured somehow. And in this case, the UI messes it up and shows me something from the wrong place in the debug log.
That is bad. I can’t say, if it’s better in the debug-editor, since I dont have an enterprise licence (yet - but given these preliminary findings, I probably won’t advice my management to get one). And that is a shame, because N8N could be a really nice tool for some quick and dirty implementations to showcase the workflow to other organizations, before implementing them in a proper (high performance) way.