Mixing
How can a junior convince a senior developer to use object oriented concepts? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
13
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.
I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.
In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.
I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.
How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.
How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?
professionalism software-industry communication negotiation
asked Jul 6 '14 at 22:58
James
1,99511420
marked as duplicate by James, yochannah, Jane S♦, scaaahu, Community♦ Aug 3 '15 at 7:58
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 1 more comment
up vote
13
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.
I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.
In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.
I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.
How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.
How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?
professionalism software-industry communication negotiation
asked Jul 6 '14 at 22:58
James
1,99511420
marked as duplicate by James, yochannah, Jane S♦, scaaahu, Community♦ Aug 3 '15 at 7:58
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
10
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
2
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
1
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29
 |Â
show 1 more comment
up vote
13
down vote
favorite
up vote
13
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.
I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.
In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.
I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.
How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.
How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?
professionalism software-industry communication negotiation
asked Jul 6 '14 at 22:58
James
1,99511420
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.
I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.
In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.
I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.
How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.
How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
professionalism software-industry communication negotiation
asked Jul 6 '14 at 22:58
James
1,99511420
edited Aug 2 '15 at 14:29
asked Jul 6 '14 at 22:58
James
1,99511420
asked Jul 6 '14 at 22:58
James
1,99511420
asked Jul 6 '14 at 22:58
James
1,99511420
1,99511420
marked as duplicate by James, yochannah, Jane S♦, scaaahu, Community♦ Aug 3 '15 at 7:58
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by James, yochannah, Jane S♦, scaaahu, Community♦ Aug 3 '15 at 7:58
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
10
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
2
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
1
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29
 |Â
show 1 more comment
3
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
10
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
2
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
1
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29
3
3
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
10
10
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
2
2
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
1
1
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
20
down vote
accepted
You show them.
I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.
Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.
But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).
In my experience, people only really believe how easy/good something can be when they've actually used it themselves.
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
20
down vote
accepted
You show them.
I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.
Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.
But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).
In my experience, people only really believe how easy/good something can be when they've actually used it themselves.
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
suggest improvements |Â
up vote
20
down vote
accepted
You show them.
I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.
Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.
But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).
In my experience, people only really believe how easy/good something can be when they've actually used it themselves.
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
suggest improvements |Â
up vote
20
down vote
accepted
up vote
20
down vote
accepted
You show them.
I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.
Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.
But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).
In my experience, people only really believe how easy/good something can be when they've actually used it themselves.
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
You show them.
I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.
Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.
But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).
In my experience, people only really believe how easy/good something can be when they've actually used it themselves.
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
edited Jul 7 '14 at 0:18
Aaron Hall
4,16312033
4,16312033
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
answered Jul 6 '14 at 23:12
Telastyn
33.9k977120
33.9k977120
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
suggest improvements |Â
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
2
2
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
– dwjohnston
Aug 3 '15 at 0:01
3
3
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
– James
Sep 29 '15 at 12:48
1
1
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
– Lightness Races in Orbit
Apr 25 '16 at 11:44
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
@LightnessRacesinOrbit You're not wrong!
– James
Jul 31 '16 at 19:29
suggest improvements |Â
3
One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
– SJuan76
Jul 6 '14 at 23:46
10
There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
– gnasher729
Jul 7 '14 at 1:35
2
Have a look at this blog post
– DJClayworth
Jul 7 '14 at 20:14
Hmm, I think this question could be abstracted out a little more to be about convincing someone with more experience of any concept - which I'm sure has already been asked before (this isn't a software engineering specific site...) :-)
– James
Aug 2 '15 at 14:51
1
Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
– keshlam
Aug 3 '15 at 13:29