You've brought many things to the table here, and are trying to condense them into a singular "should I leave?" decision.
First of all, "should I" decisions should only be answered by yourself. Don't let strangers on the internet make decisions for you.
I've written this answer to separately address the different things you've brought up, because you might encounter a subset of these issues at other workplaces and that doesn't inherently mean you should make the same decision to leave those workplaces.
Leaving when unhappy
The combination of out of scope work and company drama makes me want to leave
If you want to leave, then leave. There is no bar other than the one you set for yourself. Forcing yourself to work in an environment you don't want to work in is not going to generate happiness for you.
That being said, if there are ulterior motives, e.g. if moving jobs means taking a huge pay cut, then it becomes a matter of balancing whether you'd rather leave or have the extra pay. No one can make that judgment call except you.
The work
since I'm the only IT'er here.. any IT problem lands with me
This is not uncommon. To non-IT people, IT is alien voodoo magic, and of course they're going to visit the local shaman to help shake the chicken bones.
That being said, this can devolve into a matter of laziness, at which points lines need to be drawn.
I must add that I'm actually a freelancer but my assignment evolved in me working long term fulltime for this sole client so the way I'm working could be compared to an employee really.
Consultants tend to have a stronger standing to contest jobs outside of what was initially agreed upon. You can stick to that line if you want, but it's going to cause a dent in their opinion of you. As this is a small company, such reputational dents carry more weight than in larger companies.
I get asked to build software solutions...
I end up not only programming but also doing quite some research and actually working as an inventor of sorts..
Building software solutions entails more than just writing code. This is why "developer" is different from "programmer". Think of it like writing a novel. It takes more than just typing. You need to come up with a story, plot, narrative, characters, ... (= development) it's not just about the letters that you type (= programming).
There is nothing wrong with wanting to be a programmer and not a developer. But working at small companies tends to entail needing to be a jack-of-all-trades in your field.
I worked as the sole employee in a software studio. This meant I had to maintain our infrastructure, plan technical meetings with clients, server maintenance, deployment, ...
I didn't mind that, because I like that. I personally wouldn't enjoy solely programming. But you might be different and that's okay too.
If you're looking for a code-writing job with clear set criteria and not many sidejobs, look for work in a larger company, where the workload tends to be categorized in specific roles more. More staff tends to mean more specific roles.
you can't print.. I'm solving it...
This goes back to the "not my job" argument you can make.
However, as a consultant, I find that I'm often considered a source of expert information, even on matters that are trivial or not really part of my job. I don't mind it, as long as my time is accounted for.
If my client sidetracks me two days having to help someone, I don't mind helping, but then they have to accept that the deadlines for my planned job also shifts by two days (unless there was already open time in my schedule). In other words, I don't mind doing different work for a short time, but I do refuse to do extra work.
The thing is, your client clearly is in need of help, and you are in a prime position to provide that help. That is a very good business opportunity, if you're interested. It may involve some more hand-holding than you would like, but there is good money to be made by providing a service that the customer needs you for.
I personally like this (up to a healthy degree) because it fosters a long term stable relationship, which is nice as a consultant since you always run the risk of not finding a (nice) new contract.
But again, if you don't like it, then don't work there, or set very clear lines on what you will and won't do.
meetings are unstructured and there are never any items on the agenda... things get made up on the fly (really strange features that break standards) and I have to make sure they get done... Every single time, they manage to surprise me with the things they want in such a way that I don't know what to say.
I consider myself a passionate developer. I love the feeling of writing an elegant piece of efficient code.
But whenever a client asks for a silly feature, and ignores my suggestion to do it differently, I simply give them a projected timeline to completion and think to myself that as long as they're paying for my time spent on this, whether it's BS or not, I'm achieving my job of working as a software developer.
As a contracted employee, I agreed to work a specified amount of time for a specified wage, within some reasonable role. If the client wants to pay me to make silly or uncool things, then I will make them silly or uncool things. After all, I'm not the one running the company or deciding what the company should do.
And again, if you are negatively impacted by building something that you feel isn't the best that could've been built, then consider not working for them. But I'm hardpressed to agree that you're easily going to find a job where you're never going to have to build something that you don't 100% support.
Coping strategies
These are just some suggestions on what you can do to manage your work for this client, assuming you want to keep working with them.
I can't finish things and am jumping around between whatever is needed at that time.
Resist being sidetracked by explaining the current planning, the urgent nature of your current task, and the consequences of putting off the current task (e.g. "I promised Bob to get this done before lunch because he's stuck right now").
When someone tries to sidetrack you, judge whether it is truly an emergency, or if this is something that they failed to plan appropriately.
Help out when true emergencies occur. When non-urgent things pop up, defer them to a time where you are free to discuss them. Or, if you can, take the time to discuss them but only promise to pick them up after your current tasks are finished.
If you are pressed into doing this new thing first, discuss this with the management who is affected by both the old task and the new task, and let them decide which takes priority.
I cannot deliver the quality I'm used to because of the broad responsibilities.
One thing I very quickly learned is that you cannot rely on non-developers to grant you extra time to do developer-specific tasks (such as ensuring code quality), because these people don't understand those tasks, and that's not their fault.
Instead, you should account for these tasks in the deadlines you project. If I'm asked to make a change, which takes me 2 days to implement and 1 day to test/refactory, then I will tell them it will take 3 days.
I don't tell them it takes 2 days to write and 1 day to test, because this somehow suggest that they have the freedom to decide that I should skip that third day, which in my opinion they don't.
At a push, if there is a true emergency, I will agree to push out a dirtier workaround quickly, but only on the condition that extra time is taken to clean this up as soon as possible (usually the next sprint). I treat those deferred tasks as a hot potato and I refuse to let such technical debt grow on the backlog.
If the client keeps pushing new emergencies, I remind them that they agreed that I needed time to now clean the quick and dirty fix they had me push out as a favor to them.
If you don't budge on issues of code quality, you will find that you will find much less resistance from others in not giving you the time you need
I feel like I'm never prepared for a conversation with them and no longer have any new input because I have too much on my plate
Tell them that, in a professional manner. Try to set up a meeting for later, even if that's only 30 minutes later. It means you can prepare for that, instead of having to drop everything at their beck and call.
Software development is sensitive to unplanned interruptions, best exemplified by this comic. A minute-long interuption can cause a 30-minute slowdown because the developer has to get in the proper mindset again.
The best analogy is trying to interrupt someone who is doing mental arithmetic. Some non-developers very much understand that scenario and will learn to not interrupt you for no good reason, but there are many non-developers don't understand it (or reject it), and there are some tools to get them to respect that boundary even if they don't understand it:
- Ask for things to be put in email. So they can be looked at in due time. If they approach you, apologize for being busy and tell them that you'll look at their email as soon as you can. This gives you the opportunity to look at it when you are inbetween mentally complex tasks, rather than in the middle of one.
- Plan meetings, even if these are 10-minute long visits at someone's desk. It doesn't have to be scheduled for a specific time slot, but at least get them to wait until you are able to discuss their problem with them.
- If you are prone to distraction or work in a distraction-heavy environment, wear headphones (if allowed of course). Not only do they block out the distractions (I love my noise cancelling headphones), but they also signal that you don't want to be interrupted for trivial matters.
The drama
Yeah this is not a place I'd like to work. I have actually quit jobs for similar reasons, and will continue to do so when I encounter them. The only reason I stuck around was if the contact with the problem manager was minimal and the working relationship with the actual daily colleagues was better.
However, you may be at less of a risk of getting the stick here since you're an external. I have met the most horrible micromanagers who somehow treated me like more of an equal just because they weren't technically my boss since I'm a consultant.
I leave these kinds of places on principle alone, but if you're mostly worried about the founder turning on you, it depends on whether the founder is actually going to mess with consultant the way he messes with internals.
