About work

I have not written much about my work, my actual work but I think today is a good day to do so as it’s one of the more “typical” days.

Every day I start with a set of tasks. Imagine them as a queue, or bag, of tasks. Most of them are just beacons on parallel threads. In fact all off them are beacons on parallel threads. So, generalize: every day I start with a set of queues and a more general queue containing the first task in all those other queues.

What about those tasks, what are they? At a quick enumeration, without a deeper analyse I think the following types occurs:

  • tasks I have to perform, which can vary from functional to pinpoint technical
  • tasks I have to monitor, or to make sure other people perform. Let’s say they are goals other people have to achieve and I have to make sure they do. Well sometimes this means laying down or defining a full set of more simpler tasks in a queue for each of them. Not to forget these are usually intertwined, some depend on each other and have to be somehow equivalent in effort.
  • tasks I have to monitor but I have not really a control on the people performing them. I can only ping them with various periodicity in order to advance to the desired result, usually one step after another and hopefully no step back.

Ok, so what is with all those tasks? Well, this is where the above queues are explained as each top-level queue is a project. A project which I usually have to understand good enough to see all the tasks which have to be serialized, or more difficult, serialized and parallelized in order to achieve the goal. 
So what’s the problem then, the algorithm seems clear? Well, the problem is that even punctually the algorithm seems clear, and you schedule tasks by queues and priority, if you add too many of these tasks and queues the complexity increases. Assume an example:

  • there is a project A (queue) with some tasks to be done. Technical tasks involving changing something to a desired form. This implies the following tasks: validating the change, implementing the change, testing the change, packaging the change, sending the package and writing a mail with that
  • there is a project B (queue) where neither the environment, nor the desired result is clear, so you set some visibility and try to advance faster with the knowledge than the implementation. But for some bad, inefficient, but justifiable reasons, this has to be split in several queues for some other people to do, except the visibility part which is your responsibility. Apparently none of them needs or wants to see the full picture unless explained so all these queues have to had very small steps tasks defined which are also very intertwined.
  • there are project C and D (queues) which are maintenance queues where sometimes incidents occur which has become active. Tasks one these queue have high priority and cannot be postponed or delegated (as you solve more tasks, the more harder it becomes to pass knowledge and the more reactive you become so it’s very inefficient to impossible to delegate them)
  • there is project E (queue) which contain tasks involving passing knowledge in order to ease the empty of the other queues
  • there is project F (personal queue) with all the things I wish to write or do
  • there is project G (personal queue) with the not eating tasks

Well, a few projects, what is so complicated? It the complexity is not enough then it’s the speed. Imagine that in project B there are some sub-queues. You have to both set tasks on them for everyone to solve and then to synchronize them: make sure everyone has enough tasks, that the tasks are not conflicting with tasks on the parallel queues and that one task does not block the others. Unfortunately this parallelism is very bad in some cases. Very, very bad. Instead of a natural serialization you end up with the following scenario: several parallel blocks which you have to solve in real time at very low-level technical tasks for yourself. Imagine checking, debugging, then passing again the task, more simplified. Taking it again, checking it, debugging it and passing it again. And imagine doing this at intervals of 10 minutes for 3 sub-queues. Add the tasks in project A and the unexpected tasks in projects C and D. I end up starting a few hours early in order to gain some speed on A and flushing E, F and G while switching context at least 10 times in an interval of 1h. Sometimes a happy event means that one sub-queue works on the tasks from start to finish so you have a few hours on calm on that one.

Sounds more like a manager, huh? It might sound like that but all the very specific, very detailed and low-level technical tasks, could very nicely fill a normal schedule. So by parallelizing the full-time technical queues with several full time management and support queues you end up with 12h of something. This is the something I do.

Ah, don’t forget everything is done sitting on a chair, typing and speaking on some messenger screens. No offices, conference rooms, presentation screens or other fancy space to loose you time walking and sitting and going to the water cooler.

And why that? This is a question I cannot answer, it seems this is what I have become and apparently not very bad at it.

Still not getting the part with all the parallel tasks. Well, I agree, it’s very insufficient to parallelize tasks which are better done in serial. It’s a matter of 2 or 3 times slower and many many times more stressful, not to comment on the results. I understand however the justification that maybe at some point the parallelization exercise might prove very useful when it will be really needed.

Ok, so got it, so what’s with the “diet” part? Well, it’s the balance. Where is the stress, tension, mental context switch spark going. First it’s going in a mental buffer, but this gets overflowed very fast. At this point there is eating. Eating generated a vegetative reflex to calm down. I don’t thing that oriented screaming or blaming can solve the tasks faster. I fact I think the responsibility is of the queue manager and should not be passed to the tasks them self more than needed. So it’s about eating again. The reflex of eating balances the unbalanced tension and agitation. Each time, in order to switch context one more bite is needed. Normally, for balance, an equivalent amount of physical exercises should be done in order to purge (or match) the stress (something like this, with sticks) And without it the tension gets accumulated on the body. Last year I managed to get rid of 23kg’s of accumulated stress, how much will I gain back this year? This is why the queue G exists and even if high priority it gets flushed by the shear volume of other tasks.

So, now, do you understand why I don’t stand staying in line in a queue and why this time lost seems completely outrageous? Or why choosing a new phone cannot take more than one day, for 30m, a place in my queues?

Leave a Reply