Monday 31 August 2015

Gimme an A! Gimme a U+00D6!

(I'm kinda curious how the title is going to be parsed.)

Someone at work linked this article:

https://jaxenter.com/programming-cheerleaders-hired-in-china-119831.html

Motivation in the workplace takes on many forms, but one Chinese startup has started hiring “Programmer Cheerleaders” to motivate their mostly male developers during office hours. The reason? Apparently they suck at socialising.
Trending in China has reported that Internet companies across China are “embracing programming cheerleaders, pretty, talented girls that help create a fun work environment”. Their tasks range anywhere from buying male developers breakfast to playing ping-pong.

Gender controversy aside, to be honest, I think having someone to boost morale is a great idea. When I first joined my team, I was a mediocre, if not rubbish programmer. A lot of the stuff I learned at uni was either incredibly simplistic (this is an Integer, this is how you write a for loop), not relevant for me at the time (this is how you draw a UML diagram), or just not applicable anymore (you should always comment every part of your code (though to be fair, this was likely just to make the marker's life easier, and not an actual thing they expect you to do*)). It took a lot of learning to get up to speed with the team's processes, and just actual practical programming skills in general.

I rationalised my lack of productivity by the fact that there was something I did contribute to the team: I helped keep the morale up. Had a crappy day? Sure, I'll listen while you rant. It's your birthday? Hey everyone, gather 'round, let's have some cake! Not sure what the process is for something? I'll look it up and get back to you. I wasn't too good at my own job, but I was really great at helping other people do theirs. Over time, as I become more competent, I started to do more programming related things, but I still do the other stuff sometimes, because I feel like I'm really good at it. Sometimes I just come up with these ideas, and I think, "Lionel is really going to love this!" and I just get completely enveloped by the idea (like making that James Bond spoof movie). Plus, I really love surprising people, and I think that the people on my team are great, and deserve to know how valued they are.

I'm not advocating that companies hire super subservient women wearing cheerleading uniforms, but I do think there's some value in raising morale. There's only so long that you can whip people to keep their nose to the grindstone, and after a while, they will seek greener pastures. Not that I'm saying my company does that, as I think we have a decent work-life balance. But from what I've heard from others, it seems to be the norm, especially with the GFC being not so long ago, for the old, "we're not doing that well, so we need everyone to buckle down until things are a bit better." I think the days of company loyalty are gone, and it's asking a lot of someone to stay at one company for 30+ years, so if you want to retain that knowledge, you need to give people an incentive to stay. Low team morale is contagious. Once one team stops caring about the quality of the work they do, they will impede the work of others, causing them to become frustrated, and so on.

It's unlikely that we're going to get "cheerleaders" any time soon, so until then, I will try to keep the team cheerful! =)

------------------------------------------------------------------------------------------
* The argument against copious comments is that comments often become outdated when the code changes, and nobody remembers to update the comments. So you end up with the comments saying one thing, and the code doing something else, and you can't tell which is correct. Also, as darkpast often tells me, your code should be self-documenting. If you can't understand what it does just by looking at it, then it probably needs to be refactored. Badly named variables and methods are things that belong in obfuscated code competitions, not shared code bases. Comments should be reserved for documentation for public use (e.g. javadocs), or for cases where you had to do something that might not make sense, but it's the only way to accomplish what you need, and so you have to explain why you did what you did. Or for warnings not to do something.

No comments: