Your boss asks one of your collegues to modify your code
-
Hello Holger ; Yes, you are right after all, I may take this situation too personally, and there is, in all objectivity, no reason for me to (over)react anyway. I guess, it always would feel frustrating to see that a coworker, who I well appreciate and respect by the way, has spend a substantial amount of energy just to be wasted, as the implementation he found didn't efficiently solve the problem. Together, we had to spend almost a whole day afterwards to solve the thing. But I am still angry with my boss. I feel like we need to communicate more but he is busy all the time.
Mark, communication can always be better :-). I am from Germany, my chef is from slovakia. When I first have taken the hurdle to only talk English - that's not that hard, but the native language is always the first choice when i want to express myself clearly - he's has some ... blindness? for usability, abstraction and really managing people. I always try to do my very best - so one hand he can see that I am reliable and able to solve the weirdest things, on the other hand because of the trust I earn for my work - I am able to criticize at least even him. That works pretty well - even if I sometimes wish I would work as a freelancer. :-) Holger
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
I'm going to go along with what the others have said about it not being your code, but add a couple of points I dno't think were mentioned. It depends on the type of errors which were introduced, the type of work that needed to be done, and the alleged skill level of the other programmer. If the errors were minor, simple things we've all done, then there's no need to do anything other than mention to the other developer. "Hey John, I was looking at your code and noticed...." If the errors are show-stoppers, but the other dev is a new(er) person, go to them and use it as a learning experience. Keep in mind what you perceive as an "error" might be a different way of thinking about the problem and might lead to a stronger solution at which neither of you would have arrived independently. The learning experience might be yours. If they're pretty significant errors and the other dev is a more senior-level person, then it might be the time to go to the boss. If it's truly a matter of incompetence, that needs to be raised so the firing can begin.
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
-
When I write code on company time, that code belongs to the company I work for, not to me. My boss can have others work on "my" code as he pleases. I introduce bugs sometimes, so I imagine I'd be rather forgiving of those introduced by others (though I might make fun of it in the Hall of Shame ;) ).
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
Marc Greiner at home wrote:
your boss has asked one of your coworkers to modify your code behind your back
There's the problem right there -- not with your boss, with you. That code isn't yours and never was. There is no such thing as "behind your back" because any member of your team should be allowed to modify any piece of code in the entire project as needed, that's why its called a "team".
Marc Greiner at home wrote:
you discover that your coworker has broken some of your application's functionality or introduced some bugs
Oh, the horror.. somebody isn't as good a programmer as you are or didn't spend the time to understand the code as well as you did. They broke stuff and introduced bugs. Annoying, but that's life, get over it.
patbob
-
Marc Greiner at home wrote:
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
Why you need to react at all? It’s neither your decision nor your mistake. Live them to clean their mess or help them if they ask politely. Otherwise if you make a big thing out of it you will look like you’re too jealous to your code
There is only one Ashley Judd and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
Programming for money must be an act without ego. Your boss wants what he wants, and gets what he deserves. If the result is unsuccessful, your boss won't do it again. Remember, you get the same wage for cleaning up someone else's stupid mistakes as you do for innovating and adding value, and it's easier and less stressful. You don't have to work late fixing someone else's mistake. If the boss asks you to, just say, "This isn't my mistake. Ask Bob to stay late and fix it. He did it."
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
Depending on who your boss is, talk to them in terms that they will understand. Defects that a customer would care about is a good gauge, for instance. On the other end of the spectrum is coding style which your boss may not care about unless they, too, are a programmer and understand the maintainability value in it.
-
Totally agree with you about who owns the code. But additionally, in my opinion, whoever breaks it is responsible for fixing it.
Almost - whoever has agreed to be payed by the employer, boss, ET. AL., and has agreed to code for such tasks should be responsible for fixing it. If it is a common occurrence, then initiate QA reviews to document the issues and the time spent repairing them. In the long run, if it happens too much, compile the reviews into a proposal for reducing wasted resources, and send it on up the line. If the boss is the last step in the chain of command - well it might be time to renegotiate your contract.
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
It seems to me that many responses to this post have assumed a "one-size-fits-all" organizational structure where everything is under version control, anybody can check out and work on anything ... I don't think that reflects the majority of real-world code shops, although it might reflect the reality of certain types of companies who produce very complex products with large teams, or even multiple teams. So, I think dissolving away all variations here with the mantra "nobody owns code" is not useful. I think to really respond to Marc's OP we need to know, from Marc, if his work group, by tradition, by practice, normally functions with clear assignments of code/functionality to specific programmers. If we know that what Marc encountered was something very unique, in his work context, that's one thing; if we know it's not unusual: that's another. best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
How would you react after your boss has asked one of your coworkers to modify your code behind your back, for example to add a new function or optimize some algorithm, etc., and you discover that your coworker has broken some of your application's functionality or introduced some bugs?
Hand over all my legacy code to my co-worker so that he is bogged down with the endless monotony of fixing bugs whilst I get on with serious development. ;P OTOH, if the shoe was on the other foot, would I have done a better job on someone else's code? None of us are perfect. Finally, I'll have to remind myself that there was a reason why he was being asked to make the changes in the first place ...
-
It seems to me that many responses to this post have assumed a "one-size-fits-all" organizational structure where everything is under version control, anybody can check out and work on anything ... I don't think that reflects the majority of real-world code shops, although it might reflect the reality of certain types of companies who produce very complex products with large teams, or even multiple teams. So, I think dissolving away all variations here with the mantra "nobody owns code" is not useful. I think to really respond to Marc's OP we need to know, from Marc, if his work group, by tradition, by practice, normally functions with clear assignments of code/functionality to specific programmers. If we know that what Marc encountered was something very unique, in his work context, that's one thing; if we know it's not unusual: that's another. best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
Well, the company I am working for is having a team of 4 developers, and each developer has his own domain. To this, it is important to know that we have been working on this piece of software for more than 10 years, with almost no coworker turnover. So, we all have a strong feeling of code ownership, meaning also that we each feel responsible for the specific functions that each of us implemented. Here an example to illustrate it (and in a much greater and different scale): Imagine that you are the architect of the java platform, and that Sun sells java to Oracle. After the transaction, you realize that Oracle does not even care about asking you, the main architect, about how you would go for new features. How would you feel about it? I am sure, like several have expressed it in their opinion here, you would at least go mad in such a situation.