You generally shouldn’t put code you want to reuse in notebooks, but we haven’t found this to be much of a problem. And >3/4 of the people who’ve worked on our team don’t have software engineering backgrounds. If you set clear expectations, you can avoid the really bad tar pits even if most of your co-workers are (non-software) engineers or scientists 0-3 years out of college.
It's harder to breach that barrier in embedded, because someone has to approve of getting the hardware made.
In most organizations, there's a kind of no mans land between hacked code, and professionally written software. That's because the real SWE's are always overbooked, and for good reasons -- business and career wise -- should be working on the biggest projects. This leaves software needs that are urgent for somebody but not urgent enough to rise to the top of the priority list for the software team. The somebody could be an internal or external customer.
That explains a lot. I have seen a lot of SWE that believe they are working on bigger project but they are not. Probably 90% of them.
These are the guys that will produce a lot of useless abstractions without producing any real value.
I guess they aspire to work with kafka/k8s at Google but ended up at the local shop.
And nothing wrong with the local shop. This is probably the place where you actually have the possibility to produce real value.