Mixing
Boss accepts but then ignores company policy proposed by employees
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
5
down vote
favorite
I am working in a small software company. We are quite small with only 3-4 full time developers. I started working there as a student assistant roughly 8 years ago and started working full time after finishing my masters in computer science.
My colleagues and me have more than once proposed various policies on how we think we could enhance the development process (e.g. code style, code reviews, etc.). We have discussed these proposals in the team and came to an agreement. Also our boss who also does development from time to time had agreed on it and introduced it as official company policy.
However, he then quite often ignores these policies. E.g. commits code without code review that more than once caused a build break. When asked about it he either says it is not a big deal and does not take the complaint serious or he gets offended (we have a quite familiar atmosphere at the company).
This bothers me a lot because I don't think that is how software development should work and I also find it disrespectful. After all, however, he is the boss.
Furthermore it looks like that I am the only one who really finds this annoying. From time to time also my colleagues complain about him but they seldom talk to him about it. So it might look like for him that I am the only one complaining. I also think that it is not possible to convince my colleagues to talk to him about it, since for them it seems to be not such a big deal.
What could I do about? Is it my boss who behaves wrong or am I too picky?
management team company-policy unprofessional-behavior
asked Apr 15 '16 at 8:55
sigy
699419
suggest improvements |Â
up vote
5
down vote
favorite
I am working in a small software company. We are quite small with only 3-4 full time developers. I started working there as a student assistant roughly 8 years ago and started working full time after finishing my masters in computer science.
My colleagues and me have more than once proposed various policies on how we think we could enhance the development process (e.g. code style, code reviews, etc.). We have discussed these proposals in the team and came to an agreement. Also our boss who also does development from time to time had agreed on it and introduced it as official company policy.
However, he then quite often ignores these policies. E.g. commits code without code review that more than once caused a build break. When asked about it he either says it is not a big deal and does not take the complaint serious or he gets offended (we have a quite familiar atmosphere at the company).
This bothers me a lot because I don't think that is how software development should work and I also find it disrespectful. After all, however, he is the boss.
Furthermore it looks like that I am the only one who really finds this annoying. From time to time also my colleagues complain about him but they seldom talk to him about it. So it might look like for him that I am the only one complaining. I also think that it is not possible to convince my colleagues to talk to him about it, since for them it seems to be not such a big deal.
What could I do about? Is it my boss who behaves wrong or am I too picky?
management team company-policy unprofessional-behavior
asked Apr 15 '16 at 8:55
sigy
699419
5
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09
suggest improvements |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I am working in a small software company. We are quite small with only 3-4 full time developers. I started working there as a student assistant roughly 8 years ago and started working full time after finishing my masters in computer science.
My colleagues and me have more than once proposed various policies on how we think we could enhance the development process (e.g. code style, code reviews, etc.). We have discussed these proposals in the team and came to an agreement. Also our boss who also does development from time to time had agreed on it and introduced it as official company policy.
However, he then quite often ignores these policies. E.g. commits code without code review that more than once caused a build break. When asked about it he either says it is not a big deal and does not take the complaint serious or he gets offended (we have a quite familiar atmosphere at the company).
This bothers me a lot because I don't think that is how software development should work and I also find it disrespectful. After all, however, he is the boss.
Furthermore it looks like that I am the only one who really finds this annoying. From time to time also my colleagues complain about him but they seldom talk to him about it. So it might look like for him that I am the only one complaining. I also think that it is not possible to convince my colleagues to talk to him about it, since for them it seems to be not such a big deal.
What could I do about? Is it my boss who behaves wrong or am I too picky?
management team company-policy unprofessional-behavior
asked Apr 15 '16 at 8:55
sigy
699419
I am working in a small software company. We are quite small with only 3-4 full time developers. I started working there as a student assistant roughly 8 years ago and started working full time after finishing my masters in computer science.
My colleagues and me have more than once proposed various policies on how we think we could enhance the development process (e.g. code style, code reviews, etc.). We have discussed these proposals in the team and came to an agreement. Also our boss who also does development from time to time had agreed on it and introduced it as official company policy.
However, he then quite often ignores these policies. E.g. commits code without code review that more than once caused a build break. When asked about it he either says it is not a big deal and does not take the complaint serious or he gets offended (we have a quite familiar atmosphere at the company).
This bothers me a lot because I don't think that is how software development should work and I also find it disrespectful. After all, however, he is the boss.
Furthermore it looks like that I am the only one who really finds this annoying. From time to time also my colleagues complain about him but they seldom talk to him about it. So it might look like for him that I am the only one complaining. I also think that it is not possible to convince my colleagues to talk to him about it, since for them it seems to be not such a big deal.
What could I do about? Is it my boss who behaves wrong or am I too picky?
management team company-policy unprofessional-behavior
asked Apr 15 '16 at 8:55
sigy
699419
asked Apr 15 '16 at 8:55
sigy
699419
asked Apr 15 '16 at 8:55
sigy
699419
asked Apr 15 '16 at 8:55
sigy
699419
699419
5
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09
suggest improvements |Â
5
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09
5
5
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
7
down vote
accepted
Try to look at the problem differently.
1: You lack code review in some places.
2: You know that someone breaks your builds by ignoring code quality.
In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.
For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.
If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.
edited Apr 15 '16 at 10:24
Andrew Leach
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
suggest improvements |Â
up vote
3
down vote
You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.
The bosses job is to ensure you get paid each payday.
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
suggest improvements |Â
up vote
0
down vote
Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.
If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.
If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
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();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
Try to look at the problem differently.
1: You lack code review in some places.
2: You know that someone breaks your builds by ignoring code quality.
In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.
For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.
If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.
edited Apr 15 '16 at 10:24
Andrew Leach
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
suggest improvements |Â
up vote
7
down vote
accepted
Try to look at the problem differently.
1: You lack code review in some places.
2: You know that someone breaks your builds by ignoring code quality.
In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.
For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.
If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.
edited Apr 15 '16 at 10:24
Andrew Leach
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
suggest improvements |Â
up vote
7
down vote
accepted
up vote
7
down vote
accepted
Try to look at the problem differently.
1: You lack code review in some places.
2: You know that someone breaks your builds by ignoring code quality.
In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.
For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.
If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.
edited Apr 15 '16 at 10:24
Andrew Leach
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
Try to look at the problem differently.
1: You lack code review in some places.
2: You know that someone breaks your builds by ignoring code quality.
In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.
For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.
If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.
edited Apr 15 '16 at 10:24
Andrew Leach
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
edited Apr 15 '16 at 10:24
Andrew Leach
356110
edited Apr 15 '16 at 10:24
Andrew Leach
356110
edited Apr 15 '16 at 10:24
Andrew Leach
356110
356110
answered Apr 15 '16 at 10:15
Magnus Kirø
962
answered Apr 15 '16 at 10:15
Magnus Kirø
962
answered Apr 15 '16 at 10:15
Magnus Kirø
962
962
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
suggest improvements |Â
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
– sigy
Apr 15 '16 at 10:48
1
1
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
– Magnus Kirø
Apr 15 '16 at 11:11
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
We don't do continuous delivery. However, I get your point. And I agree.
– sigy
Apr 15 '16 at 11:32
suggest improvements |Â
up vote
3
down vote
You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.
The bosses job is to ensure you get paid each payday.
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
suggest improvements |Â
up vote
3
down vote
You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.
The bosses job is to ensure you get paid each payday.
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.
The bosses job is to ensure you get paid each payday.
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.
The bosses job is to ensure you get paid each payday.
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
answered Apr 15 '16 at 9:39
Kilisi
94.5k50216376
94.5k50216376
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
suggest improvements |Â
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
– sigy
Apr 15 '16 at 9:59
2
2
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
– Kilisi
Apr 15 '16 at 10:02
suggest improvements |Â
up vote
0
down vote
Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.
If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.
If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
suggest improvements |Â
up vote
0
down vote
Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.
If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.
If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.
If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.
If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.
If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.
If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
answered Apr 17 '16 at 13:56
Jay Godse
1,290710
1,290710
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%2f65279%2fboss-accepts-but-then-ignores-company-policy-proposed-by-employees%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
5
You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
– Stephan Branczyk
Apr 15 '16 at 9:12
1 word for ya: Gated Checkins.
– Grimm The Opiner
Jun 26 '17 at 16:09