Mixing
![Grad student accepts internship offer and is contacted and offered dream internship elsewhere right before starting [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How to deal with a manager who doesn't follow process
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I'm a software developer and we've recently implemented code reviews. The process should go like this:
- The developer submits a pull request.
- The developer's partner reviews the code, and approves it/leaves suggestions
- Once the partner has approved it, one of our two managers/admins approves it and it can then be merged into our main branch
The problem is, as we near our deadline, one of the managers constantly removes me from my partner's PR review lists, approves it, and merges the code in without reading it. My partner was hired as a senior developer (but has worked on this codebase for less time than me) but based on what I've read/questions asked writes infinite loops and is unaware how classes are instantiated. If I'm not able to get to the code review within an hour or two (which I don't find unreasonable), I will often then see that it has been approved/merged without my input. This obviously causes issues down the line.
How do I approach my manager about this situation without seeming like I'm attacking the other more senior developer?
**Non technical version: ** We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking. How do I deal with this?
manager software-development
asked Jan 29 '16 at 1:57
Daniel
1133
suggest improvements |Â
up vote
2
down vote
favorite
I'm a software developer and we've recently implemented code reviews. The process should go like this:
- The developer submits a pull request.
- The developer's partner reviews the code, and approves it/leaves suggestions
- Once the partner has approved it, one of our two managers/admins approves it and it can then be merged into our main branch
The problem is, as we near our deadline, one of the managers constantly removes me from my partner's PR review lists, approves it, and merges the code in without reading it. My partner was hired as a senior developer (but has worked on this codebase for less time than me) but based on what I've read/questions asked writes infinite loops and is unaware how classes are instantiated. If I'm not able to get to the code review within an hour or two (which I don't find unreasonable), I will often then see that it has been approved/merged without my input. This obviously causes issues down the line.
How do I approach my manager about this situation without seeming like I'm attacking the other more senior developer?
**Non technical version: ** We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking. How do I deal with this?
manager software-development
asked Jan 29 '16 at 1:57
Daniel
1133
1
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm a software developer and we've recently implemented code reviews. The process should go like this:
- The developer submits a pull request.
- The developer's partner reviews the code, and approves it/leaves suggestions
- Once the partner has approved it, one of our two managers/admins approves it and it can then be merged into our main branch
The problem is, as we near our deadline, one of the managers constantly removes me from my partner's PR review lists, approves it, and merges the code in without reading it. My partner was hired as a senior developer (but has worked on this codebase for less time than me) but based on what I've read/questions asked writes infinite loops and is unaware how classes are instantiated. If I'm not able to get to the code review within an hour or two (which I don't find unreasonable), I will often then see that it has been approved/merged without my input. This obviously causes issues down the line.
How do I approach my manager about this situation without seeming like I'm attacking the other more senior developer?
**Non technical version: ** We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking. How do I deal with this?
manager software-development
asked Jan 29 '16 at 1:57
Daniel
1133
I'm a software developer and we've recently implemented code reviews. The process should go like this:
- The developer submits a pull request.
- The developer's partner reviews the code, and approves it/leaves suggestions
- Once the partner has approved it, one of our two managers/admins approves it and it can then be merged into our main branch
The problem is, as we near our deadline, one of the managers constantly removes me from my partner's PR review lists, approves it, and merges the code in without reading it. My partner was hired as a senior developer (but has worked on this codebase for less time than me) but based on what I've read/questions asked writes infinite loops and is unaware how classes are instantiated. If I'm not able to get to the code review within an hour or two (which I don't find unreasonable), I will often then see that it has been approved/merged without my input. This obviously causes issues down the line.
How do I approach my manager about this situation without seeming like I'm attacking the other more senior developer?
**Non technical version: ** We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking. How do I deal with this?
manager software-development
asked Jan 29 '16 at 1:57
Daniel
1133
asked Jan 29 '16 at 1:57
Daniel
1133
asked Jan 29 '16 at 1:57
Daniel
1133
asked Jan 29 '16 at 1:57
Daniel
1133
1133
1
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17
suggest improvements |Â
1
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17
1
1
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17
suggest improvements |Â
5 Answers
5
active
oldest
votes
up vote
1
down vote
accepted
Few points to convey to your manager and team mate:
Quality: You should be the voice of quality when you talk to your manager. Even if a deadline is approaching, poor processes only lead to poor quality
User error / Knowing ones code too well: This can very well cause even a senior developer to make silly mistakes in the design approach and even sometimes basic Java practices around writing code. Thus, it is a must that at least 1 more pair of eyes go through the code change so that such things can be identified and fixed.
"We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking.": Seniority can cause this kind of an attitude in people, which is a different battle, but the least you can say is that another senior developer be added to your colleagues code reviews if not a junior (don't mention you as the one being junior. That may sound as though you are taking this personally).
If none of this works, don't fret. It's important you keep up your good work and don't become a person who disregards processes. You follow them. All the best!
edited Jan 29 '16 at 11:01
James Fenwick
204311
answered Jan 29 '16 at 6:08
shyla
447159
suggest improvements |Â
up vote
9
down vote
Do something radical and talk to your manager, without accusing anyone of anything. "Hey, I see you approved X, Y, and Z. I thought I was responsible for those -- did you take them because there's something I need to get better at, or did you just have some spare time to work on them? We should coordinate this better to make sure we aren't wasting resources by having unnecessary parallel reviewing."
Then listen. Carefully. Whether you agree or not, what you're told is going to he the actual process as implemented. It may not be the one you're assuming. In particular there may be no ownership of reviewing tasks; it may be assigned to you to make sure it gets done, but others may be actively encouraged to help out when time permits.
Remember that the system tracks approvals. If your manager says code is OK and it isn't, you will not be blamed for that; management and the other coder will handle it appropriately, and one or both of them will learn from the experience. The system is working; let it work.
As far as your doubts about the other people's work goes... we can't tell from here if you are right about your concerns or not. I suggest pausing for a moment to consider that just maybe your manager did review the changes befire approving them, and that maybe your problems with the other coder's work are more a matter of misunderstanding and of different styles of approaching the problem rather that their code necessarily being worse. Maybe that loop isn't infinite after all, but merely exits differently than it would have had you written it. Or maybe it was, but everyone makes a mistake once in a while and you shouldn't assume they will continue to make that mistake
Don't tell people they're wrong. Tell them you're not sure you understand, and ask them to explain why they're right. Even if they aren't -- especially if they aren't -- this is a far more polite way to open the discussion. And it keeps you from embarassing yourself if they do have a good answer.
Don't contend. Collaborate.
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
suggest improvements |Â
up vote
3
down vote
The reviewer has the responsibility to make sure that the code is of acceptable quality. That's what you would make sure of if you were the reviewer. Since your boss is the reviewer, it's his responsibility that your co-workers code is of acceptable quality when checked in, not your responsibility, and not your co-worker's.
That needs to be made clear to the boss. If you end up shipping a product with severe defects, and it costs your company money, then you are not to blame, nor is your co-worker (even if his code caused the fault, because the real cause of the fault is the incompetent review), it's your bosses fault entirely.
Senior or junior doesn't make a difference. People make mistakes, whether junior or senior, just different mistakes. Reviews catch them. If the boss decides to do incompetent reviews, any problems coming from this are his fault.
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
suggest improvements |Â
up vote
0
down vote
Not sure you want to try too hard to manipulate your manager. He has decided to take the risk and let potentially bad code go into production. Who knows, he could get lucky.
When you are required to debug, enhance or alter the code, you should consider padding your estimates on code you haven't reviewed because in a way, you need to do the review now.
Again, your boss will have to decide how to address the extra time you're taking. I would make sure you document these situations. I don't know if you want to get into any details on the quality of the code or lack of skills by the other developer. If your boss feels threatened by all this, he'll make excuses to defend his actions and the capabilities of the other person and put more blame on you or just tell you to stop taking so long (i.e perform magic).
Maybe the manager will see the error of his ways or at least the other programmer.
suggest improvements |Â
up vote
0
down vote
I feel like there are a couple of issues with this approach...
Pick your battles.
I understand how annoying it is when someone else you work with writes bad code. It makes everyone else in your department look bad because end users tend not to understand the difference between a bad UI and a good backend, for example. That being said, you really ought to review with yourself whether or not this particular issue is worth spending relationship capital with this supervisor (or whomever else you have to turn to). Along the same lines...
Try to keep your circle of concern within your circle of influence.
Sorry to get all Stephen Covey here but I think this applies. According to the rules as written, you have a distinct vertical in place. You are supposed to review this other guy's code, but when someone else comes by and marks it off as approved, you no longer have either the need nor the authority to review said code anymore. It's outside of your circle of influence, and hard as this may sound, you kind of need to push it outside of your circle of concern as well for the sake of your own sanity.
If the system as is happening is failing right now, consider allowing it to fail once or twice.
Consider this: your partner puts something into the code that you know is going to eventually cause your solution to crash (I'm a little bit skeptical of the "infinite loop" thing that was proposed in the comments, as most modern IDEs won't even compile if you do that, but certainly the general concept of putting out untested/sloppy code exists) and said code gets approved and follows the path to production. What happens when the bug is caught? If people are coming to you asking how you let it through, you should have a chain of evidence that says that you did not, in fact, touch or otherwise approve said code.
On the other hand, if it ain't broke, don't fix it.
I've also run into some pretty damn inflexible developers in my day to be honest. What is "broken" to one person is simply "another way of doing things" to another. If you saw a bug and the bug never actually fired, is it really a bug, or did someone else just come up with a different style of fixing the issue than you did? If it performs worse than your way, then that may be an opportunity to say "well, I would have done this like X", but the reality of programming is that there is rarely only one proper way to fix things.
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Few points to convey to your manager and team mate:
Quality: You should be the voice of quality when you talk to your manager. Even if a deadline is approaching, poor processes only lead to poor quality
User error / Knowing ones code too well: This can very well cause even a senior developer to make silly mistakes in the design approach and even sometimes basic Java practices around writing code. Thus, it is a must that at least 1 more pair of eyes go through the code change so that such things can be identified and fixed.
"We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking.": Seniority can cause this kind of an attitude in people, which is a different battle, but the least you can say is that another senior developer be added to your colleagues code reviews if not a junior (don't mention you as the one being junior. That may sound as though you are taking this personally).
If none of this works, don't fret. It's important you keep up your good work and don't become a person who disregards processes. You follow them. All the best!
edited Jan 29 '16 at 11:01
James Fenwick
204311
answered Jan 29 '16 at 6:08
shyla
447159
suggest improvements |Â
up vote
1
down vote
accepted
Few points to convey to your manager and team mate:
Quality: You should be the voice of quality when you talk to your manager. Even if a deadline is approaching, poor processes only lead to poor quality
User error / Knowing ones code too well: This can very well cause even a senior developer to make silly mistakes in the design approach and even sometimes basic Java practices around writing code. Thus, it is a must that at least 1 more pair of eyes go through the code change so that such things can be identified and fixed.
"We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking.": Seniority can cause this kind of an attitude in people, which is a different battle, but the least you can say is that another senior developer be added to your colleagues code reviews if not a junior (don't mention you as the one being junior. That may sound as though you are taking this personally).
If none of this works, don't fret. It's important you keep up your good work and don't become a person who disregards processes. You follow them. All the best!
edited Jan 29 '16 at 11:01
James Fenwick
204311
answered Jan 29 '16 at 6:08
shyla
447159
suggest improvements |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Few points to convey to your manager and team mate:
Quality: You should be the voice of quality when you talk to your manager. Even if a deadline is approaching, poor processes only lead to poor quality
User error / Knowing ones code too well: This can very well cause even a senior developer to make silly mistakes in the design approach and even sometimes basic Java practices around writing code. Thus, it is a must that at least 1 more pair of eyes go through the code change so that such things can be identified and fixed.
"We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking.": Seniority can cause this kind of an attitude in people, which is a different battle, but the least you can say is that another senior developer be added to your colleagues code reviews if not a junior (don't mention you as the one being junior. That may sound as though you are taking this personally).
If none of this works, don't fret. It's important you keep up your good work and don't become a person who disregards processes. You follow them. All the best!
edited Jan 29 '16 at 11:01
James Fenwick
204311
answered Jan 29 '16 at 6:08
shyla
447159
Few points to convey to your manager and team mate:
Quality: You should be the voice of quality when you talk to your manager. Even if a deadline is approaching, poor processes only lead to poor quality
User error / Knowing ones code too well: This can very well cause even a senior developer to make silly mistakes in the design approach and even sometimes basic Java practices around writing code. Thus, it is a must that at least 1 more pair of eyes go through the code change so that such things can be identified and fixed.
"We have a process in place, which my direct manager often ignores because the other person hired was more senior and he doesn't check her work, even though it is lacking.": Seniority can cause this kind of an attitude in people, which is a different battle, but the least you can say is that another senior developer be added to your colleagues code reviews if not a junior (don't mention you as the one being junior. That may sound as though you are taking this personally).
If none of this works, don't fret. It's important you keep up your good work and don't become a person who disregards processes. You follow them. All the best!
edited Jan 29 '16 at 11:01
James Fenwick
204311
answered Jan 29 '16 at 6:08
shyla
447159
edited Jan 29 '16 at 11:01
James Fenwick
204311
edited Jan 29 '16 at 11:01
James Fenwick
204311
edited Jan 29 '16 at 11:01
James Fenwick
204311
204311
answered Jan 29 '16 at 6:08
shyla
447159
answered Jan 29 '16 at 6:08
shyla
447159
answered Jan 29 '16 at 6:08
shyla
447159
447159
suggest improvements |Â
suggest improvements |Â
up vote
9
down vote
Do something radical and talk to your manager, without accusing anyone of anything. "Hey, I see you approved X, Y, and Z. I thought I was responsible for those -- did you take them because there's something I need to get better at, or did you just have some spare time to work on them? We should coordinate this better to make sure we aren't wasting resources by having unnecessary parallel reviewing."
Then listen. Carefully. Whether you agree or not, what you're told is going to he the actual process as implemented. It may not be the one you're assuming. In particular there may be no ownership of reviewing tasks; it may be assigned to you to make sure it gets done, but others may be actively encouraged to help out when time permits.
Remember that the system tracks approvals. If your manager says code is OK and it isn't, you will not be blamed for that; management and the other coder will handle it appropriately, and one or both of them will learn from the experience. The system is working; let it work.
As far as your doubts about the other people's work goes... we can't tell from here if you are right about your concerns or not. I suggest pausing for a moment to consider that just maybe your manager did review the changes befire approving them, and that maybe your problems with the other coder's work are more a matter of misunderstanding and of different styles of approaching the problem rather that their code necessarily being worse. Maybe that loop isn't infinite after all, but merely exits differently than it would have had you written it. Or maybe it was, but everyone makes a mistake once in a while and you shouldn't assume they will continue to make that mistake
Don't tell people they're wrong. Tell them you're not sure you understand, and ask them to explain why they're right. Even if they aren't -- especially if they aren't -- this is a far more polite way to open the discussion. And it keeps you from embarassing yourself if they do have a good answer.
Don't contend. Collaborate.
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
suggest improvements |Â
up vote
9
down vote
Do something radical and talk to your manager, without accusing anyone of anything. "Hey, I see you approved X, Y, and Z. I thought I was responsible for those -- did you take them because there's something I need to get better at, or did you just have some spare time to work on them? We should coordinate this better to make sure we aren't wasting resources by having unnecessary parallel reviewing."
Then listen. Carefully. Whether you agree or not, what you're told is going to he the actual process as implemented. It may not be the one you're assuming. In particular there may be no ownership of reviewing tasks; it may be assigned to you to make sure it gets done, but others may be actively encouraged to help out when time permits.
Remember that the system tracks approvals. If your manager says code is OK and it isn't, you will not be blamed for that; management and the other coder will handle it appropriately, and one or both of them will learn from the experience. The system is working; let it work.
As far as your doubts about the other people's work goes... we can't tell from here if you are right about your concerns or not. I suggest pausing for a moment to consider that just maybe your manager did review the changes befire approving them, and that maybe your problems with the other coder's work are more a matter of misunderstanding and of different styles of approaching the problem rather that their code necessarily being worse. Maybe that loop isn't infinite after all, but merely exits differently than it would have had you written it. Or maybe it was, but everyone makes a mistake once in a while and you shouldn't assume they will continue to make that mistake
Don't tell people they're wrong. Tell them you're not sure you understand, and ask them to explain why they're right. Even if they aren't -- especially if they aren't -- this is a far more polite way to open the discussion. And it keeps you from embarassing yourself if they do have a good answer.
Don't contend. Collaborate.
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
suggest improvements |Â
up vote
9
down vote
up vote
9
down vote
Do something radical and talk to your manager, without accusing anyone of anything. "Hey, I see you approved X, Y, and Z. I thought I was responsible for those -- did you take them because there's something I need to get better at, or did you just have some spare time to work on them? We should coordinate this better to make sure we aren't wasting resources by having unnecessary parallel reviewing."
Then listen. Carefully. Whether you agree or not, what you're told is going to he the actual process as implemented. It may not be the one you're assuming. In particular there may be no ownership of reviewing tasks; it may be assigned to you to make sure it gets done, but others may be actively encouraged to help out when time permits.
Remember that the system tracks approvals. If your manager says code is OK and it isn't, you will not be blamed for that; management and the other coder will handle it appropriately, and one or both of them will learn from the experience. The system is working; let it work.
As far as your doubts about the other people's work goes... we can't tell from here if you are right about your concerns or not. I suggest pausing for a moment to consider that just maybe your manager did review the changes befire approving them, and that maybe your problems with the other coder's work are more a matter of misunderstanding and of different styles of approaching the problem rather that their code necessarily being worse. Maybe that loop isn't infinite after all, but merely exits differently than it would have had you written it. Or maybe it was, but everyone makes a mistake once in a while and you shouldn't assume they will continue to make that mistake
Don't tell people they're wrong. Tell them you're not sure you understand, and ask them to explain why they're right. Even if they aren't -- especially if they aren't -- this is a far more polite way to open the discussion. And it keeps you from embarassing yourself if they do have a good answer.
Don't contend. Collaborate.
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
Do something radical and talk to your manager, without accusing anyone of anything. "Hey, I see you approved X, Y, and Z. I thought I was responsible for those -- did you take them because there's something I need to get better at, or did you just have some spare time to work on them? We should coordinate this better to make sure we aren't wasting resources by having unnecessary parallel reviewing."
Then listen. Carefully. Whether you agree or not, what you're told is going to he the actual process as implemented. It may not be the one you're assuming. In particular there may be no ownership of reviewing tasks; it may be assigned to you to make sure it gets done, but others may be actively encouraged to help out when time permits.
Remember that the system tracks approvals. If your manager says code is OK and it isn't, you will not be blamed for that; management and the other coder will handle it appropriately, and one or both of them will learn from the experience. The system is working; let it work.
As far as your doubts about the other people's work goes... we can't tell from here if you are right about your concerns or not. I suggest pausing for a moment to consider that just maybe your manager did review the changes befire approving them, and that maybe your problems with the other coder's work are more a matter of misunderstanding and of different styles of approaching the problem rather that their code necessarily being worse. Maybe that loop isn't infinite after all, but merely exits differently than it would have had you written it. Or maybe it was, but everyone makes a mistake once in a while and you shouldn't assume they will continue to make that mistake
Don't tell people they're wrong. Tell them you're not sure you understand, and ask them to explain why they're right. Even if they aren't -- especially if they aren't -- this is a far more polite way to open the discussion. And it keeps you from embarassing yourself if they do have a good answer.
Don't contend. Collaborate.
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
edited Jan 29 '16 at 2:49
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
answered Jan 29 '16 at 2:42
keshlam
41.5k1267144
41.5k1267144
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
suggest improvements |Â
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
All good points, I should add a few more reasons why I don't think the code works though: I left a comment saying it doesn't work, and she insisted it work. I then attempted to try to understand her approach by sitting down with her and pair programming. We then ran the code together and it did not work. She did not change the code before the approval happened. The mistake was a very clear, and obvious one.
– Daniel
Jan 29 '16 at 3:06
1
1
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
One data point maketh not a trend. If there is a trend, management will notice. Wotk the one case in front of you now.
– keshlam
Jan 29 '16 at 3:11
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
My concern is that management doesn't keep a close enough tab on us to notice... and this is not the first time something like this has happened. It's happened at least 2 other times I can recall off the top of my head. I posted this question because I feel if I don't speak up soon, it'll be negligience on my part. So how many times is too many? 3? 5? 10? Please note that I genuinely appreciate your feedback, but I'm just not sure how many times this pattern has to repeat myself before the onus is on me to bring it up to management in a more direct way.
– Daniel
Jan 29 '16 at 3:16
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
See first three paragraphs.
– keshlam
Jan 29 '16 at 3:39
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
Yeah, I think that generally speaking, adding a comment like "this code doesn't work" is not going to help you get your point across at all. Developers and the managers who approve their code are people and people don't particularly enjoy being told that their stuff doesn't work. I strongly second following the above approach instead of going in and telling people off, especially in print (where your words can be pulled up and later used against you).
– NotVonKaiser
Jan 29 '16 at 18:19
suggest improvements |Â
up vote
3
down vote
The reviewer has the responsibility to make sure that the code is of acceptable quality. That's what you would make sure of if you were the reviewer. Since your boss is the reviewer, it's his responsibility that your co-workers code is of acceptable quality when checked in, not your responsibility, and not your co-worker's.
That needs to be made clear to the boss. If you end up shipping a product with severe defects, and it costs your company money, then you are not to blame, nor is your co-worker (even if his code caused the fault, because the real cause of the fault is the incompetent review), it's your bosses fault entirely.
Senior or junior doesn't make a difference. People make mistakes, whether junior or senior, just different mistakes. Reviews catch them. If the boss decides to do incompetent reviews, any problems coming from this are his fault.
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
suggest improvements |Â
up vote
3
down vote
The reviewer has the responsibility to make sure that the code is of acceptable quality. That's what you would make sure of if you were the reviewer. Since your boss is the reviewer, it's his responsibility that your co-workers code is of acceptable quality when checked in, not your responsibility, and not your co-worker's.
That needs to be made clear to the boss. If you end up shipping a product with severe defects, and it costs your company money, then you are not to blame, nor is your co-worker (even if his code caused the fault, because the real cause of the fault is the incompetent review), it's your bosses fault entirely.
Senior or junior doesn't make a difference. People make mistakes, whether junior or senior, just different mistakes. Reviews catch them. If the boss decides to do incompetent reviews, any problems coming from this are his fault.
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
The reviewer has the responsibility to make sure that the code is of acceptable quality. That's what you would make sure of if you were the reviewer. Since your boss is the reviewer, it's his responsibility that your co-workers code is of acceptable quality when checked in, not your responsibility, and not your co-worker's.
That needs to be made clear to the boss. If you end up shipping a product with severe defects, and it costs your company money, then you are not to blame, nor is your co-worker (even if his code caused the fault, because the real cause of the fault is the incompetent review), it's your bosses fault entirely.
Senior or junior doesn't make a difference. People make mistakes, whether junior or senior, just different mistakes. Reviews catch them. If the boss decides to do incompetent reviews, any problems coming from this are his fault.
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
The reviewer has the responsibility to make sure that the code is of acceptable quality. That's what you would make sure of if you were the reviewer. Since your boss is the reviewer, it's his responsibility that your co-workers code is of acceptable quality when checked in, not your responsibility, and not your co-worker's.
That needs to be made clear to the boss. If you end up shipping a product with severe defects, and it costs your company money, then you are not to blame, nor is your co-worker (even if his code caused the fault, because the real cause of the fault is the incompetent review), it's your bosses fault entirely.
Senior or junior doesn't make a difference. People make mistakes, whether junior or senior, just different mistakes. Reviews catch them. If the boss decides to do incompetent reviews, any problems coming from this are his fault.
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
answered Jan 29 '16 at 9:11
gnasher729
70.9k31131222
70.9k31131222
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
Not sure you want to try too hard to manipulate your manager. He has decided to take the risk and let potentially bad code go into production. Who knows, he could get lucky.
When you are required to debug, enhance or alter the code, you should consider padding your estimates on code you haven't reviewed because in a way, you need to do the review now.
Again, your boss will have to decide how to address the extra time you're taking. I would make sure you document these situations. I don't know if you want to get into any details on the quality of the code or lack of skills by the other developer. If your boss feels threatened by all this, he'll make excuses to defend his actions and the capabilities of the other person and put more blame on you or just tell you to stop taking so long (i.e perform magic).
Maybe the manager will see the error of his ways or at least the other programmer.
suggest improvements |Â
up vote
0
down vote
Not sure you want to try too hard to manipulate your manager. He has decided to take the risk and let potentially bad code go into production. Who knows, he could get lucky.
When you are required to debug, enhance or alter the code, you should consider padding your estimates on code you haven't reviewed because in a way, you need to do the review now.
Again, your boss will have to decide how to address the extra time you're taking. I would make sure you document these situations. I don't know if you want to get into any details on the quality of the code or lack of skills by the other developer. If your boss feels threatened by all this, he'll make excuses to defend his actions and the capabilities of the other person and put more blame on you or just tell you to stop taking so long (i.e perform magic).
Maybe the manager will see the error of his ways or at least the other programmer.
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Not sure you want to try too hard to manipulate your manager. He has decided to take the risk and let potentially bad code go into production. Who knows, he could get lucky.
When you are required to debug, enhance or alter the code, you should consider padding your estimates on code you haven't reviewed because in a way, you need to do the review now.
Again, your boss will have to decide how to address the extra time you're taking. I would make sure you document these situations. I don't know if you want to get into any details on the quality of the code or lack of skills by the other developer. If your boss feels threatened by all this, he'll make excuses to defend his actions and the capabilities of the other person and put more blame on you or just tell you to stop taking so long (i.e perform magic).
Maybe the manager will see the error of his ways or at least the other programmer.
Not sure you want to try too hard to manipulate your manager. He has decided to take the risk and let potentially bad code go into production. Who knows, he could get lucky.
When you are required to debug, enhance or alter the code, you should consider padding your estimates on code you haven't reviewed because in a way, you need to do the review now.
Again, your boss will have to decide how to address the extra time you're taking. I would make sure you document these situations. I don't know if you want to get into any details on the quality of the code or lack of skills by the other developer. If your boss feels threatened by all this, he'll make excuses to defend his actions and the capabilities of the other person and put more blame on you or just tell you to stop taking so long (i.e perform magic).
Maybe the manager will see the error of his ways or at least the other programmer.
answered Jan 29 '16 at 18:02
user8365
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
I feel like there are a couple of issues with this approach...
Pick your battles.
I understand how annoying it is when someone else you work with writes bad code. It makes everyone else in your department look bad because end users tend not to understand the difference between a bad UI and a good backend, for example. That being said, you really ought to review with yourself whether or not this particular issue is worth spending relationship capital with this supervisor (or whomever else you have to turn to). Along the same lines...
Try to keep your circle of concern within your circle of influence.
Sorry to get all Stephen Covey here but I think this applies. According to the rules as written, you have a distinct vertical in place. You are supposed to review this other guy's code, but when someone else comes by and marks it off as approved, you no longer have either the need nor the authority to review said code anymore. It's outside of your circle of influence, and hard as this may sound, you kind of need to push it outside of your circle of concern as well for the sake of your own sanity.
If the system as is happening is failing right now, consider allowing it to fail once or twice.
Consider this: your partner puts something into the code that you know is going to eventually cause your solution to crash (I'm a little bit skeptical of the "infinite loop" thing that was proposed in the comments, as most modern IDEs won't even compile if you do that, but certainly the general concept of putting out untested/sloppy code exists) and said code gets approved and follows the path to production. What happens when the bug is caught? If people are coming to you asking how you let it through, you should have a chain of evidence that says that you did not, in fact, touch or otherwise approve said code.
On the other hand, if it ain't broke, don't fix it.
I've also run into some pretty damn inflexible developers in my day to be honest. What is "broken" to one person is simply "another way of doing things" to another. If you saw a bug and the bug never actually fired, is it really a bug, or did someone else just come up with a different style of fixing the issue than you did? If it performs worse than your way, then that may be an opportunity to say "well, I would have done this like X", but the reality of programming is that there is rarely only one proper way to fix things.
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
suggest improvements |Â
up vote
0
down vote
I feel like there are a couple of issues with this approach...
Pick your battles.
I understand how annoying it is when someone else you work with writes bad code. It makes everyone else in your department look bad because end users tend not to understand the difference between a bad UI and a good backend, for example. That being said, you really ought to review with yourself whether or not this particular issue is worth spending relationship capital with this supervisor (or whomever else you have to turn to). Along the same lines...
Try to keep your circle of concern within your circle of influence.
Sorry to get all Stephen Covey here but I think this applies. According to the rules as written, you have a distinct vertical in place. You are supposed to review this other guy's code, but when someone else comes by and marks it off as approved, you no longer have either the need nor the authority to review said code anymore. It's outside of your circle of influence, and hard as this may sound, you kind of need to push it outside of your circle of concern as well for the sake of your own sanity.
If the system as is happening is failing right now, consider allowing it to fail once or twice.
Consider this: your partner puts something into the code that you know is going to eventually cause your solution to crash (I'm a little bit skeptical of the "infinite loop" thing that was proposed in the comments, as most modern IDEs won't even compile if you do that, but certainly the general concept of putting out untested/sloppy code exists) and said code gets approved and follows the path to production. What happens when the bug is caught? If people are coming to you asking how you let it through, you should have a chain of evidence that says that you did not, in fact, touch or otherwise approve said code.
On the other hand, if it ain't broke, don't fix it.
I've also run into some pretty damn inflexible developers in my day to be honest. What is "broken" to one person is simply "another way of doing things" to another. If you saw a bug and the bug never actually fired, is it really a bug, or did someone else just come up with a different style of fixing the issue than you did? If it performs worse than your way, then that may be an opportunity to say "well, I would have done this like X", but the reality of programming is that there is rarely only one proper way to fix things.
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
I feel like there are a couple of issues with this approach...
Pick your battles.
I understand how annoying it is when someone else you work with writes bad code. It makes everyone else in your department look bad because end users tend not to understand the difference between a bad UI and a good backend, for example. That being said, you really ought to review with yourself whether or not this particular issue is worth spending relationship capital with this supervisor (or whomever else you have to turn to). Along the same lines...
Try to keep your circle of concern within your circle of influence.
Sorry to get all Stephen Covey here but I think this applies. According to the rules as written, you have a distinct vertical in place. You are supposed to review this other guy's code, but when someone else comes by and marks it off as approved, you no longer have either the need nor the authority to review said code anymore. It's outside of your circle of influence, and hard as this may sound, you kind of need to push it outside of your circle of concern as well for the sake of your own sanity.
If the system as is happening is failing right now, consider allowing it to fail once or twice.
Consider this: your partner puts something into the code that you know is going to eventually cause your solution to crash (I'm a little bit skeptical of the "infinite loop" thing that was proposed in the comments, as most modern IDEs won't even compile if you do that, but certainly the general concept of putting out untested/sloppy code exists) and said code gets approved and follows the path to production. What happens when the bug is caught? If people are coming to you asking how you let it through, you should have a chain of evidence that says that you did not, in fact, touch or otherwise approve said code.
On the other hand, if it ain't broke, don't fix it.
I've also run into some pretty damn inflexible developers in my day to be honest. What is "broken" to one person is simply "another way of doing things" to another. If you saw a bug and the bug never actually fired, is it really a bug, or did someone else just come up with a different style of fixing the issue than you did? If it performs worse than your way, then that may be an opportunity to say "well, I would have done this like X", but the reality of programming is that there is rarely only one proper way to fix things.
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
I feel like there are a couple of issues with this approach...
Pick your battles.
I understand how annoying it is when someone else you work with writes bad code. It makes everyone else in your department look bad because end users tend not to understand the difference between a bad UI and a good backend, for example. That being said, you really ought to review with yourself whether or not this particular issue is worth spending relationship capital with this supervisor (or whomever else you have to turn to). Along the same lines...
Try to keep your circle of concern within your circle of influence.
Sorry to get all Stephen Covey here but I think this applies. According to the rules as written, you have a distinct vertical in place. You are supposed to review this other guy's code, but when someone else comes by and marks it off as approved, you no longer have either the need nor the authority to review said code anymore. It's outside of your circle of influence, and hard as this may sound, you kind of need to push it outside of your circle of concern as well for the sake of your own sanity.
If the system as is happening is failing right now, consider allowing it to fail once or twice.
Consider this: your partner puts something into the code that you know is going to eventually cause your solution to crash (I'm a little bit skeptical of the "infinite loop" thing that was proposed in the comments, as most modern IDEs won't even compile if you do that, but certainly the general concept of putting out untested/sloppy code exists) and said code gets approved and follows the path to production. What happens when the bug is caught? If people are coming to you asking how you let it through, you should have a chain of evidence that says that you did not, in fact, touch or otherwise approve said code.
On the other hand, if it ain't broke, don't fix it.
I've also run into some pretty damn inflexible developers in my day to be honest. What is "broken" to one person is simply "another way of doing things" to another. If you saw a bug and the bug never actually fired, is it really a bug, or did someone else just come up with a different style of fixing the issue than you did? If it performs worse than your way, then that may be an opportunity to say "well, I would have done this like X", but the reality of programming is that there is rarely only one proper way to fix things.
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
answered Jan 29 '16 at 18:32
NotVonKaiser
6,5051533
6,5051533
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%2f61248%2fhow-to-deal-with-a-manager-who-doesnt-follow-process%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
1
How do you know he's not reading it?
– keshlam
Jan 29 '16 at 2:21
He's a developer as well, and there are basic errors in there (eg. an infinite loop) that means the code will never work.
– Daniel
Jan 29 '16 at 2:35
Are you working in a startup ?
– Radu Murzea
Jan 29 '16 at 12:26
How does something as egregious as an infinite loop ever get out of unit testing? I'm confused.
– NotVonKaiser
Jan 29 '16 at 18:17