Bringing those prototypes to production is another matter. In any organization, there are processes that need to be followed to onboard a new application, platform, pattern, etc. If those aren't followed, the implementation won't be nearly as effective—especially long-term.

Indeed production is another matter.. "I'll just slip in this new crypto routine I wrote and ask for forgiveness later..."

It's the office responsible for processing TPS reports.

This is at a 25,000 employee healthcare system. Bureaucracy is inevitable, but agility is still essential.

Our manager doesn't have a clue how systems work, so it's up to us to find the best way. I know the various areas we need to develop to push the system forward and it is up to me to find the best way to do it. If I learn something new that makes me rethink something, then I am more than welcome to revisit it and try out some new things. If it ends up with a better system then we all benefit. At the end of the day the work that needs to get done does get done.

Obviously I do have to use my judgement to allocate time appropriately. If there is a customer screaming at accounts because they were overcharged or whatever, then it is quite obvious I need to resolve that issue rather than work on a new way to style our buttons, but for the majority of the time it is up to me.

I do also spend quite a lot of my own time working on various things where it is a bit ambiguous as to whether it is 'proper' work or not. I enjoy the work I do because I don't feel like I am working in a sweat shop..

Maybe I'm just lucky to have always found a job where management trusts the developers.

When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.

Nobody is sitting over my shoulder looking at everything I do and I'd be right out the door if that was ever the case. I'd expect professional software engineers to spend at least a bit of their time working on this sort of stuff!

Well, of course this is how normal development works. This is the work I am talking about that would _not_ get done because the OP was working on a prototype to solve some _other_ problem.

Working code is the easiest part. No one every throws it out and we are doomed to maintain the shitty prototype code for years. I find for internal software / consulting: "working code, ends arguments" but for enterprise software it is exactly the opposite.

It's idiosyncratic code that doesn't scale to a team developing it. It's has no tests and no thought to broader usage. There is no documentation. It fails apart after you put load on it, want HA, load-balancing, disaster recovery. Almost all code works at the small scale. It's so hard to prove to even mid-range developers why an architecture that "works" doesn't really work.

When you mix developers coming from the opposite spectrum it is disastrous.

I think the key thing here is to ask "What is the impact on other people if I just do the thing?"

In the case of building the prototype, its either "Well, now they need to spend time looking at the prototype", which would be the case no matter what communication medium you used or its "Well now JS spent 4 days doing that instead of what was on the roadmap. On the other hand, we have a prototype of X" which is a bit of a gamble and depends on what people were depending on you for.

I don't understand this point. Are you suggesting coding a prototype on your own time? Otherwise if everyone in a team is free to choose to code prototypes who gets the actual work done?