As the only backend developer, how should I handle repeated challenges from my manager about core technical decisions?

He also says that since there is no other developer to review my work, it’s reasonable for him to question my decisions, even on topics where I am the only expert.

Well, he's right on that. It is reasonable.

When he questions your decisions, there are three possible outcomes:

1. Your decision is right, and you can explain to him why this is the case. Yes, this delays your work, but if your manager wants you to spend your time teaching him instead of coding, that's his choice. It might even be a good choice, given the fact that you are currently the only backend developer.

2. You strongly feel that your decision is right, but you cannot explain why. Well, this is a learning opportunity for you (actually, for both of you). Open Google and find out why your decision is right (or not). If your manager wants you to do research and improve your skills instead of coding, that's his choice.

3. Your decision is wrong. Congratulations, teamwork just prevented a bug from getting into the codebase! Don't take it personally, nobody is perfect. Don't forget to thank your manager. It's hard, but don't let ego get in the way of improving your product.

For example, we recently had a long discussion about list ordering: I explained that unless you explicitly order a list in code, you cannot rely on its order remaining the same in the future, even if it seems to work now. My manager did not accept this and asked to see the code, because it was different from what he believed, even though he is not a specialist in this area.

I'm also an experienced C# developer, and I love questions like that, especially from people with a different background. It gives me the opportunity to explain to them the concept of design by contract, and how software development for business components differs from hardware development. A business software backend is not a piece of hardware whose implementation never changes, but an evolving system under continuous development, thus necessitating the need for a contract. Does the documentation of the method specify that the return value is ordered? If yes, it's the backend's duty to ensure this property, even if the implementation changes. If not, the frontend cannot make this assumption, and the backend is free to implement optimizations that break the list order in the future.

Let him make his decision, write it down, write your objections below it and start following his decision. When things go wrong you tell him “I told you so” and take no responsibility for the failure. If someone higher up enquires why a feature isnt done you tell him “because my manager insisted of doing it his way even though I told you that would fail”. Throw him under the bus, he deserves it.

To the manager: A competent manager hires people who are better at their job then he could do it. So unless an employee has shown himself as incompetent (and should be fired), you assume they know their stuff better than you do.

And by letting them use their decision, you make sure they will be doing what makes them look good which turns out to be good for the company. Having to follow your orders they will want to demonstrate your orders were wrong and will subconsciously want to fail.

I had a manager just like this once - he had a similar, C-heavy low-level background, while I was a Java developer and architect. It got to the point that he thought we should write our own hashmap instead of using the one in the Java API! Needless to say, I didn't stick around.

It's all well and good to talk about setting boundaries, but ultimately you cannot enforce a boundary against your boss without being willing to walk away. You need to decide your red lines here, make those clear to your boss and why you feel that way, and be willing to walk away if they are not respected.

I feel like there are a lot of questions on this SE that boil down to "how can I make my manager respect me," and the answer is that you cannot. Maybe some situation will eventually arise where you will be able to play the hero, and/or he will be taken down a peg, and you will then be in a better position, but more likely he will just continue to make your life miserable.

A manager's job is to make sure that the needed product makes it to the market within needed time and cost. When a manager is getting into the technical decisions, that is often an indicator that the project is going over time or cost constraints.

Your questions suggest that you are focused on the quality of the system - rightfully so. I submit that it is time to talk about the manager's concerns.

The point is to go over your manager's real concerns (time and costs) and address them in a professional manner.

Managers often have unrealistic ideas of what can be accomplished by one person within the given amount of time. This situation suggests that it would be a good idea to sit down to go over the whole project, identify what can be done in the time left, and push out to a second project (or third project) those items that are of lessor importance and won't get done in time. Even if you are meeting with the manager on weekly or daily basis, it is a good idea to periodically review the whole project goals and timelines.

If the manager continues to debate your professional decisions after you have addressed the manager's concerns, that suggests that it is time to move on to another position.

In organisations where experts work together, there always is a discussion about what is the right quality.

Qualitative research methods suggest that after asking 12 to 30 experts a relative qualitative saturation is reached.

What I am saying with this is, that the likelyhood of you and your manager being wrong at the same time is very high.

But humans cannot organise their work together if not one person has the authority of decision making.

What you need to do, is not to argue with your manager about who is right about a detail, but to agree upon who is the authority and at the same time accountable person for that field of expertise.

Your manager might be accountable for people management, but you might be accountable for the subject. But do you two share the same understanding of who is accountable for what?

Well, you are in a tough position. I am not sure this will solve your problem, but you can try - at least as an exercise. The other solutions are the usual ones: keep going as you did until now for as long as possible, and (then) find another job.

Since your manager is so determined that he knows better, "teach" him how to modify the code (he probably already knows that), how to test, and how to push the changes to production. Obviously, he should do all that using his own account, so any change can be traced back to him.

And then let him decide if he is willing to take the business off the market or not.

WARNING: If you go this way, make sure that you have a bullet-proof backup-and-restore strategy for all the data (code, databases etc.). To be able to recover after the experts prove their point.

The more professional way to implement my proposal is explained below.

1. [MANDATORY] Use a issue tracking system. I hope you already use one.
2. Whenever he wants you to do something, ask him to create ticket and explain there what he wants.
3. You explain why you (strongly) advise against it, and then return the ticket to him for decision.
4. You make the requested changes ONLY if the takes responsibility in written (inside the ticket) for the said changes.

NOTE: Make sure you have hard copies of those tickets, and especially the parts where he takes full responsibility. Just in case that the systems somehow goes down, and the backup copies magically disappear. Or have the tickets exported to PDF, and the PDFs saved properly for later use. In case that the company will start looking goats. Scapegoats.

Now, there is a reverse story also.

If your company has more than one manager, then you can try to escalate the problem to N+2 or higher. However, this can backfire against you - for daring to "rat" against your manager. It is useless to debate in how many ways it can backfire, but you can brainstorm yourself some of them easily. The worst case of the bad cases is that your manager is a dear relative (or close friend) of a higher level manager.