What stops your Arduino project?

For me, I still find Arduino is THE go-to option for almost all my prototype projects as I've almost always found an Arduino open source library for the sensors I need to use - even the obscure ones.

In business, MS Excel or Google Sheets, for example, tends to be the first thing one uses to analyse data, develop a model and produce reports with charts to show trends etc. I've always seen Arduino as the hardware version of the spreadsheet - as it allows you to quickly create projects to measure real-world data with sensors and transmit this data remotely if required.

Having been schooled in the traditional (i.e. many moons ago) methods of programming during my engineering degree, I grew up totally dependent on a debugger to help me develop firmware. Discovering that Arduino did not have a debugger was initially a stumbling block, but I soon found that by changing how I think, prepare and develop a project using the serial monitor and data logging I can still achieve the same outcome. In fact, over time I have found, when switching to other IDE's and platforms, that I rely less and less on the debugger and with BLE, for example, and probably other real-time event driven modules, you cannot use a debugger and have to use other "sniffing" tools.

As such, I think video tutorials on alternative development approaches, without using debuggers and also using sniffing tools, may be helpful.

So what else stops me?

Well for me it's searching for the right components to use, whether it's MOSFETS, pressure sensors or RF modules, for example. All too often I make mistakes based on the assumptions I've made based on what I read on Newark/AVNET/Farnell/Mouser/DIgikey/etc. But, TBH, this is mostly caused by my lack of familiarity with what I am trying to achieve.

Python has some of the debugger stuff baked-in : )
Someone should do a write-up/video (if it doesn't already exist) showing how to do it - e.g. how to edit variables on-the-fly and run code, it's very interactive since it is all interpreted and has a nice 'shell'. Not related to Arduino though : (

I too have (slowly, without realizing it) changed my coding practice to work around the lack of debugger (mbed and others don't have a step in/step over capability, memory viewer, etc either, and I don't ever remember using GDB with it either - perhaps I have but can't recall), to the extent that I no longer miss it... this only kind-of works when the C run-time and the libraries and the compiler are reasonably stable of course. Whereas in the past, pre-GNU and early GNU compilers, none of that was very certain.

Agree there should be videos on the alternative approaches, e.g. using console output (maybe also input), how to insert debug statements into code and easily switch it on or off, and where to insert it for reducing intrusiveness to real-time behavior, how to detect if memory is being trampled, what types of things to be considerate of to reduce run-time errors.
Also how to do (where feasible) some stuff in Linux first, where GDB is available (usually a last resort thing, since there's plenty of higher-level debug options for algorithms anyway), to sort out algorithms etc without spending time building and pushing to the real target platform repeatedly, stub code, #ifdef etc. 

Python has some of the debugger stuff baked-in : )
Someone should do a write-up/video (if it doesn't already exist) showing how to do it - e.g. how to edit variables on-the-fly and run code, it's very interactive since it is all interpreted and has a nice 'shell'. Not related to Arduino though : (

I too have (slowly, without realizing it) changed my coding practice to work around the lack of debugger (mbed and others don't have a step in/step over capability, memory viewer, etc either, and I don't ever remember using GDB with it either - perhaps I have but can't recall), to the extent that I no longer miss it... this only kind-of works when the C run-time and the libraries and the compiler are reasonably stable of course. Whereas in the past, pre-GNU and early GNU compilers, none of that was very certain.

Agree there should be videos on the alternative approaches, e.g. using console output (maybe also input), how to insert debug statements into code and easily switch it on or off, and where to insert it for reducing intrusiveness to real-time behavior, how to detect if memory is being trampled, what types of things to be considerate of to reduce run-time errors.
Also how to do (where feasible) some stuff in Linux first, where GDB is available (usually a last resort thing, since there's plenty of higher-level debug options for algorithms anyway), to sort out algorithms etc without spending time building and pushing to the real target platform repeatedly, stub code, #ifdef etc.