3 ms·
If the goal is to increase productivity by reducing unhappiness, then I think the so called 'causes' would be more correctly described as 'situations'. For exa
by riazrizvi 9y ago
If the goal is to increase productivity by reducing unhappiness, then I think the so called 'causes' would be more correctly described as 'situations'. For example 'Bad code quality and coding', which is explained as a situation where a developer essentially has to clean up another's poor code, is described as a cause of unhappiness. But I like cleaning up other's shit code. The activity helps me feel good about myself in lots of ways. So I believe the way people handle these situations is the 'cause' of unhappiness. However people who do become unhappy in these situations tend to interpret them as causes, because they don't yet understand what the actual cause/solution to their process problem truly is.
- amelius 9y agoCleaning up code requires a lot of testing (which you cannot always automate, e.g. in case of a UI, except if you are willing to invest a lot of time). Not everybody likes testing.
- crdoconnor 9y ago"For example 'Bad code quality and coding', which is explained as a situation where a developer essentially has to clean up another's poor code, is described as a cause of unhappiness. But I like cleaning up other's shit code. " I like doing it too (sometimes), but I find that: * It's very low visibility work by its nature. People outside of the team will see bugfixes and new features but they don't see prevented disastrous bugs and don't necessarily see speeded up delivery. * Dysfunctional working environments tend to go hand in hand with bad code.