usable in any place a human can be used

20091028

related tasks

I remember watching Mitch Hedburg one time talk about how comedy is an odd kind of profession because if you are really good at it you have to stop doing it. The point he was making is that if you are successful enough at stand-up then one day people are going to ask you if you can act and write and star in movies. Here is the pertinent quote.

When you’re in Hollywood and you’re a comedian, everybody wants you to do other things that are related to comedy, but are not stand-up comedy. ‘All right, you’re a stand-up comedian, can you write us a script?’ That’s not fair. That’s like if I worked hard all my life to become a really good chef, they’d say, ‘OK, you’re a chef. Can you farm?’

This is a less severe version of the Peter Principle.

But it's not just comedians, Software Development has a whole host of secondary tasks that are related, sometimes closely, sometimes not so closely, that need to be taken care of. I've found myself in a secondary task day the last few days.

  • New client conference call
  • Functional Specification examination and inquiry
  • Task list creation and time estimates
  • Talking to a hosting company about plan upgrades
  • Researching a fix for PCI non-compliance issue
  • Researching why in the hell IIS6 wouldn't serve .aspx pages (Web Service Extension wasn't permitted)
  • Fighting with a dev environment to get an application running to test whether or not a PCI Compliance fix would break the application
  • Taking a break from fighting with the maddening server to write a blog post

These secondary tasks are all necessary, some are enjoyable (blogging), some I'm surprisingly skilled at (research, talking), some make me feel completely out of my element (time estimates, server configuration). In the landmark The Law of Leaky Abstractions and the follow up The Development Abstraction, Joel writes

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization. The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market.

Its not that I don't want to perform these secondary tasks, or that I'm not good at them, it's just that I'm much more productive at coding. My brain is set up for it, ask anyone that knows me, I think about life as one big program, I examine my emotions based off of function arguments, I turn situations into class hierarchies, it's just how my brain works. Programming makes sense to me, I feel at home there, I feel warm and cuddly wrapped in curly braces, and I work really well there.

These secondary tasks, related tasks, need to get done, and because of my availability I'm the one to do them. It's good to learn new things, but also scary and uncomfortable and frustrating.

I don't know if there is a point to writing this, it started off as a rant against feeling forced to waste my time and skills on tasks that I don't feel comfortable doing, but it hasn't ended there. It hasn't really ended anywhere, it's a reality, so I'll deal.

All I know is that right now the abstraction is leaking and getting my clothes wet, I long to wrap myself in comfy curly braces by a warm fire and feel like I know what I'm doing again.

No comments:

Post a Comment