Mixing
As an intern, how do I approach the team regarding improving code quality?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I am a Software Engineering intern at a big company.
Few weeks back, I was given a simple task to do, imitating the behavior of another component.
Reading the code, I found the current implementation rather flawed. It was introducing tight coupling between components, and the effort put on it looked rather redundant: additions to the codebase would result in duplication of work.
I came up with an alternative solution, using a different library, which would extremely reduce future repetition, at its own costs:
- Nobody else knows how to work with it, so I am pretty much on my own.
- It is not implemented elsewhere within the team, so I have to "decide" the best practices on my own.
- Most importantly, unexpected problems are coming up every now and then, which are delaying the supposed "3-day work".
I'm pretty much sure this implementation would save months of developer effort, but I also feel bad delaying the 3 days' work (though we don't seem to be having hard client deadline on us).
How do I approach my team about improving the code quality? I want to make this work, but make sure I've considered the rest of the team.
software-industry internship team
edited Apr 20 '16 at 16:14
Anko
1136
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
suggest improvements |Â
up vote
4
down vote
favorite
I am a Software Engineering intern at a big company.
Few weeks back, I was given a simple task to do, imitating the behavior of another component.
Reading the code, I found the current implementation rather flawed. It was introducing tight coupling between components, and the effort put on it looked rather redundant: additions to the codebase would result in duplication of work.
I came up with an alternative solution, using a different library, which would extremely reduce future repetition, at its own costs:
- Nobody else knows how to work with it, so I am pretty much on my own.
- It is not implemented elsewhere within the team, so I have to "decide" the best practices on my own.
- Most importantly, unexpected problems are coming up every now and then, which are delaying the supposed "3-day work".
I'm pretty much sure this implementation would save months of developer effort, but I also feel bad delaying the 3 days' work (though we don't seem to be having hard client deadline on us).
How do I approach my team about improving the code quality? I want to make this work, but make sure I've considered the rest of the team.
software-industry internship team
edited Apr 20 '16 at 16:14
Anko
1136
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
3
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05
suggest improvements |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I am a Software Engineering intern at a big company.
Few weeks back, I was given a simple task to do, imitating the behavior of another component.
Reading the code, I found the current implementation rather flawed. It was introducing tight coupling between components, and the effort put on it looked rather redundant: additions to the codebase would result in duplication of work.
I came up with an alternative solution, using a different library, which would extremely reduce future repetition, at its own costs:
- Nobody else knows how to work with it, so I am pretty much on my own.
- It is not implemented elsewhere within the team, so I have to "decide" the best practices on my own.
- Most importantly, unexpected problems are coming up every now and then, which are delaying the supposed "3-day work".
I'm pretty much sure this implementation would save months of developer effort, but I also feel bad delaying the 3 days' work (though we don't seem to be having hard client deadline on us).
How do I approach my team about improving the code quality? I want to make this work, but make sure I've considered the rest of the team.
software-industry internship team
edited Apr 20 '16 at 16:14
Anko
1136
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
I am a Software Engineering intern at a big company.
Few weeks back, I was given a simple task to do, imitating the behavior of another component.
Reading the code, I found the current implementation rather flawed. It was introducing tight coupling between components, and the effort put on it looked rather redundant: additions to the codebase would result in duplication of work.
I came up with an alternative solution, using a different library, which would extremely reduce future repetition, at its own costs:
- Nobody else knows how to work with it, so I am pretty much on my own.
- It is not implemented elsewhere within the team, so I have to "decide" the best practices on my own.
- Most importantly, unexpected problems are coming up every now and then, which are delaying the supposed "3-day work".
I'm pretty much sure this implementation would save months of developer effort, but I also feel bad delaying the 3 days' work (though we don't seem to be having hard client deadline on us).
How do I approach my team about improving the code quality? I want to make this work, but make sure I've considered the rest of the team.
software-industry internship team
edited Apr 20 '16 at 16:14
Anko
1136
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
edited Apr 20 '16 at 16:14
Anko
1136
edited Apr 20 '16 at 16:14
Anko
1136
edited Apr 20 '16 at 16:14
Anko
1136
1136
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
asked Apr 20 '16 at 14:07
Akshay Arora
1,04349
1,04349
3
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05
suggest improvements |Â
3
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05
3
3
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
6
down vote
accepted
You really need to ask your team and/or manager.
Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.
As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.
It sounds like you've found a good fix. I hope you can convince your team.
@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.
As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.
The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
suggest improvements |Â
up vote
1
down vote
Reading the code, I found the current implementation rather flawed
Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).
Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.
Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.
Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).
I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.
answered Apr 20 '16 at 19:18
numenor
17510
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
You really need to ask your team and/or manager.
Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.
As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.
It sounds like you've found a good fix. I hope you can convince your team.
@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.
As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.
The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
suggest improvements |Â
up vote
6
down vote
accepted
You really need to ask your team and/or manager.
Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.
As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.
It sounds like you've found a good fix. I hope you can convince your team.
@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.
As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.
The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
suggest improvements |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
You really need to ask your team and/or manager.
Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.
As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.
It sounds like you've found a good fix. I hope you can convince your team.
@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.
As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.
The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
You really need to ask your team and/or manager.
Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.
As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.
It sounds like you've found a good fix. I hope you can convince your team.
@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.
As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.
The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
edited Apr 20 '16 at 14:53
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
answered Apr 20 '16 at 14:17
Dan Pichelman
24.5k116682
24.5k116682
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
suggest improvements |Â
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
How should the OP go about convincing the team since they are only an intern?
– IDrinkandIKnowThings
Apr 20 '16 at 14:18
3
3
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
I think OP should finish the work he was assigned before mentioning this new idea. This will inspire more confidence and may leave some "opening" to allow trying out his new proposal.
– Brandin
Apr 20 '16 at 14:20
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
@Brandin - You should include that in your answer...
– IDrinkandIKnowThings
Apr 20 '16 at 14:40
1
1
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
"As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better." This times 1,000.
– Andrew Whatever
Apr 20 '16 at 20:39
suggest improvements |Â
up vote
1
down vote
Reading the code, I found the current implementation rather flawed
Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).
Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.
Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.
Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).
I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.
answered Apr 20 '16 at 19:18
numenor
17510
suggest improvements |Â
up vote
1
down vote
Reading the code, I found the current implementation rather flawed
Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).
Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.
Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.
Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).
I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.
answered Apr 20 '16 at 19:18
numenor
17510
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
Reading the code, I found the current implementation rather flawed
Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).
Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.
Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.
Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).
I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.
answered Apr 20 '16 at 19:18
numenor
17510
Reading the code, I found the current implementation rather flawed
Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).
Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.
Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.
Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).
I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.
answered Apr 20 '16 at 19:18
numenor
17510
answered Apr 20 '16 at 19:18
numenor
17510
answered Apr 20 '16 at 19:18
numenor
17510
answered Apr 20 '16 at 19:18
numenor
17510
17510
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f65549%2fas-an-intern-how-do-i-approach-the-team-regarding-improving-code-quality%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
3
Complete the required work first without adding the new library (after all, it will only take a few days). Afterwards, consider your new library implementation as a separate project to get approval on based on benefit (saving future work, more maintainability, etc.).
– Brandin
Apr 20 '16 at 14:18
@Brandin Please flush that comment out into an answer. I think it would be the best if you do it right.
– IDrinkandIKnowThings
Apr 20 '16 at 19:05