I have been working as a Ruby on Rails developer in a real estate company since 2012. However, I have been fundamentally in opposition to my team ever since it decided to pursue a architectural strategy of smaller services instead of one Rails monolith about 15 months ago.

As a result, I find the system as a whole increasingly difficult to navigate and my productivity is going down, because I cannot trace how everything is glued or stapled together.

I no longer feel entitled to my sizeable paycheck and I want to work on a different team, where I can be a more productive member like I used to be and where I feel that we share the understanding of good software.

If I were to quit my job, can and should I tell my (non-technical) boss/product owner and coworkers, that I am quitting over professional differences?

Will it make me come off as a bitter control freak who's slamming the door or is it a legitimate reason to part?

Anyone with experience in quitting or seeing coworkers quit over different perceptions on how to practice the profession?

  • The linked duplicate probably has some very good answers, I would definitely look there. (I'd also look at how they asked the question: if you want answers to only that part of the question, and not the general advice/criticism you're getting below, that's how you ask it. Minimal details about why you're leaving, only just enough to get your point across. If you do want advice about whether it's a good idea, well, ask it this way.) – Joe Aug 12 '15 at 21:58
  • 7
    But you do sound a bit bitter and control freak. You have not even turned in your notice and yo are worried about what to say in your exit interview. "Share the understanding of good software" - smaller services is not bad software. – paparazzo Aug 12 '15 at 22:00
  • 2
    Just to add to what others have said--there's a link to your github account on your profile. You may want to consider whether this particular question and your responses to answers would reflect well on you to people who might want to hire you. – Amy Blankenship Aug 12 '15 at 22:39
  • 1
    I'm voting to close this question as off-topic because this sounds like a rant. – user9158 Aug 13 '15 at 0:20
  • Sounds like this is a symptom to a much bigger problem. Why didn't you object earlier? Didn't anyone notice the decline in your productivity? Did you decline more than other developers using this system? Your exit interview should consist of, "I didn't think this was going to work. It is severely hindered my productivity. I take pride in my work, so I'm leaving." – user8365 Aug 13 '15 at 10:14

It sounds like your differences revolve around architecture, not over what "Good software" is.

I can't know the specifics of your environment, but the move away from "Monolithic" apps and towards "Micro-Services" is a prevailing wind in the development world, today.

If your organization is going this direction, then it's up to your architect(s) to manage the scope and interface(s) of each application, not you. You (developer) should concern yourself with the INTERNAL concerns of each project you work on, and leave the interfacing to the architects.

If you insist on being the architect, then you either have to get your self promoted or find a place that will let you be the architect. However, your "My way or the highway" approach is not going to help at all in the short term.

Were I you, I'd take this opportunity to learn to be effective in a different architecture. Whether or not you want to pursue it is your decision, but there's no reason at all you can't be knowledgeable about it.

  • 1
    "If I were to quit my job, can and should I tell my (non-technical) boss/product owner and coworkers, that I am quitting over professional differences?" - No implication at all. Just putting a popular (if dated) colloquialism on your statement. – Wesley Long Aug 12 '15 at 21:13
  • 1
    While I think this is good advice, it doesn't really answer the question at all, does it? He's asking how he should approach leaving his job, not asking for advice for how to stay in the company. – Joe Aug 12 '15 at 21:37
  • 1
    @Joe - We're not going to agree, here. He's asking if he can quit based on the merits of his argument, point it out, and do so gracefully. I am trying to get him to realize the merits of his argument are dubious, and therefore the whole set of subsequent reasoning is not necessarily valid. I understand you don't see it that way. – Wesley Long Aug 12 '15 at 22:03
  • 4
    @Joe It is not a about a bad fit for the organization. Smaller services is A valid architecture and if this guy cannot adopt to A valid architecture he has a performance problem. "I cannot trace how everything is glued or stapled together" reflects lack of technical knowledge, ability to adapt, and maturity. – paparazzo Aug 12 '15 at 22:45
  • 1
    @Frisbee, your response reflects a lack of understanding of the question and a total lack of manners. – anon Aug 13 '15 at 15:54

If I were to quit my job, can and should I tell my (non-technical) boss/product owner and coworkers, that I am quitting over professional differences?

Will it make me come off as a bitter control freak who's slamming the door or is it a legitimate reason to part?

Have you talked with someone outside your organization that is a Ruby on Rails expert? What do they think about your company's architectural strategy that you dislike so much?

A "one Rails monolith" architecture doesn't sound good to me, but I'm not enough of a Rails expert to pass judgement.

Quitting over professional differences when you prefer an architecture that experts think is misguided risks not only labeling you as "a bitter control freak" but worse as a "bitter control freak who doesn't understand a proper Rails architecture."

Again, I don't know if that's the case here or not. But before I started telling the tale to a prospective employer, I'd want to know for sure.

  • 1
    While I don't want to start an argument with you, I do want to add that David Heinemeier Hansson, the founder of Ruby of Rails, actively discourages the so-called microservice architecture and promotes a structured monolithic design as the best solution for 99% of use cases. – anon Aug 12 '15 at 21:00

I think you're actually in luck. Many if not most of the people who will be in a position to answer this question will have felt the opposite frustration--they want to embrace best practices, but they are held back by teams for whatever reason can't or won't make the jump. IME, such teams are much more common than the blogosphere would have us believe and you're extremely likely to find such a team if you search for another job. You're just in the position to be on one of the small percentage of teams that is forward-thinking. Many of us find your position enviable, but to each his own.

If you find another job, I wouldn't tell your non-technical boss that you are leaving because you aren't able to keep up with a team that is changing with the times. What would you gain from that?

  • I think you are being a snob with that answer. I have my reasons for disliking this latest fad in software engineering. Could it be that my objections are just as rational as your praise? – anon Aug 12 '15 at 20:51
  • 6
    Even if they are, the answer stands. You can easily find a team that feels the way you do, because it's actually fairly unusual for teams to embrace best practices across the board. And there's no point in telling your boss you don't. – Amy Blankenship Aug 12 '15 at 20:52
  • 6
    This may be harsh, but there's nothing here that doesn't need to be said. Besides, sugar-coating is for donuts, not advice. – Wesley Long Aug 12 '15 at 20:57

What you should tell your boss and co-workers is that you are quitting because the new position you have been offered elsewhere is an exciting role that you are looking forward to taking on.

Needless to say, this means that you should of course have such an exciting job offer in your hand before quitting! There are situations when quitting a job even with nothing to move on to can be the correct move, but "don't agree with the architectural design we are using" is not one of them.

As mhoran_psprep said in his answer, I'm sure you have made it clear over the last 15 months that you don't agree with the design. There's nothing much you can add there. Just find a new position, making sure you discuss the nature of their codebase in interviews, and move on. You've been with your current employer since 2012, that's not an unreasonably short time for a programmer to spend at one company.

If you feel the need to say anything, suggest to your boss that when interviewing for a replacement, he should make sure to talk about the design of the application in interviews, so he can be sure to hire someone who is familiar and comfortable with the micro-service architecture.


To answer the question: yes, saying you're quitting because you don't like the architecture does risk making you sound like a prima donna who is unable to understand the proposed architecture and/or is too inflexible to be able to work with it. If the architecture didn't exist -- if it was a mass of spaghetti code -- i'd grant your point. If it's at all reasonably structured, you really should be able to work with that structure.

If you can demonstrate drawbacks of the proposed approach, that's reason to work with the team to understand whether the benefits outweigh these costs. They may.

If you can't demonstrate it -- if your argument is appeal to authority -- remember that even highly respected authority can be wrong. I had the interesting experience of explaining to Tim Berners-Lee why he was wrong about one aspect of XML Namespaces....

If your argument is "I can't program effectively while holding my nose"... welcome to the real world of software engineering. If you can't fix that attitude, your career is going to be limited.


If I were to quit my job, can and should I tell my (non-technical) boss/product owner and coworkers, that I am quitting over professional differences?

There is nothing to be gained by telling them. For 15 months or more you have disagreed with the direction of the project. If you decide to move on to another project, or to another company resign gracefully with the minimal amount of information.

Are you expecting them to change their mind? They are unlikely to do so.


Disagreements about software and/or hardware architecture are a fact of life. There are some decisions that are so obvious that nobody disagrees, but they are not very interesting.

Rather than quitting a job over such a disagreement, do your best to make the new direction work.

You raise a specific problem with making it work:

I find the system as a whole increasingly difficult to navigate and my productivity is going down, because I cannot trace how everything is glued or stapled together.

What would help you navigate? Roadmap documents? Tools for viewing relationships between services? Check what exists, make sure you are using it to best effect, and if there are gaps discuss with your colleagues what can be done to improve navigation.


Microservices are a form of abstraction which, generally speaking, should help developers to work with a large product. If this isn't the case you should analyse your system and identify why you find it so difficult to work with. The framework you use shouldn't really come into this analysis, you didn't state it but I assume you are using Rails for the services as well.

When you find some concrete issues with the architecture (and possible solutions) raise them with your superiors or the rest of your team. If this doesn't solve anything and doesn't make you happier you can start looking for a different job with a much better explanation to both your current company and the prospective future employers. Your newfound knowledge will also be valuable to a lot of other, growing companies which are thinking about or in the process of breaking down their monoliths.

On last thing, your question makes you sound a bit like a bitter, one trick pony. You have learned a technology/system a few years ago, got comfortable with it and now refuse to learn something new. I realise that this is harsh and I may very well be wrong, but I wanted to let you know that this is how you can be perceived. As a software engineer I would be very weary of giving out this perception.