Let Your Programmers Be Silly(blog.matchfwd.com)
blog.matchfwd.com
Let Your Programmers Be Silly
http://blog.matchfwd.com/2012/01/programmers-sillyness/
4 comments
Honestly I think they are the same in term of impact in the spirit and fun they bring to the workplace. The "n/a" versus "ø" discussion will be settled by me sticking to use "n/a" as it's most commonly understood. No need to A/B test it imho. But that's not the point. My point is that it's not "always" required to crack down on silly discussion. I am not saying you should let your guys spend their day discussing that kind of stuff. I am simply don't kill all the fun as long as product is being shipped.
Does that make more sense?
Does that make more sense?
++
"Silly" probably wouldn't be the word I'd have chosen, but it's a good point. If I'm building a system, I want it to be quality work, and I don't want the programmer who has to deal with it in 2 years to be cursing my name :). Thus I sometimes become very concerned with things that seem to have "no business impact".
"Silly" probably wouldn't be the word I'd have chosen, but it's a good point. If I'm building a system, I want it to be quality work, and I don't want the programmer who has to deal with it in 2 years to be cursing my name :). Thus I sometimes become very concerned with things that seem to have "no business impact".
English is not my primary language so there could very well be a better adjective ;-)
:)
I think it might be more of a perspective difference than a language difference. My point was that there is often internal quality work that seems to have "no business impact". This obviously doesn't apply to the example you gave, but the truth is product managers and developers are often looking at two different "products". And there you're especially right on the mark. Programmers need to feel ownership over the product they created, which is not the user experience, but the code.
I think it might be more of a perspective difference than a language difference. My point was that there is often internal quality work that seems to have "no business impact". This obviously doesn't apply to the example you gave, but the truth is product managers and developers are often looking at two different "products". And there you're especially right on the mark. Programmers need to feel ownership over the product they created, which is not the user experience, but the code.
Gotcha. Honestly I probably picked "silly" to get clicks ;-)
Don't let this be a detriment to the actual business. Your best employees would probably enjoy spending more time on real work and less time 'bikeshedding' [1].
[1] http://en.wikipedia.org/wiki/bikeshedding
[1] http://en.wikipedia.org/wiki/bikeshedding
I should have made it clearer that this shouldn't be allowed to individuals not meeting deadlines. That would not make sense. But actually, one of our best employee actually enjoy a little bikeshedding here and there. I blame his young age but it actually bring some fun in when it's most needed. Sometimes you just need to cool down.
thanks for teaching me a new word ;-)
thanks for teaching me a new word ;-)
A bit of a demeaning way to get the point across, but true nonetheless. If developers don't get the sense of ownership, or at the very least the sense that they influenced the direction of development, then it's a lot harder to get them to stay motivated.
I have huge respect for my team, don't worry.
Arguing about small outward-facing stuff is just bikeshedding. In the case of the "n/a" versus "ø" debate, you should settle it with an A/B test, some paper mockups, or even just by manager fiat. If a manager's job is not to keep the developers away from unproductive ratholes like this, then what is it?
Arguing about small inward-facing stuff, like house coding style, is about control of one's own environment, and having a pleasant workplace. So it may well be a matter of human dignity and respect to let them spend "useless" time on it.