Quitting my job over different perceptions on good software [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-1
down vote
favorite
This question already has an answer here:
How much should I say in an exit interview?
8 answers
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?
software-industry quitting
marked as duplicate by gnat, Jim G., user9158, scaaahu, Jan Doggen Aug 13 '15 at 10:11
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
suggest improvements |Â
up vote
-1
down vote
favorite
This question already has an answer here:
How much should I say in an exit interview?
8 answers
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?
software-industry quitting
marked as duplicate by gnat, Jim G., user9158, scaaahu, Jan Doggen Aug 13 '15 at 10:11
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
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
6
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
suggest improvements |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
This question already has an answer here:
How much should I say in an exit interview?
8 answers
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?
software-industry quitting
This question already has an answer here:
How much should I say in an exit interview?
8 answers
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?
This question already has an answer here:
How much should I say in an exit interview?
8 answers
software-industry quitting
edited Aug 13 '15 at 16:51


Masked Man♦
43.6k25114163
43.6k25114163
asked Aug 12 '15 at 20:32
Niels B.
1653
1653
marked as duplicate by gnat, Jim G., user9158, scaaahu, Jan Doggen Aug 13 '15 at 10:11
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, Jim G., user9158, scaaahu, Jan Doggen Aug 13 '15 at 10:11
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
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
6
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
suggest improvements |Â
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
6
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
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
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
6
6
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
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
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
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
1
I'm voting to close this question as off-topic because this sounds like a rant.
– user9158
Aug 13 '15 at 0:20
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
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
suggest improvements |Â
8 Answers
8
active
oldest
votes
up vote
15
down vote
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.
– Niels B.
Aug 13 '15 at 15:54
 |Â
show 3 more comments
up vote
8
down vote
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.
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.
– Niels B.
Aug 12 '15 at 21:00
suggest improvements |Â
up vote
6
down vote
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?
– Niels B.
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
suggest improvements |Â
up vote
3
down vote
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.
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
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.
– Niels B.
Aug 13 '15 at 15:54
 |Â
show 3 more comments
up vote
15
down vote
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.
– Niels B.
Aug 13 '15 at 15:54
 |Â
show 3 more comments
up vote
15
down vote
up vote
15
down vote
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.
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.
answered Aug 12 '15 at 20:38


Wesley Long
44.7k15100159
44.7k15100159
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.
– Niels B.
Aug 13 '15 at 15:54
 |Â
show 3 more comments
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.
– Niels B.
Aug 13 '15 at 15:54
1
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
"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
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
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
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
@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
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
@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
1
@Frisbee, your response reflects a lack of understanding of the question and a total lack of manners.
– Niels B.
Aug 13 '15 at 15:54
@Frisbee, your response reflects a lack of understanding of the question and a total lack of manners.
– Niels B.
Aug 13 '15 at 15:54
 |Â
show 3 more comments
up vote
8
down vote
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.
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.
– Niels B.
Aug 12 '15 at 21:00
suggest improvements |Â
up vote
8
down vote
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.
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.
– Niels B.
Aug 12 '15 at 21:00
suggest improvements |Â
up vote
8
down vote
up vote
8
down vote
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.
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.
answered Aug 12 '15 at 20:47


Joe Strazzere
223k106654921
223k106654921
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.
– Niels B.
Aug 12 '15 at 21:00
suggest improvements |Â
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.
– Niels B.
Aug 12 '15 at 21:00
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.
– Niels B.
Aug 12 '15 at 21:00
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.
– Niels B.
Aug 12 '15 at 21:00
suggest improvements |Â
up vote
6
down vote
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?
– Niels B.
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
suggest improvements |Â
up vote
6
down vote
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?
– Niels B.
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
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
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'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?
answered Aug 12 '15 at 20:48
Amy Blankenship
7,13711836
7,13711836
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?
– Niels B.
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
suggest improvements |Â
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?
– Niels B.
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
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?
– Niels B.
Aug 12 '15 at 20:51
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?
– Niels B.
Aug 12 '15 at 20:51
6
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
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
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
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
suggest improvements |Â
up vote
3
down vote
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.
suggest improvements |Â
up vote
3
down vote
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.
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
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.
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.
answered Aug 13 '15 at 0:31
Carson63000
7,1712748
7,1712748
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
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.
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.
answered Aug 12 '15 at 22:48
keshlam
41.5k1267144
41.5k1267144
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
2
down vote
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.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
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.
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.
answered Aug 12 '15 at 23:51
mhoran_psprep
40.3k462144
40.3k462144
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Aug 12 '15 at 21:10
Patricia Shanahan
16.2k53256
16.2k53256
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Aug 12 '15 at 22:23
Jakub K
1191
1191
suggest improvements |Â
suggest improvements |Â
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
6
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