As a developer, we are paid to fix bugs or introduce new features. So as long as you are asked to write in the language you know, it seems silly to turn work down. The exception to this is if part of the code-base requires a high amount of domain-specific knowledge.
We do have a few areas that are like that, and we end up keeping that knowledge with a small group of developers, and in some extreme cases; just a single developer. If that developer leaves the company, then there’s trouble.
I think there has only been one situation where I’ve been asked to fix something, and I have declared it to be a bad idea. It was in an area of code that basically works in 99% of the situations, and if you change it; you are almost guaranteed to introduce a new bug (or many). It’s a really important area of the system, a manager was stating it had to be fixed within a few days; piling on the pressure. I put up a good argument to wait a day for the Lead Developer to return from holiday. A gamble; but I could take the pressure off myself, reduce risk of mistakes, and I could pass on the responsibility.
It was a brilliant idea in hindsight. He came in, I explained the problem and he managed to come up with a really understandable solution within an hour. Worked perfectly; crisis averted.
There’s been plenty of times where there’s been really standard, low risk bugs and Derek has been asked to fix them and he has said “I don’t know much about that area, so I’m not best placed to do it”. But it’s a bit of a paradox, because if you don’t look at the code, and don’t learn about functionality, then you will never know it, and will always come up with that excuse.
There’s been plenty of times where there’s been really standard, low risk bugs and Derek has been asked to fix them and he has said “I don’t know much about that area, so I’m not best placed to do it”. But it’s a bit of a paradox, because if you don’t look at the code, and don’t learn about functionality, then you will never know it, and will always come up with that excuse. Here is a bonus quote:
Derek
“that’s the limit of my knowledge, so I draw a line under it and move on.”
A few days ago, in the stand-up meeting, our Team Lead asked Colin if he could help pick up one of the bugs. Again, it was a standard bug and he said “I don’t think I should pick it up, I think Sam should do it.” The thing is, Colin is a Senior and Sam is a Junior; a couple of ranks below him. When you think of it in those terms; it is just absurd. Sure, I understand Colin’s point that Sam may know which files the problem may reside in; maybe Sam has even introduced it! But, is there really a situation where a Junior is in a better position to fix something than a Senior?
In my opinion, delegating down makes you appear silly. Delegating up alerts people to the severity of the problem. You’ll just look silly if it is actually a simple problem.
Stranger Coding Tings 