Even though most people who see the movie see it as a story of "betrayal" or "fallout between friends" T see a more common pattern in both of Mark Zuckerberg's conflicts as depicted in the movie i.e Programmer-Non Programmer friction.
Both of Mark's "adversaries" in the movie were not programmers. And I think in both cases the fact that they didnt actually write any code somehow lessened the "value" of their actual contribution(if any).
I wont try to take sides in whether Mark Zuckerberg screwed over his friends or was he just smart. Being a programmer myself I'm afraid my stand would be inherently biased.
The fact that programmers and non programmers don't mix that easily is something gets highlighted to me quite frequently at work these days. At work most of the "people in charge" are non-programmers or at least people who would answer "No" to "Are you a technical person?". Quite often we are faced with situations where decisions taken by the non-technical crowd fly in the face of basic software engineering.
I've also realized that in most situations highlighting the problem and offering a sensible sounding solution fixes it , while in some cases and they are met with "I don't want it that way".
But if you dig a little deeper you'll find that the difference is not between people "likes to program" and "doesn't like to program". What usually turns off the self-professed non-technical people is a "fear-of-the-unknown". Its a powerful driving force. Very seldom do people want to try something new.
An easy analogy would be a kid refusing to learn to multiply and choosing to repeatedly add to get his answers. The sad part is that he does get his answer. But what he doesn't realize is that the time he spent repeatedly adding could have been put to better uses.
The situation further complicates when the kid who doesn't know how to multiply is put in charge of a team in which people who know how to multiple are a minority. Its a very sensitive situation in which any attempt by the "multipliers" to explain multiplication is quickly seen as either an insult on the intellect of the non-multipliers or arrogance or both. What I've learned from experience is that aggressiveness from either side worsens the situation.
The formation of a team with the above mentioned composition is unavoidable in todays IT scenario, since your average IT crowd is filled with programmers and non-programmers. Hence this situation cannot be prevented, however it is my firm belief that it can be dealt with easily.
The key to dealing with the above situation is to encourage a culture of criticism and debate. When I say a culture of criticism I mean that the following sentences should come up in team meetings frequently.
1. You are wrong and heres why
2. Actually what you are suggesting isn't right either and heres why
3. I was wrong -> Personally I rate this sentence to be the most important but the most scarcely heard sentence in today's workplace.
Ideally no decisions that impact the day to day working of a software team like new processes or new tools or new design should be implemented without them passing through a meeting room with every member present where the above mentioned three sentences are spoken.
The fundamental difference in which programmers and non-programmers approach problems pr work in general lead into interesting questions like this one - http://stackoverflow.com/questions/811246/how-to-hide-thinking-at-work-so-that-the-non-programmers-dont-suspect-slacking/
My office has a window with a pretty neat view of the KL skyline. Sometimes when im thinking about stuff I like staring out of it. Once my team lead asked whether i was free since i seem to have time to stare out of the window. Wonder whether i should start implementing some of the suggestions that people give in the above mentioned link.
I'm naming this article as part one of a series because I've been writing this one for over a week and I have a slight feeling that I'll have more to add on to this in the future.
No comments:
Post a Comment