That’s a poor analogy. Accountancy isn’t creative (in fact, creative accounting is frowned upon). Accountants don’t need to develop a taste for ‘good accounting’.
Coding is writing, and choosing what to write about, and picking language to use to write about it. It is an unending series of creative choices.
If someone has no exposure to the process of making those choices, they are not ready to code.
By your definition accounting is budgeting, and choosing what to budget about, and picking the tools to budget with. It operates within constraints, as programming does, and those constraints likely vary from company to company (inverted compared to programming, perhaps---it seems like a larger company may have more scenarios to run, a smaller company fewer, and thus there may be more room for the kind of creativity you describe at a larger company). Even within a tool you can make a million stylistic choices on how to present the information around your budgets and payments to enable the rest of your organization to make decisions.
Programming itself is also not limited to developers. That should be self-evident in that spreadsheets are the go-to tool for so many non programmers, and they are at heart accessible programs. In that sense, it is programming that is a creative endeavor, not development or coding.
Last but not least, the most creative (and valuable) part of programming is arguably problem definition and problem solving. I would argue these two things are shared, in one way or another, across most jobs and careers.
I don't necessarily disagree with this - I've often felt like the criteria used to make software development decisions should be more empirical (YAGNI etc, schemas, contracts - not the whole formal specification bucket, but formal-"ish") and constraint based
However, it seems to me - as a layman with zero accounting experience beyond Wikipedia and GnuCash - you could feasibly drop an accountant into any arbitrary business and they would eventually find their way around the cash flows, balances, and - given sufficient information - build up a general profit/loss and general idea of financial health.
It doesn't seem to me, however, that you could drop any software engineer into any arbitrary company and expect the same. You should be able to, but not right now. Some software engineers can do that. Not all of them.
I suppose my point being: a degree from a chartered accountant indicates a core level of competency to me. But a software engineering degree doesn't. This is why we interview them with whiteboards / fizz buzz / how many windows can you wash / what is the ideal shape of a manhole cover.
Because you can get a top class degree in S.E. / C.S. and still not be able to handle a JVM OOM error.
It's true that the problem space of “accounting” seems, at least to me (I likewise don't have deep experience), somewhat more constrained; indeed, accounting seems very specialized. Perhaps one difficulty here is that “software engineer” isn't really one job or career---it's dozens of jobs or careers that we're pretending are one and the same. To follow the accounting example, I guarantee people are hiring software engineers to do work that is largely accounting. But they're doing that work in something other than Excel, so it's software engineering, not accounting. But is that actually true? You wrap these software engineers in teams with acceptance criteria, etc, etc, but really you're trying desperately to paper over the fact that your software engineers aren't accountants, and you're basically training accountants by trying to help the software engineers build an accounting system.
In general, I agree with your point. It's mentioned elsewhere that there's a difference between a trade school and a university, and a software engineering degree is a broad university degree. Much like an English degree won't guarantee you're a great author, it seems odd to expect a CS degree to guarantee you know how to handle an OOM error, for example. I think in many cases CS/SE degrees to themselves a disservice by trying to teach everything, instead of allowing specialization that can be clearly understood in the next phase of someone's career.
Coding is writing, and choosing what to write about, and picking language to use to write about it. It is an unending series of creative choices.
If someone has no exposure to the process of making those choices, they are not ready to code.