Easy or Hard?

I had the following conversation with a colleague about a client project recently.

At that moment, it strikes me that sometimes I want the easy ones but at other times I want the hard ones. But why? After some thoughts, I concluded with:

I want the easy ones because they are easy and quick, but annoying and boring. And I want the hard ones because they are challenging and interesting.

I think the following matrix describes it best:

Do you get the point?

As software engineers or programmers (sometimes interchangeable terms IMO), we like to solve challenging and interesting problems, regardless of difficulties. Ideally, we like everything to be in the easy and interesting quadrant, but we certainly like (sometimes prefer because it is also challenging) things in the hard and interesting quadrant as well. We would accomplish things in these two quadrants with our fullest attention and best effort.

Stuff that belong to the easy and annoying, and hard and annoying quadrants bore us. We naturally pay less attention and try to do them with spare time. However, they still need to be done. They become a drag.

Now we understand the matrix, but what can we do about the drag?

This is what I think.

I may feel ActiveMerchant is a joy and interesting to work with, but someone else may think it is a distraction to the project and just want to settle with using Authorize.net when it is already supported by ActiveMerchant to do recurring payment.

I may feel having to crop all images again and save them in a different format is a waste of my development time, but a photographer may actually enjoy such work and may even add a drop shadow to make the images look better.

The difference is in the interpretation.

Interpretation

Different people interpret the same thing differently based on their own level of interest/time/concern, …/etc. That is a fact, not an argument.

In software development, instead of the project manager assigning tasks to each engineer, programmer, QA, you name it, based on time, skill levels, familiarities with certain code pieces, scopes, existing client relationships, maybe, just maybe, it is better to ask each person which of the tasks they have the most interest in and then assign tasks based on level of interest. That way, each person on the team will put forth his/her best attention/effort to accomplish them.

Potential pitfalls

• What if none of the tasks interest me? Maybe put that person in a different project that has tasks that interest him?
• What if many people are interested in the same task? Who gets to work on it? Maybe pair programming in which several people can participate and can have inputs?
• If I keep picking tasks that seem easy (on the surface), would it make me look lazy?
• If I pick several hard tasks, I may make myself too busy.

Again, we should not be blind folded by interpretaion. I may think it is easy but someone else may think it is interesting and solve the task better. I may think it is hard but since I am so interested, I may solve it with higher efficiency, hence less time.

The above is just a thought. I have not actually tried it to see how well the process works. However, since project management is so boring and annoying to so many people. We may as well put a different interpretation to it. It certainly is a paradigm shift in project management.