Mixing
Team makes excuses about bad software and practices instead of fixing it. How to head in the right direction? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
At my new job I sometimes make mistakes. Usually these mistakes are because of assumptions I make based on other jobs I've had, other tools I've used, and other software I've developed on this very team.
Inevitably when we talk about what went wrong, I ask "Where is this information written down?" or "How can I avoid this in the future?" and the answer is always along the lines of "Remember that X in context Y is different than X in most other contexts". The lack of standardization on any practice is hurting my morale, productivity, and perception among the team (I'm seen as negative, and I don't want to foster a toxic workplace). If we have to make a decision, we usually do a little of both; we also never completely roll off of old practices.
The excuses I'm given for this go something like this:
- Why in this case things really did need to be different, but why we couldn't make a solution that was either documented or automatic.
- What team should've been responsible for documenting this, but were (inevitably) really busy or (my personal favorite) what obvious solution would've been better, now that I've hit one of the many edge cases in yet another poorly thought out solution.
- A stressful sigh, because I'm being unreasonable, thinking things should be standard in any way, and a phrase like "yeah, we really should work on that in the future" or "yeah, maybe we can fix that when [project touching that system] starts up"
How do I tell my team:
- I'm tired of excuses; we're all adults, and we should be able to work in an environment that isn't held up by the whims of whoever wanted a quick workaround instead of doing their job.
- We shouldn't accept this kind of environment. Think of how many workarounds just one senior person knows. How are we going to continue to function if new employees don't stick around to learn them all, and senior employees retire? We're going to pay for this tech debt one way or another some day.
- We really can fix this. It will be tedious, and we might step on some toes (everyone around here is cool with just slapping some (metaphorical) tape on it and waiting until it falls off again to take another look), but if we put some thought and diligence into our solutions we can slowly pay up some of this tech/process debt.
As an alternate solution, I see myself as having these options:
- Don't try to fix things. Make only the necessary changes. Try to document edge cases (either just for me or posterity somewhere), and avoid them.
- Go home and study and jump ship once the time feels right. Get on a team of people who solve problems instead of finding the workaround that requires the least amount of effort and just trying to remember that in the future.
- Work super hard to fix all these problems. Try to avoid pushback from people used to this way of working, and don't be discouraged when people that neither understand the problem nor have read your proposed solution say things like "if it ain't broke, don't fix it", meaning "if all we have to do is ask others to restart their servers from time to time, what's the big deal" or something similar.
These "solutions" are not mutually exclusive.
I don't feel like I can change this culture myself, and I like my immediate team, but it's super draining to constantly step in these mud puddles that real professionals would not tolerate.
Edit: I can't comment, so my responses to the comments are inline below:
Jimbo: that's a part of the third "option" I guess. Work diligently to document everything, make tickets so one day things might be fixed, and try not to get frustrated as the rabbit hole deepens.
Vietnhi Phuvan: I have no authority over this team. I'm not sure what you mean by meddling. I don't have a responsibility for fixing the software and processes that we work with each day, but it affects us all, and it affects our output. I have not "build a coalition". Others feel strongly about certain things, but usually just accept them and go on with their day-to-day work, or try to get resources to fix them. I'm not the only one ranting, but I am the most discouraged on my team; part of the problem is that "problem with an acceptable workaround" is no longer a problem to most people around here, and "acceptable workaround" means "any workaround". I'm working on a plan of action. I'm going to research how other companies solve these issues, why it's more effective to solve these problems instead of live with them, and come up with a clear upgrade path. Alternatively I'm going to build my skills until I can leave. The credibility I have has to do with the kinds of questions teammates already ask me.
Kent Anderson: Thanks for the thoughtful response. I'll try to stay positive in the future. The point that surprised me most was "try and understand how/why your teammates think like they do". Maybe I can figure out their motivations/process/intentions and be more effective.
P.S. I'm not the one always speaking up in meetings, in fact I've stopped almost completely, choosing instead to try to help form a consensus instead of trying to put new ideas on the table.
Finally I'd like to accept Kent's answer, but I've forgotten the first throwaway account's email :(. Thank you all for your comments. I'll work on this.
team culture apathy
edited Mar 30 '15 at 6:55
user209348243
32
asked Mar 28 '15 at 21:18
user209348234
251
closed as off-topic by Jim G., gnat, ChrisF, Chris E, Michael Grubey Mar 30 '15 at 18:14
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., gnat, ChrisF, Chris E, Michael Grubey
 |Â
show 1 more comment
up vote
3
down vote
favorite
At my new job I sometimes make mistakes. Usually these mistakes are because of assumptions I make based on other jobs I've had, other tools I've used, and other software I've developed on this very team.
Inevitably when we talk about what went wrong, I ask "Where is this information written down?" or "How can I avoid this in the future?" and the answer is always along the lines of "Remember that X in context Y is different than X in most other contexts". The lack of standardization on any practice is hurting my morale, productivity, and perception among the team (I'm seen as negative, and I don't want to foster a toxic workplace). If we have to make a decision, we usually do a little of both; we also never completely roll off of old practices.
The excuses I'm given for this go something like this:
- Why in this case things really did need to be different, but why we couldn't make a solution that was either documented or automatic.
- What team should've been responsible for documenting this, but were (inevitably) really busy or (my personal favorite) what obvious solution would've been better, now that I've hit one of the many edge cases in yet another poorly thought out solution.
- A stressful sigh, because I'm being unreasonable, thinking things should be standard in any way, and a phrase like "yeah, we really should work on that in the future" or "yeah, maybe we can fix that when [project touching that system] starts up"
How do I tell my team:
- I'm tired of excuses; we're all adults, and we should be able to work in an environment that isn't held up by the whims of whoever wanted a quick workaround instead of doing their job.
- We shouldn't accept this kind of environment. Think of how many workarounds just one senior person knows. How are we going to continue to function if new employees don't stick around to learn them all, and senior employees retire? We're going to pay for this tech debt one way or another some day.
- We really can fix this. It will be tedious, and we might step on some toes (everyone around here is cool with just slapping some (metaphorical) tape on it and waiting until it falls off again to take another look), but if we put some thought and diligence into our solutions we can slowly pay up some of this tech/process debt.
As an alternate solution, I see myself as having these options:
- Don't try to fix things. Make only the necessary changes. Try to document edge cases (either just for me or posterity somewhere), and avoid them.
- Go home and study and jump ship once the time feels right. Get on a team of people who solve problems instead of finding the workaround that requires the least amount of effort and just trying to remember that in the future.
- Work super hard to fix all these problems. Try to avoid pushback from people used to this way of working, and don't be discouraged when people that neither understand the problem nor have read your proposed solution say things like "if it ain't broke, don't fix it", meaning "if all we have to do is ask others to restart their servers from time to time, what's the big deal" or something similar.
These "solutions" are not mutually exclusive.
I don't feel like I can change this culture myself, and I like my immediate team, but it's super draining to constantly step in these mud puddles that real professionals would not tolerate.
Edit: I can't comment, so my responses to the comments are inline below:
Jimbo: that's a part of the third "option" I guess. Work diligently to document everything, make tickets so one day things might be fixed, and try not to get frustrated as the rabbit hole deepens.
Vietnhi Phuvan: I have no authority over this team. I'm not sure what you mean by meddling. I don't have a responsibility for fixing the software and processes that we work with each day, but it affects us all, and it affects our output. I have not "build a coalition". Others feel strongly about certain things, but usually just accept them and go on with their day-to-day work, or try to get resources to fix them. I'm not the only one ranting, but I am the most discouraged on my team; part of the problem is that "problem with an acceptable workaround" is no longer a problem to most people around here, and "acceptable workaround" means "any workaround". I'm working on a plan of action. I'm going to research how other companies solve these issues, why it's more effective to solve these problems instead of live with them, and come up with a clear upgrade path. Alternatively I'm going to build my skills until I can leave. The credibility I have has to do with the kinds of questions teammates already ask me.
Kent Anderson: Thanks for the thoughtful response. I'll try to stay positive in the future. The point that surprised me most was "try and understand how/why your teammates think like they do". Maybe I can figure out their motivations/process/intentions and be more effective.
P.S. I'm not the one always speaking up in meetings, in fact I've stopped almost completely, choosing instead to try to help form a consensus instead of trying to put new ideas on the table.
Finally I'd like to accept Kent's answer, but I've forgotten the first throwaway account's email :(. Thank you all for your comments. I'll work on this.
team culture apathy
edited Mar 30 '15 at 6:55
user209348243
32
asked Mar 28 '15 at 21:18
user209348234
251
closed as off-topic by Jim G., gnat, ChrisF, Chris E, Michael Grubey Mar 30 '15 at 18:14
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., gnat, ChrisF, Chris E, Michael Grubey
2
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
1
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
1
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
In software I have worked with,Where is X documented?is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.
– Brandon
Mar 29 '15 at 2:13
 |Â
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
At my new job I sometimes make mistakes. Usually these mistakes are because of assumptions I make based on other jobs I've had, other tools I've used, and other software I've developed on this very team.
Inevitably when we talk about what went wrong, I ask "Where is this information written down?" or "How can I avoid this in the future?" and the answer is always along the lines of "Remember that X in context Y is different than X in most other contexts". The lack of standardization on any practice is hurting my morale, productivity, and perception among the team (I'm seen as negative, and I don't want to foster a toxic workplace). If we have to make a decision, we usually do a little of both; we also never completely roll off of old practices.
The excuses I'm given for this go something like this:
- Why in this case things really did need to be different, but why we couldn't make a solution that was either documented or automatic.
- What team should've been responsible for documenting this, but were (inevitably) really busy or (my personal favorite) what obvious solution would've been better, now that I've hit one of the many edge cases in yet another poorly thought out solution.
- A stressful sigh, because I'm being unreasonable, thinking things should be standard in any way, and a phrase like "yeah, we really should work on that in the future" or "yeah, maybe we can fix that when [project touching that system] starts up"
How do I tell my team:
- I'm tired of excuses; we're all adults, and we should be able to work in an environment that isn't held up by the whims of whoever wanted a quick workaround instead of doing their job.
- We shouldn't accept this kind of environment. Think of how many workarounds just one senior person knows. How are we going to continue to function if new employees don't stick around to learn them all, and senior employees retire? We're going to pay for this tech debt one way or another some day.
- We really can fix this. It will be tedious, and we might step on some toes (everyone around here is cool with just slapping some (metaphorical) tape on it and waiting until it falls off again to take another look), but if we put some thought and diligence into our solutions we can slowly pay up some of this tech/process debt.
As an alternate solution, I see myself as having these options:
- Don't try to fix things. Make only the necessary changes. Try to document edge cases (either just for me or posterity somewhere), and avoid them.
- Go home and study and jump ship once the time feels right. Get on a team of people who solve problems instead of finding the workaround that requires the least amount of effort and just trying to remember that in the future.
- Work super hard to fix all these problems. Try to avoid pushback from people used to this way of working, and don't be discouraged when people that neither understand the problem nor have read your proposed solution say things like "if it ain't broke, don't fix it", meaning "if all we have to do is ask others to restart their servers from time to time, what's the big deal" or something similar.
These "solutions" are not mutually exclusive.
I don't feel like I can change this culture myself, and I like my immediate team, but it's super draining to constantly step in these mud puddles that real professionals would not tolerate.
Edit: I can't comment, so my responses to the comments are inline below:
Jimbo: that's a part of the third "option" I guess. Work diligently to document everything, make tickets so one day things might be fixed, and try not to get frustrated as the rabbit hole deepens.
Vietnhi Phuvan: I have no authority over this team. I'm not sure what you mean by meddling. I don't have a responsibility for fixing the software and processes that we work with each day, but it affects us all, and it affects our output. I have not "build a coalition". Others feel strongly about certain things, but usually just accept them and go on with their day-to-day work, or try to get resources to fix them. I'm not the only one ranting, but I am the most discouraged on my team; part of the problem is that "problem with an acceptable workaround" is no longer a problem to most people around here, and "acceptable workaround" means "any workaround". I'm working on a plan of action. I'm going to research how other companies solve these issues, why it's more effective to solve these problems instead of live with them, and come up with a clear upgrade path. Alternatively I'm going to build my skills until I can leave. The credibility I have has to do with the kinds of questions teammates already ask me.
Kent Anderson: Thanks for the thoughtful response. I'll try to stay positive in the future. The point that surprised me most was "try and understand how/why your teammates think like they do". Maybe I can figure out their motivations/process/intentions and be more effective.
P.S. I'm not the one always speaking up in meetings, in fact I've stopped almost completely, choosing instead to try to help form a consensus instead of trying to put new ideas on the table.
Finally I'd like to accept Kent's answer, but I've forgotten the first throwaway account's email :(. Thank you all for your comments. I'll work on this.
team culture apathy
edited Mar 30 '15 at 6:55
user209348243
32
asked Mar 28 '15 at 21:18
user209348234
251
At my new job I sometimes make mistakes. Usually these mistakes are because of assumptions I make based on other jobs I've had, other tools I've used, and other software I've developed on this very team.
Inevitably when we talk about what went wrong, I ask "Where is this information written down?" or "How can I avoid this in the future?" and the answer is always along the lines of "Remember that X in context Y is different than X in most other contexts". The lack of standardization on any practice is hurting my morale, productivity, and perception among the team (I'm seen as negative, and I don't want to foster a toxic workplace). If we have to make a decision, we usually do a little of both; we also never completely roll off of old practices.
The excuses I'm given for this go something like this:
- Why in this case things really did need to be different, but why we couldn't make a solution that was either documented or automatic.
- What team should've been responsible for documenting this, but were (inevitably) really busy or (my personal favorite) what obvious solution would've been better, now that I've hit one of the many edge cases in yet another poorly thought out solution.
- A stressful sigh, because I'm being unreasonable, thinking things should be standard in any way, and a phrase like "yeah, we really should work on that in the future" or "yeah, maybe we can fix that when [project touching that system] starts up"
How do I tell my team:
- I'm tired of excuses; we're all adults, and we should be able to work in an environment that isn't held up by the whims of whoever wanted a quick workaround instead of doing their job.
- We shouldn't accept this kind of environment. Think of how many workarounds just one senior person knows. How are we going to continue to function if new employees don't stick around to learn them all, and senior employees retire? We're going to pay for this tech debt one way or another some day.
- We really can fix this. It will be tedious, and we might step on some toes (everyone around here is cool with just slapping some (metaphorical) tape on it and waiting until it falls off again to take another look), but if we put some thought and diligence into our solutions we can slowly pay up some of this tech/process debt.
As an alternate solution, I see myself as having these options:
- Don't try to fix things. Make only the necessary changes. Try to document edge cases (either just for me or posterity somewhere), and avoid them.
- Go home and study and jump ship once the time feels right. Get on a team of people who solve problems instead of finding the workaround that requires the least amount of effort and just trying to remember that in the future.
- Work super hard to fix all these problems. Try to avoid pushback from people used to this way of working, and don't be discouraged when people that neither understand the problem nor have read your proposed solution say things like "if it ain't broke, don't fix it", meaning "if all we have to do is ask others to restart their servers from time to time, what's the big deal" or something similar.
These "solutions" are not mutually exclusive.
I don't feel like I can change this culture myself, and I like my immediate team, but it's super draining to constantly step in these mud puddles that real professionals would not tolerate.
Edit: I can't comment, so my responses to the comments are inline below:
Jimbo: that's a part of the third "option" I guess. Work diligently to document everything, make tickets so one day things might be fixed, and try not to get frustrated as the rabbit hole deepens.
Vietnhi Phuvan: I have no authority over this team. I'm not sure what you mean by meddling. I don't have a responsibility for fixing the software and processes that we work with each day, but it affects us all, and it affects our output. I have not "build a coalition". Others feel strongly about certain things, but usually just accept them and go on with their day-to-day work, or try to get resources to fix them. I'm not the only one ranting, but I am the most discouraged on my team; part of the problem is that "problem with an acceptable workaround" is no longer a problem to most people around here, and "acceptable workaround" means "any workaround". I'm working on a plan of action. I'm going to research how other companies solve these issues, why it's more effective to solve these problems instead of live with them, and come up with a clear upgrade path. Alternatively I'm going to build my skills until I can leave. The credibility I have has to do with the kinds of questions teammates already ask me.
Kent Anderson: Thanks for the thoughtful response. I'll try to stay positive in the future. The point that surprised me most was "try and understand how/why your teammates think like they do". Maybe I can figure out their motivations/process/intentions and be more effective.
P.S. I'm not the one always speaking up in meetings, in fact I've stopped almost completely, choosing instead to try to help form a consensus instead of trying to put new ideas on the table.
Finally I'd like to accept Kent's answer, but I've forgotten the first throwaway account's email :(. Thank you all for your comments. I'll work on this.
team culture apathy
edited Mar 30 '15 at 6:55
user209348243
32
asked Mar 28 '15 at 21:18
user209348234
251
edited Mar 30 '15 at 6:55
user209348243
32
edited Mar 30 '15 at 6:55
user209348243
32
edited Mar 30 '15 at 6:55
user209348243
32
32
asked Mar 28 '15 at 21:18
user209348234
251
asked Mar 28 '15 at 21:18
user209348234
251
asked Mar 28 '15 at 21:18
user209348234
251
251
closed as off-topic by Jim G., gnat, ChrisF, Chris E, Michael Grubey Mar 30 '15 at 18:14
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., gnat, ChrisF, Chris E, Michael Grubey
closed as off-topic by Jim G., gnat, ChrisF, Chris E, Michael Grubey Mar 30 '15 at 18:14
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., gnat, ChrisF, Chris E, Michael Grubey
2
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
1
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
1
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
In software I have worked with,Where is X documented?is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.
– Brandon
Mar 29 '15 at 2:13
 |Â
show 1 more comment
2
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
1
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
1
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
In software I have worked with,Where is X documented?is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.
– Brandon
Mar 29 '15 at 2:13
2
2
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
1
1
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
1
1
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
In software I have worked with,
Where is X documented? is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.– Brandon
Mar 29 '15 at 2:13
In software I have worked with,
Where is X documented? is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.– Brandon
Mar 29 '15 at 2:13
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
13
down vote
This is going to seem like I'm picking on you. I'm not, just trying to be objective...
Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.
Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)
I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.
If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.
Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
suggest improvements |Â
up vote
3
down vote
Put yourself in their shoes.
If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.
Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.
But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
suggest improvements |Â
up vote
2
down vote
In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
suggest improvements |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
This is going to seem like I'm picking on you. I'm not, just trying to be objective...
Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.
Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)
I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.
If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.
Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
suggest improvements |Â
up vote
13
down vote
This is going to seem like I'm picking on you. I'm not, just trying to be objective...
Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.
Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)
I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.
If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.
Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
suggest improvements |Â
up vote
13
down vote
up vote
13
down vote
This is going to seem like I'm picking on you. I'm not, just trying to be objective...
Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.
Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)
I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.
If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.
Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
This is going to seem like I'm picking on you. I'm not, just trying to be objective...
Be very careful about declaring everyone around you as unprofessional. It's not true, especially if they are veteran workers. As the new person on the team, you are likely unaware of the historical reasons they do things the way they do. Sure, there are unprofessional behaviors in the workplace. Complaining and accusing others of being unprofessional is one such example.
Does every meeting contain an element of you vocalizing that things are not what you wish they were? If so, there is some basis for your team to regard you as difficult or a complainer. If this is the case, try to identify a solution and offer to implement it for them. (Maintain a wiki page for the team, for example.)
I am sure you were much more positive when you first started working on this team, and now you are beaten down and fed up. Try to recover some of that positivity and tolerance you started with. You will be happier. Do what you can to try and understand how/why your teammates think like they do. Take personal notes you can review if you get into one of these areas where you think you might be "stepping into a puddle." Resist the urge to flash a page of notes as "proof" your team is being inconsistent or capricious. That never makes things better.
If you get to the point of bailing out (either from the team or from the company altogether), remember, there is no such thing as a team that does everything right, all the time. (What does "right" even mean in this setting?) Leaving might help you feel better, and might be the right thing for you to do. Just don't embark on a nomadic career searching for the perfect team. You won't find it.
Again, I'm not picking on you. I remember the frustrations I felt early on in my software development career because others did not measure up to my ideals, or to my "standard" of technical excellence. Patience, tolerance, and offering to help fix things are the best ways to ease your frustrations and encourage changes to be made.
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
answered Mar 28 '15 at 23:22
Kent A.
19.2k75575
19.2k75575
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
suggest improvements |Â
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
4
4
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
+1 You want to work with people. Passing judgment on them is not going to enhance the chances of getting a positive outcome. And if you start condemning them, your chances of getting crucified for your trouble skyrocket.
– Vietnhi Phuvan
Mar 29 '15 at 0:15
1
1
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
"there is no such thing as a team that does everything right, all the time." I don't think the OP expects things to be perfect.
– jcm
Mar 29 '15 at 5:46
suggest improvements |Â
up vote
3
down vote
Put yourself in their shoes.
If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.
Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.
But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
suggest improvements |Â
up vote
3
down vote
Put yourself in their shoes.
If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.
Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.
But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
Put yourself in their shoes.
If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.
Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.
But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
Put yourself in their shoes.
If the code base that you have to deal with is no good, they know about that. It is quite likely not because your new colleagues are not decent programmers, but because there is pressure to deliver things quicker than possible while doing a job properly. Things are not documented because someone couldn't hit a deadline and document what he was doing, and when he or she delivered at the deadline, new work came up before anyone could start with the documentation.
Some of them may have arrived at the company recently and had the exact same ideas that you have now, and then it turned out they couldn't do anything about it.
But what are they going to say if you say "your code is rubbish and needs changing"? The same thing that you would do in two years time of the next new addition to the time says exactly the same to you. They will be defensive. Nobody wants to admit that their work (through no fault of their own) is not the highest quality. If it is through their own fault, they will be even less likely to admit it.
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
answered Mar 30 '15 at 18:08
gnasher729
71k31131222
71k31131222
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
suggest improvements |Â
up vote
2
down vote
In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
In situations like this often the best solution is to simply find a new situation. Not all shops run like yours. There are development teams that strive actively for continuous improvement, that do not rely on individuals to remember obscure work-arounds or bizarre dependencies, that understand current best practices and follow them or have a very good reason to do something differently. In my long experience, shops like yours eventually go out of business. It may take a while, but eventually they will be overtaken by a smarter competitor. Now that you know the sort of place you do not enjoy working, you can be more careful about the next offer you accept.
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
answered Mar 30 '15 at 8:56
kevin cline
15.6k43861
15.6k43861
suggest improvements |Â
suggest improvements |Â
2
Seems like you need to start remembering these 'standards' - you could even document them yourself and start the trend :-)
– James
Mar 28 '15 at 21:23
1
Do you have any official authority on the team, or are you just meddling? Do you have a responsibility for designing the software development work flow, or are you just acting as a concerned citizen? Clearly, the team acknowledges that there are issues. However, it is just as clear that the team does not feel strongly about the issues to do something about the issues. If you are not a manager, have you built a coalition among the staff and management of individuals who feel exactly as you do and feel as strongly as you do, or are you currently the only one and ranting as the only one?
– Vietnhi Phuvan
Mar 28 '15 at 21:50
1
Have you come up with a workable plan of action that others can rally around or do you have exactly nothing going for you but indignation and self-righteousness? My take is that It is very unlikely that you are going to achieve anything all by yourself. Oh, you are new to the job, too. So the next question is, what credibility have you established with the team and the management in the short time since you started your job?
– Vietnhi Phuvan
Mar 28 '15 at 22:03
You are bothered by lack of consistency. In my experience, in software development, consistency is often the enemy of progress. I have seen very experienced developers choose "consistent" code versus "good" code. Would you rather have code that is consistently wrong or inconsistently right?
– Brandon
Mar 29 '15 at 2:11
In software I have worked with,
Where is X documented?is asked when a piece of code has surprises or confusing behaviors. I would contest on the grounds that the code should not have been full of surprises and should have been less confusingly written. But I feel your pain about documentation.– Brandon
Mar 29 '15 at 2:13