When I—a development manager who still works with the codebase—tell my guys that I don't want them working on that particular piece of code it's precisely because a) I know things about the overall design and project that they don't, and b) I know what needs to be done next.
Yes, I want my employees asking whether they should be spending the extra time to make something subjectively better. Once the code works, we need to weigh the time it will take to clean the code up vs the time to do the next task.
Code cleanup should NEVER be a sole task, and it should probably not be a solo task if it is (and if it is, it had better be one of your two or three best programmers in the company doing it). I have told folks not to make changes NOW, because we are revisiting the code in two sprints for the next major milestone. Meeting the current milestone is more important than aesthetics, and it isn't an ethical deficiency at all.
(Hopefully this is sensible; composed on the iPad right before bed.)
Let me be clear - I think that before programmers start throwing off their shackles and asserting their 'rights' they need to build up trust with the PMs.
I do this by consistently delivering high quality code on time and reporting back to them about progress. I assure them that I'm not going to drop them in the crapper by trying to conceal a problem until it is too late, I am very up front and honest about any problems and try to give them plenty of advance warning.
In return, I expect to build trust and the coinage of the realm is autonomy. They show me the plan, and I figure out the best way to get us across the line relatively unscathed.
Comments
When I—a development manager who still works with the codebase—tell my guys that I don't want them working on that particular piece of code it's precisely because a) I know things about the overall design and project that they don't, and b) I know what needs to be done next.
Yes, I want my employees asking whether they should be spending the extra time to make something subjectively better. Once the code works, we need to weigh the time it will take to clean the code up vs the time to do the next task.
Code cleanup should NEVER be a sole task, and it should probably not be a solo task if it is (and if it is, it had better be one of your two or three best programmers in the company doing it). I have told folks not to make changes NOW, because we are revisiting the code in two sprints for the next major milestone. Meeting the current milestone is more important than aesthetics, and it isn't an ethical deficiency at all.
(Hopefully this is sensible; composed on the iPad right before bed.)
Let me be clear - I think that before programmers start throwing off their shackles and asserting their 'rights' they need to build up trust with the PMs.
I do this by consistently delivering high quality code on time and reporting back to them about progress. I assure them that I'm not going to drop them in the crapper by trying to conceal a problem until it is too late, I am very up front and honest about any problems and try to give them plenty of advance warning.
In return, I expect to build trust and the coinage of the realm is autonomy. They show me the plan, and I figure out the best way to get us across the line relatively unscathed.