Pitfalls of a polymath programmer

I’ve talked about how a polymath programmer can greatly benefit any software development team. So, what’s the number one advantage of being a polymath programmer?

Polymath programmers are skilled at many programming related tasks.

But do you know the number one disadvantage of being a polymath programmer?

Polymath programmers are skilled at many programming related tasks.

The story of that fateful day…

It was a morning like any other. The sky was a soft blue, the morning air crisp with a hint of the Singapore afternoon heat, and I was friggin’ tired from the programming frenzy the night before.

I reached the office, greeting people along the way, and sat down in my office chair. The subtle difference? There’s no one in a 5 metre radius from my seat for the entire morning.

By a fluke of coincidences and emergencies, all the members of my team were not around. I would be the lone contact, the singular representative for matters directed to my team for two whole days. Some of you might think, “Wow! Power! Command!”.

No such thing.

My team was already small in size, so each member begun to take on more specialised areas of the team’s effort. I’m primarily in charge of most web application development, as well as a few complete systems, a few servers, software installation… anyway, I’m in charge of a lot.

What happened? Like a uncanny manifestation of Murphy’s Law, things started falling apart rapidly on my first day alone in the office. Users started to barrage me with requests and queries. Programs started to fail for the most unfathomable reasons.

Being the sole point of contact for my team members, the users who usually bug them, now bug me. They started with the innocently enough “Hi Vincent. I sent an email to so-and-so, but he’s not around. His out-of-office autoresponder email says to look for you. Can you help me?”, which escalated to the “You. Clear data. Now”

For the entire day, I did everything that my other team members would be reasonably expected to do on a normal work day (serendipities, misfortunes and all). This was in addition to what I would do on my normal work day. Programs failed, files weren’t sent, so I debugged C programs and shell scripts. A user asked for web application assistance, so I helped. Some users got new computers four times better (hard disk and RAM) than mine, and they’d be positively unproductive without the software programs developed by my team, so I went to install the programs.

Because I knew enough of my team members’ work, I filled in their shoes and covered for them. It didn’t make it right or wrong. It was just unfortunate. I was plug-and-playable, and that day pushed that quality to the limit.

It was a very tired and dejected man who stepped out of that office in the evening. That man used every ounce of whatever energy’s left to write this post too…

Just because you can do everything, doesn’t mean you should.