This slashdot entry contains some very anger-inspiring content. Especially if you are a developer. Even more especially if you are a developer that listens to music while you work, which I would think most do. The obvious exceptions are the ones who work for the lunatic boss mentioned in the entry who came up with the brilliant policy of banning music at work for developers.
Personally, I would be devastated if I had no music to listen to while writing code. Forget about blocking out office noise. What about the rhythmic productivity music adds to the though process? Is that of no value? I sometimes here a song and almost instantly, I can visualize the code I was writing while listening to it years ago. I wonder if that means the music was distracting me while I was writing it.
Don't take away the right to listen to music at work where it isn't necessary. People just resent you for it and you aren't helping anyone by doing it. You may think you are helping your ego, but all you're really doing is giving yourself false hope as a leader.
Showing posts with label productivity. Show all posts
Showing posts with label productivity. Show all posts
Thursday, December 17, 2009
Monday, September 21, 2009
Productive Developers
In an interesting entry over at agile focus, they mention the developer productivity question. They also discuss why defining developer productivity is such a hard thing to do. The question of whether or not productivity can or cannot be accurately measured is still unanswered as far as I'm concerned.
Developers have a goal to reach on any given project that they happen to be working on at any given time. Or, at least they should have a goal. If they don't have an overall idea of what exactly it is that they are building, then there are bigger problems elsewhere and the company need not concern itself with measuring developer productivity. As stated in the entry, if the developer does have a goal to reach, any forward motion made toward that goal can be considered progress. Again, nearly impossible to measure.
This of course begs the question, should developer productivity even be measured at all? Or should management be able to answer yes or no to the question of whether or not a developer is productive? That is, making progress vs. not making progress. I think this is a valid approach to measuring developer productivity if measurements are taken relative to the expected skill of the developer.
Developers have a goal to reach on any given project that they happen to be working on at any given time. Or, at least they should have a goal. If they don't have an overall idea of what exactly it is that they are building, then there are bigger problems elsewhere and the company need not concern itself with measuring developer productivity. As stated in the entry, if the developer does have a goal to reach, any forward motion made toward that goal can be considered progress. Again, nearly impossible to measure.
This of course begs the question, should developer productivity even be measured at all? Or should management be able to answer yes or no to the question of whether or not a developer is productive? That is, making progress vs. not making progress. I think this is a valid approach to measuring developer productivity if measurements are taken relative to the expected skill of the developer.
Subscribe to:
Posts
(
Atom
)