Archive for March, 2007
“Everybody” knows that making programmers switch tasks often hurts programming. (I’ll talk a lot about Mr. Everybody, who is a common reader of many blogs) I’ve recently become very interested in evaluating how this effects people a half-step above the programming level. My previous position often had me leading multiple programming teams for different projects, while my current position has me leading a single team for a single project while taking care of many other issues surrounding the actual product development.
Both environments involve quite a bit of task switching in a given day, but I’ve discovered that the nature of the switching changes. Previously, my task switches were mostly in the Problem Domain. I was still helping/doing the same type of things (code reviews, design, etc), but the technical setting changed immensely (Java->.NET, web->client/server), as did the problem being solved (human resources->medical). Now, I find myself doing many many different types of activities, but these activities are all focused on a single business and technical setting.
I’ve found that the end effect of the previous environment was that I was often much more tired and much less satisfied with my progress, even though I managed to accomplish quite a bit. Now, I’m energized by the rapid movement across the different actions and excited about what’s next. I think many of the reasons for this difference involve the way I conceptualize things.
(Tangent!) My mind usually pictures a three(or more) dimensional model of the environment for the problem at hand. This model is a mix of actual visual images of physical entities and a variety of abstract perceptions related to that model. For instance, when conceiving the proper object model for a situation, I’ve got a physical data model in mind, an abstract stereotype of the users, and a wire-frame concept of what the UI looks like floating around in my head, and these models will intersect in various ways as I explore various ways of structuring the model. Some ideas will naturally feel good, and those that I intuitively feel are a good fit are the ones that get the most attention. Often, I’ll then verbalize the idea to give it more substance, and follow with various adjustments for a better fit.
Those who have worked with me are very familiar with the outer view of this process, along with the randomly arcane notes that arrive on white-boards in the process of doing this. In essence, these notes on the board are just a physical anchor for my thought process, allowing me to think in random directions without losing where I came from. Thus, they lose meaning when transcribed and at that point become anchors only for the decision itself, not the process of creating that decision.
(And I’m back!) This big tangent really just goes to explain why I struggle with one type of swap, but not the other. The kinds of switches I do now are all directly related to different pieces of the same big model. I don’t have to put down my Java Web Project for Human Resources model and pick up my .NET client for medical environments model. THAT is what really wears me out, and often includes a trip to the web browser for a mental break.
So, when all is said and done, what I take out of this is that everything a person does needs to be pretty “near” the previous thing they did. The distance and number of dimensions of a jump determines the difficulty of making that jump, and the cost of making that jump.
Technology: .NET? C? C++? Java? Assembly? Visual Basic? I know all of these languages, but they have different object libraries ( if they even have objects), and thus require a different mental perspective on how to accomplish something.
Architecture: Client/server? Data warehouse? Web application? Headless embedded device? Even if these could all share the same language, the rules are different for each of them. New mental model!
Constraints: Real time behavior? six nines uptime? absolutely zero data loss? Maximal user-friendliness? Minimal footprint? Done Now? Each of these laudable goals carries different inherent tradeoffs and must be approached in slightly different ways. Never mind that in reality we have to consider each of these “-ilities” and prioritize them.
Goal: Code? Review? Manage? Decompose? Design? Plan? Propose? Test? Every activity has a different mental approach required. However, I’ve found that these are easy for me – I can move across the software lifecycle easily because it’s all different perspectives on the same work.
Authority: This is one that just recently occurred to me. The authority and responsibility a person has on a current task is important. In code reviews I’m totally in charge, while requirements I’m merely able to suggest changes. Having to back away from the work, even momentarily, to consider if I have to consult others for permission is a distraction.
Media: Computer? Phone? In Person? Across town? On a whiteboard? Do you also have to change the channel you use to communicate and perform the work when you’ve switched tasks? These are more of a friction than a change of mental model, but it’s still real and potentially damaging to efficiency.
Are there any others?
How much does this effect you?
How could this change how you interact with others?