Mixing
![How to deal with a uncommitted coworker, it affects my performance too [duplicate]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How to work with senior staff who are averse to new ideas? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
My senior developers have around almost a decade of experience. They are open-minded to whatever THEY believe is good. They also lack interest in general problem solving and are not interested in learning.
There's also an ego problem along with this. I am poor in arguments and discussions therefore, I get easily pushed even in discussions on matters that I have researched thoroughly. This is primarily for the fact that I open the discussion showing that I might not be completely right hoping to get the words heard. In addition, the discussion often gets overturned with my own words echoed back at me, e.g., "that's what I've been telling you!", "so you understand now.". This also means I don't get credit for matters I proposed. Even when casually reviewing, they respond with "yeah yeah, I know", "was gonna do it.", etc.
Their limited horizon of experience and ego issues, I believe, is hurting the projects we work upon. For example, someone with such experience not having learned about symlinks. We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory. They're not to get the entire blame but the way things are structured it's tough for someone new like me.
We will be working on a new project soon and I have suggested the use for a native-hybrid app stack but have felt that I might regret this decision. I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
My questions here are:
- How do you deal with individuals that are unwilling to credit you for your proposal?
- Do what's best for the job at hand ignoring under-appreciation?
professionalism learning
asked Sep 5 '16 at 4:01
Display Name
94
closed as off-topic by Masked Man♦, gnat, Richard U, Michael Grubey, jimm101 Sep 9 '16 at 1:21
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – Masked Man, gnat, Richard U, Michael Grubey, jimm101
 |Â
show 3 more comments
up vote
0
down vote
favorite
My senior developers have around almost a decade of experience. They are open-minded to whatever THEY believe is good. They also lack interest in general problem solving and are not interested in learning.
There's also an ego problem along with this. I am poor in arguments and discussions therefore, I get easily pushed even in discussions on matters that I have researched thoroughly. This is primarily for the fact that I open the discussion showing that I might not be completely right hoping to get the words heard. In addition, the discussion often gets overturned with my own words echoed back at me, e.g., "that's what I've been telling you!", "so you understand now.". This also means I don't get credit for matters I proposed. Even when casually reviewing, they respond with "yeah yeah, I know", "was gonna do it.", etc.
Their limited horizon of experience and ego issues, I believe, is hurting the projects we work upon. For example, someone with such experience not having learned about symlinks. We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory. They're not to get the entire blame but the way things are structured it's tough for someone new like me.
We will be working on a new project soon and I have suggested the use for a native-hybrid app stack but have felt that I might regret this decision. I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
My questions here are:
- How do you deal with individuals that are unwilling to credit you for your proposal?
- Do what's best for the job at hand ignoring under-appreciation?
professionalism learning
asked Sep 5 '16 at 4:01
Display Name
94
closed as off-topic by Masked Man♦, gnat, Richard U, Michael Grubey, jimm101 Sep 9 '16 at 1:21
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – Masked Man, gnat, Richard U, Michael Grubey, jimm101
8
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
1
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
1
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
6
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47
 |Â
show 3 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
My senior developers have around almost a decade of experience. They are open-minded to whatever THEY believe is good. They also lack interest in general problem solving and are not interested in learning.
There's also an ego problem along with this. I am poor in arguments and discussions therefore, I get easily pushed even in discussions on matters that I have researched thoroughly. This is primarily for the fact that I open the discussion showing that I might not be completely right hoping to get the words heard. In addition, the discussion often gets overturned with my own words echoed back at me, e.g., "that's what I've been telling you!", "so you understand now.". This also means I don't get credit for matters I proposed. Even when casually reviewing, they respond with "yeah yeah, I know", "was gonna do it.", etc.
Their limited horizon of experience and ego issues, I believe, is hurting the projects we work upon. For example, someone with such experience not having learned about symlinks. We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory. They're not to get the entire blame but the way things are structured it's tough for someone new like me.
We will be working on a new project soon and I have suggested the use for a native-hybrid app stack but have felt that I might regret this decision. I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
My questions here are:
- How do you deal with individuals that are unwilling to credit you for your proposal?
- Do what's best for the job at hand ignoring under-appreciation?
professionalism learning
asked Sep 5 '16 at 4:01
Display Name
94
My senior developers have around almost a decade of experience. They are open-minded to whatever THEY believe is good. They also lack interest in general problem solving and are not interested in learning.
There's also an ego problem along with this. I am poor in arguments and discussions therefore, I get easily pushed even in discussions on matters that I have researched thoroughly. This is primarily for the fact that I open the discussion showing that I might not be completely right hoping to get the words heard. In addition, the discussion often gets overturned with my own words echoed back at me, e.g., "that's what I've been telling you!", "so you understand now.". This also means I don't get credit for matters I proposed. Even when casually reviewing, they respond with "yeah yeah, I know", "was gonna do it.", etc.
Their limited horizon of experience and ego issues, I believe, is hurting the projects we work upon. For example, someone with such experience not having learned about symlinks. We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory. They're not to get the entire blame but the way things are structured it's tough for someone new like me.
We will be working on a new project soon and I have suggested the use for a native-hybrid app stack but have felt that I might regret this decision. I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
My questions here are:
- How do you deal with individuals that are unwilling to credit you for your proposal?
- Do what's best for the job at hand ignoring under-appreciation?
professionalism learning
asked Sep 5 '16 at 4:01
Display Name
94
edited Sep 9 '16 at 5:27
asked Sep 5 '16 at 4:01
Display Name
94
asked Sep 5 '16 at 4:01
Display Name
94
asked Sep 5 '16 at 4:01
Display Name
94
94
closed as off-topic by Masked Man♦, gnat, Richard U, Michael Grubey, jimm101 Sep 9 '16 at 1:21
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – Masked Man, gnat, Richard U, Michael Grubey, jimm101
closed as off-topic by Masked Man♦, gnat, Richard U, Michael Grubey, jimm101 Sep 9 '16 at 1:21
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – Masked Man, gnat, Richard U, Michael Grubey, jimm101
8
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
1
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
1
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
6
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47
 |Â
show 3 more comments
8
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
1
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
1
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
6
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47
8
8
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
1
1
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
1
1
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
6
6
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47
 |Â
show 3 more comments
4 Answers
4
active
oldest
votes
up vote
7
down vote
If it ain't broke, don't fix it.
We do get stuff done, but one will quickly realize that the models
have not been structured properly, making the work done less
satisfactory.
"We do get stuff done" is a very, very good thing.
"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.
The gain from the proposed change has to outweigh the costs of adding another framework etc.
If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.
There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
i would adddon't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with thebut do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.
– Walfrat
Sep 6 '16 at 6:40
suggest improvements |Â
up vote
4
down vote
As a developer I'll make a rather controversial answer that probably some won't like but here I go.
They also lack interest in their job
As long what they're paid for is done there is professionally nothing wrong here.
and are not interested in learning
Every people working are not passionate about their job.
Linux OS had no idea about symlinks
For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.
I would love to try a lot of new things such as FP in this
I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.
Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.
Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.
If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.
answered Sep 5 '16 at 14:37
Walfrat
1,194615
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
suggest improvements |Â
up vote
3
down vote
As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.
If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.
I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.
Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.
To answer your two questions directly:
Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.
How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.
If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
suggest improvements |Â
up vote
2
down vote
As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).
As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.
As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.
Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.
Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
suggest improvements |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
If it ain't broke, don't fix it.
We do get stuff done, but one will quickly realize that the models
have not been structured properly, making the work done less
satisfactory.
"We do get stuff done" is a very, very good thing.
"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.
The gain from the proposed change has to outweigh the costs of adding another framework etc.
If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.
There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
i would adddon't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with thebut do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.
– Walfrat
Sep 6 '16 at 6:40
suggest improvements |Â
up vote
7
down vote
If it ain't broke, don't fix it.
We do get stuff done, but one will quickly realize that the models
have not been structured properly, making the work done less
satisfactory.
"We do get stuff done" is a very, very good thing.
"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.
The gain from the proposed change has to outweigh the costs of adding another framework etc.
If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.
There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
i would adddon't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with thebut do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.
– Walfrat
Sep 6 '16 at 6:40
suggest improvements |Â
up vote
7
down vote
up vote
7
down vote
If it ain't broke, don't fix it.
We do get stuff done, but one will quickly realize that the models
have not been structured properly, making the work done less
satisfactory.
"We do get stuff done" is a very, very good thing.
"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.
The gain from the proposed change has to outweigh the costs of adding another framework etc.
If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.
There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
If it ain't broke, don't fix it.
We do get stuff done, but one will quickly realize that the models
have not been structured properly, making the work done less
satisfactory.
"We do get stuff done" is a very, very good thing.
"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.
The gain from the proposed change has to outweigh the costs of adding another framework etc.
If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.
There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
answered Sep 5 '16 at 17:10
Patricia Shanahan
16.2k53256
16.2k53256
i would adddon't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with thebut do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.
– Walfrat
Sep 6 '16 at 6:40
suggest improvements |Â
i would adddon't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with thebut do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.
– Walfrat
Sep 6 '16 at 6:40
i would add
don't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with the but do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.– Walfrat
Sep 6 '16 at 6:40
i would add
don't replace something working by trying something new to replace it, only by something else working better. And I don't really agree with the but do that on your own time, you can just have working time dedicated to that on when there is some time. Just don't push new things on a on-going project. just learn it enough to be able to use it right on a project.– Walfrat
Sep 6 '16 at 6:40
suggest improvements |Â
up vote
4
down vote
As a developer I'll make a rather controversial answer that probably some won't like but here I go.
They also lack interest in their job
As long what they're paid for is done there is professionally nothing wrong here.
and are not interested in learning
Every people working are not passionate about their job.
Linux OS had no idea about symlinks
For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.
I would love to try a lot of new things such as FP in this
I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.
Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.
Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.
If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.
answered Sep 5 '16 at 14:37
Walfrat
1,194615
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
suggest improvements |Â
up vote
4
down vote
As a developer I'll make a rather controversial answer that probably some won't like but here I go.
They also lack interest in their job
As long what they're paid for is done there is professionally nothing wrong here.
and are not interested in learning
Every people working are not passionate about their job.
Linux OS had no idea about symlinks
For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.
I would love to try a lot of new things such as FP in this
I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.
Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.
Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.
If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.
answered Sep 5 '16 at 14:37
Walfrat
1,194615
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
As a developer I'll make a rather controversial answer that probably some won't like but here I go.
They also lack interest in their job
As long what they're paid for is done there is professionally nothing wrong here.
and are not interested in learning
Every people working are not passionate about their job.
Linux OS had no idea about symlinks
For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.
I would love to try a lot of new things such as FP in this
I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.
Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.
Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.
If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.
answered Sep 5 '16 at 14:37
Walfrat
1,194615
As a developer I'll make a rather controversial answer that probably some won't like but here I go.
They also lack interest in their job
As long what they're paid for is done there is professionally nothing wrong here.
and are not interested in learning
Every people working are not passionate about their job.
Linux OS had no idea about symlinks
For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.
I would love to try a lot of new things such as FP in this
I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.
Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.
Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.
If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.
answered Sep 5 '16 at 14:37
Walfrat
1,194615
edited Sep 6 '16 at 6:32
answered Sep 5 '16 at 14:37
Walfrat
1,194615
answered Sep 5 '16 at 14:37
Walfrat
1,194615
answered Sep 5 '16 at 14:37
Walfrat
1,194615
1,194615
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
suggest improvements |Â
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
1
1
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
Symlinks in Unix are more like junctions in Windows, not shortcuts. msdn.microsoft.com/en-us/library/windows/desktop/… This distinction is actually very important.
– Stephan Branczyk
Sep 5 '16 at 15:53
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
@StephanBranczyk well to be honest i didn't even know about junction on windows, since i learned on Linux. But it was just to get non IT people the idea. I'll fix it.
– Walfrat
Sep 6 '16 at 6:30
suggest improvements |Â
up vote
3
down vote
As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.
If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.
I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.
Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.
To answer your two questions directly:
Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.
How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.
If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
suggest improvements |Â
up vote
3
down vote
As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.
If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.
I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.
Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.
To answer your two questions directly:
Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.
How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.
If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.
If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.
I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.
Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.
To answer your two questions directly:
Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.
How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.
If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.
If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.
I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.
What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.
Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.
To answer your two questions directly:
Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.
How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.
If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
answered Sep 6 '16 at 21:04
Richard U
77.2k56200307
77.2k56200307
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
suggest improvements |Â
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
We are actually building a new app and this time it's going to be with a cross-platform Javascript framework. I understand what you mean sir, but for reasons unknown, they present arguments and exhibit lack of having learned anything proper or new. For instance, it's quite shocking for a someone with such an experience to claim method chaining is not possible in their language, they're not using anything uncommon here. Thing is, I don't want to be pushed around by people who hardly have knowledge yet claim so. I fear this will be the case once more.
– Display Name
Sep 9 '16 at 3:48
suggest improvements |Â
up vote
2
down vote
As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).
As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.
As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.
Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.
Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
suggest improvements |Â
up vote
2
down vote
As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).
As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.
As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.
Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.
Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).
As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.
As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.
Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.
Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).
As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.
As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.
Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.
Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
answered Sep 6 '16 at 20:48
VaeInimicus
1,231312
1,231312
suggest improvements |Â
suggest improvements |Â
8
What's your role in the team? If you are the manager, then you have control. If you're a junior developer, than perhaps it may be worth trying to learn from your seniors. You might find that they are willing to listen if you are :)
– Jane S♦
Sep 5 '16 at 4:08
@JaneS junior developer, you are correct, during discussions I place my opinions/arguments in doubt with openness to criticism because I intend to learn and improve, but there are certain moments that you are 100% sure of what you're talking about but you end up looking schooled with whatever you just said, not to say they haven't taught me anything, they have, but I hate to lose on arguments that way and even not see your opinions get the consideration sometimes.
– Display Name
Sep 5 '16 at 4:17
1
How long have you worked there for? What components/sub-projects have you successfully completed during your time there? You may also find that it will take some time for more senior people to respect your professional opinion.
– Jane S♦
Sep 5 '16 at 4:26
1
This sounds more like a communications problem than anything else. Perhaps they tell you what you tell them because, in fact, they do already understand it (though they may disagree about its applicability). Remember that even desirable changes may be difficult to adopt in an established code base.
– keshlam
Sep 5 '16 at 6:49
6
Every framework you add to the set in use adds recruitment, training, and maintenance costs. Ideally, you want to work with a small set that covers what you need. To add a framework, you don't just have to show it is a better choice for the specific program. You have to show it is enough better to outweigh the cost of adding it. Have you been doing that?
– Patricia Shanahan
Sep 5 '16 at 7:47