If it were me, I would insist some more on the hardware and the delay of hardware.
Have a "bug" in your circuit board? The most mundane thing, you planned room for a 5mm component but it's slightly larger and it can't fit.
It takes 5 minutes to adjust the schematics. It will take minimum 2 weeks to manufacture a new board and until it's delivered to your lab.
The project is now 2 weeks late.
Every criticism I give is met with "but it's for kids so shut up!" - but that makes my point more valid!
Image how much easier it would be for kids to learn if it auto suggested words and things like any decent ide, or highlighted why their code won't work before they try to flash it, and had useful links and resources to how to do things.
I use to work in professionally teaching people Arduino and writing other programming stuff. I'd rather keep them away from Arduino, there's no room for self-learning at all. It's only for people who already know C.
Also there are less of those religious arguments over code style in embedded since it's all written in C and will look like ass no matter what.
in 'normal' software you're awash in a sea of poorly or non-documented libraries with a host of weird bugs sitting on top of mountain of dependencies you could never untangle.
while very limiting - that simplicity can be pleasant
and yes, you just know its going to look like ass no matter what - but it works and thats all we care about
But, I do agree with the general point - since everything is "close to the metal", there are no or very few layers of abstractions to dig through to figure out what's going on.
Of course, you then get to deal with weird bugs from poorly documented hardware IPs...oh well.
