October 7, 2007 by mensming.

In January, I let my boss know that after more than six years, I would be leaving the company (after a long transition period). Having spent six years in my role, there was quite a bit of knowledge that only existed in my head. He asked that I put together a list of what I did along with a job description for my replacement.

The job description felt like a monumental task, so I started with just a list of what I did day in and day out. Luckily, I keep a bulleted list of what I do each day. I archive these off on a weekly basis. After retrieving these task logs for the last twelve months, I went through the tasks and categorized them into recurring items.

Once I had this comprehensive list of tasks I performed over the last twelve months, I then classified them as:

• Should be done by the person in my role
• Should be delegated to someone on my team
• Should be done by someone on a different team
• Should not be done

With the list of items that should be done by my replacement (and a couple of web searches), it was easy to generate the job description. However, the real value of this exercise was identifying those items I should be doing and those I should delegate. If only I had been doing this before and on a more regular basis.

Posted in professional development | No Comments »

August 28, 2007 by mensming.

I just finished reading Better: A Surgeon’s Notes on Performance by Atul Gawande. This is a very interesting book about the medical system. However, there are a couple of items which apply to software development professionals.

The first section of the book deals with diligence. Many of the examples in the book deal with the need to be vigilant in some of the most mundane aspects - washing hands, inoculations and wearing body armor in Iraq. Often, in software development, we fall down when we are not diligent. We take shortcuts, we don’t create unit tests, we don’t review requirements, design or code. All things we know we should do but often skip. In short - we are not diligent.

In another section, Gawande shows how measurements impacts the quality of care. The Apgar score (the simple measurement used to judge the health of newborns) spurred doctors to improve care of newborns who originally were not considered viable. While the medical profession keeps many different statistics, it is often difficult to compare one doctor’s performance to another. The introduction of the Apgar store allowed for a simple measurement to be applied universally. Doctor’s, patient’s and hospital’s had a way to compare performance and improvement in this aspect of care. Unfortunately for software, there is no simple measurement that can be applied to a software product and there is definitely no universal measurement that can be used to judge our performance compared to our peers.

I think these two items are worth each of us considering. How can we be more diligent in our daily activities? And while a universal measurement is not achievable, can we develop a measurement to compare our (or our team’s) performance from project to project?

Posted in professional development | 1 Comment »