3 ms·
Even if what they commit does not solve the customer's problem? I'd rather have a coder spend 3 days thinking and 10 minutes coding with one commit than spend
by chris_mahan 13y ago
Even if what they commit does not solve the customer's problem?
I'd rather have a coder spend 3 days thinking and 10 minutes coding with one commit than spend ten minutes thinking and three days coding with 300 commits.
Coder productivity to me is "is the user of the software more effective in their job?"
- weixiyen 13y agowhat if they commit once every 3 days and it's super trivial.
- chris_mahan 13y agoWell, if their trivial change in 3 days makes the customers more effective in their job, then that's fine. Remember: the best code is no code.
- weixiyen 13y agowell I suppose that really depends. When there is little to no code and the feature remains incomplete, then it's pretty bad.
- furyg3 13y agoYes, the end goal and final judgement of success is to have your fix/change implemented in the best way for the price you are willing to pay for it... of course. I'm just saying that in my experience good work actually looks and feels like work, in terms of commits and deliverables. If it looks like nothing is happening, it probably isn't. Overtime as it was mentioned in the article, on the other hand, is a very untrustworthy indicator of quality work. Managers too easily think that it's a sign of aggressiveness, commitment, perfect capacity estimates (cost savings), etc. But it can just as easily be a sign of bad planning, resource issues, inept management, internal politics, etc. Managers have to answer the question: is my development team being used most effectively? They need some indicators. Looking at the commits and deliverables isn't perfect, but it's much better than looking at the number of hours someone is sitting in their chair, or ensuring they are adequately stressed out.