Now that I’m almost done with my despaghettification, and for reasons that will become obvious as you read on, I’m kind of wondering about teamwork.

I’ve had good and bad relationships, projects that made it through despite the huge odds (think “organizing events”) or projects that went down the drain pretty fast for unforeseen reasons. I think that despite the common asocial image associated with computer geeks, working with unforgiving machines makes us highly sensitive in some areas of human relationships. To wit, we have to follow a clear set of rules all day long, and it can be really hard to have an interaction in which the rules change constantly, or aren’t completely explainable. I think that deeply ingrained in our daily life is the assumption that given enough time and “debugging”, everything’s 100% understandable.

Most “normal” people, as some of my friends will call them, don’t think like that. They keep adding stuff to the rulebook, such as “when someone higher up in the hierarchy calls, I pick up the phone, no matter what”, or “you don’t say to your spouse that you’d like to go out with your buddies because you want a taste of normalcy once in a while”. True, it’s a primitive form of trial and error-by-being-punished, but they are stupid rules that should be replaced by more generic and sensible ones. You pick up the phone because they have some business with you (but should still be ready to say “Look I have work to do, can I call you back?”), or you behave in such a way that it is normal to spend some time apart from your spouse, and just as normal as it is to spend some time with him/her. Basically, you don’t spring up a new rule on somebody else because you don’t like them sprung on you.

Back to teamwork, I find it hard to work with people who have a different set of rules than mine, especially when we are trying to build something together. I’ve been kind of documenting this for a long while and am curious as to what you guys think about it.

To me, doing a task can always be resumed in a sentence such as this:

This person wants me to do this Nth step like this because of that

And in my decade or so of working, I’ve seen various people focus primarily on this or that part of the sentence. I find I have a better personal relationship with people who share my focus, but can work with them more easily if I “get” what their focus is. If I don’t understand what they are leaning towards, it’s a one-way ticket to hell.


For obvious reasons, who’s doing the asking matters a lot. As a somewhat social species, we don’t feel like putting the same effort into a task for a personal friend or a complete stranger. It is unequivocally true in personal relationships (hence the word personal), but in professional tasks, the who is the gatekeeper, and should not be some kind of thermostat.

If your boss asks you do do something, and you agreed to do it, then it has no more value than if it’s a friend who does the asking, in my mind. The who deals with the accepting the task, not the realization of it.

When I have to deal with co-workers to whom the person doing the asking defines the whole of the effort put into the task, I shiver. Yes, this person is your biggest customer. Yes this person is your boss and could reassign you to toilet duty. Yes this client is the cutest person on Earth. But you have agreed to other tasks as well. It actually serves the relationship to state you’ll do your task the way you think is better, rather than the way this person thinks it should be done.


Each and every one of us has things they like doing, and things they hate doing. We tend to procrastinate on things we don’t like to do and perform admirably on things we love. And everything in between, mileage may vary. Same thing as the who, it’s natural and literally built-in our genes. We learn through painful mistakes not to put our fingers in the flames. It gives us most of the “one shot rules” I was talking about earlier.

But the thing is, it’s like the who of the previous section. It acts as a filter for accepting the task or not. Once you agreed to perform the task… well, it has to be done.

One of the people who was supposed to “help me” (aka “do it for me”) with my accounting and stuff was exactly like that. Give him a book on his favorite topic or strike a conversation about it, and absolutely no other work would be getting done. And I know I have myself that tendency that I try to overrule all the time: I like debugging and optimizing and looking at the tiny teenie details, rather than cutting up the PSDs to size. But hey, I accepted the task.


Each task has a history, and has a place in a process. Being a developer, most of the tasks I get assigned are the end-of-chain kind. There’s a reason why this tasks occurs now, has to be done by that time and is worded or constrained the way it is.

But rehashing about the timeline over and over and over again bores me. If I have to plug this into that, I do’t really care about all the steps that led to this particular form factor. I mean, I do care about it, but it’s a matter of perspective. I care about it to understand how to perform better, but if it’s not relevant, or I don’t have much latitude in my task, then… why bother.


As you probably guessed by now, that’s what makes me tick, and it does make me tick a little bit too much sometimes. I want to understand why it works or should work in the way it does, because it makes me feel like I’ll write less code, or write code that will integrate better in the grand scheme of things.

The main trouble with focusing on that part of the task is that progress comes in discreet steps. There’s an inordinate amount of analysis and thought that goes in it before a step is taken, then another kind of long pause, etc… It can be hugely frustrating for people who work with me because they’d see nothing moving till all the pieces fit together, and then it all works, as if by magic. And even though I’d be able to explain in great details why I did things that way, we rarely have time for it. So it stays “a kind of magic” that was long-ish to come, and works in mysterious ways.

Kind of conclusion

Being a developer means interacting all day long with an alien way of doing things, and we’re kind of stuck between “regular” humans and unforgiving computers. That means that the human interaction part of work will mostly be evaluated in a similar way: how should I say/write this (syntax), so that the other person (compiler) does what I’d like them to (algorithm). Man, that sounds so nerdy, but I genuinely think that it’s somewhere deep in most work-related conversations I’ve had over the years.

And so, based on that experience and these thoughts, I realized that it takes quite a huge effort to find out what makes other people tick, but once it’s understood, it makes every interaction a whole lot easier. But if the focus keeps changing, the amount of time spent finding out the right “syntax” to talk with somebody about what has to be done becomes too long to be a useful use of time. That’s why some of my co-workers feel they can’t delegate and can’t rely on anyone to help them.

So my advice to anyone dealing with what seems to be an introverted geek, is to find out which part they are more used to dealing with (because they were educated that way or just like it) and make sure your translator is on!


Leave a Reply