I'm miserable at my first programming job (small company) due to a very long list of workflow and management issues.
These issues cause me a great deal of stress, to the point of feeling physically sick from dread in the morning some days. I understand this is extremely unhealthy and I'm planning on leaving as soon as I can get a decent job lined up, though that will be difficult (and will probably take a long while).
One of my managers is the head of the company (let's call him "Bill") who assigns me the majority of my tasks. Bill does a lot of the programming himself, but has severe problems communicating, delegating, keeping organized, among many other things. The vast majority of my issues come down to dealing with his (very problematic) workflow, and him not being receptive to changing it.
Early on I was bringing up these issues, diplomatically, to him and other managers, always making sure it's alongside a suggested achievable solution. The response is always the same: Bill says, "it's not a priority", "this is just how I do things", or (usually) total silence. If it's in person, his mood also sours. After so many times, I've learned to stop asking, which has become extremely distressing.
I've discussed a couple of the issues briefly with one of the other managers (who is also in programming, but is not a direct superior), and he seems to agree with me on the solutions. He also has implied feeling a bit stymied by these issues as well.
This is complicated by my direct superior being almost entirely unrelated to programming. In theory I should bring these up with him, but explaining technical process problems is difficult to someone unfamiliar with the workflow, and a language barrier compounds this. I've asked HR about him recently and they confirmed my direct superior is still him, despite very few of my tasks being assigned by him.
Ethically, it feels that these other managers should know about these workflow problems, especially as they're actively causing harm. I respect these other managers, and some part of me says I need to communicate this to them, so that when these issues aren't addressed, and I leave, they can infer why. But I don't know how to communicate these problems, or where to start, or if it's even possible at this point.
Do I (ethically speaking, not legally) owe my company this sort of "fair warning", to bring up issues that are severe enough to make me want to quit, even if I know there's no hope in fixing them? If so, how do I voice these concerns honestly and fairly, without becoming "the complainer" and souring my relationship with the other managers?
EDIT: My initial intent was to keep it brief, as the details tend to get rather longwinded in explanations in an already complicated situation. However, there's been several requests to give examples, to show I'm not just some hotshot new dev who thinks they know everything (which does tend to happen here it seems).
Here's a few particularly problematic workflow issues that have been dismissed/deflected/ignored:
"Bill" doesn't understand merging. Instead, he will re-clone the repository in another folder, update to the destination branch, open a diff tool between the two folders, and overwrite select clusters of files from one branch over the other (sometimes 1000+ files). Then he makes a commit on the destination repo with a message no longer than 3 words.
We have no issue tracker whatsoever. Issues and bugs are frequently reported by clients, and their complaint email is forwarded to me and several others. I investigate, and reply with my findings and suggestions to my superiors and to customer relations. Often a new email chain is started with a different and often unclear subject, and is often hard to correlate with other emails later on.
I have virtually no code-related interaction with other programmers. There is no code review, no pair programming, no Q&A about how things work internally. I am pointed in a direction and told to go. Bill has said he's quite proud of this "sink-or-swim" strategy, even after I've expressed discomfort with it in the past. By now I have most of the ropes, but when I'm tossed into a new area of the code, it can be deeply distressing.
All of these I have brought up with Bill and other managers, with examples of specific problems caused, and short- and long-term solutions to moving past them. I made sure to phrase things as diplomatically as possible when doing this. In all cases these attempts were dismissed or ignored.
From conversations with friends in the industry (with years more experience than me), I've been told these problems are not normal.