Tuesday, February 7, 2012

Planning vs doing

My dad possesses a great amount of patience, he reads books cover to cover, he would start to learn the electric guitar by studying musical theory, he learned DOS before BASIC and then MS Access. It took me many years to begin to understand that patience is not the only way. I have been long tormented by the battle between my dad's inherited logic of doing things with patience versus my natural tendency to jump from page to page, learn differential equations without previously memorizing the multiplication tables and writing a program without knowing where each bit of data is stored. I still carry this "first things first" philosophy with me, I will not skip boring episodes of my favorite shows, will not do something I have not planned first and I feel bad for not knowing my multiplication tables or my alphabet (sorry dad).

These are the thoughts racing in my head this morning because recently I have started skipping math intensive chapters in the GEB in order to actually read the rest. In light of this epiphany about myself I have been looking at the way I work and I identified both areas where my dad's first things first philosophy still rules my thought processes but also finding where my ADHD philosophy takes over. An example would be that thanks to code completion I have been programming in Java for two years without knowing much about the standard Java libraries, but on the other hand I am reluctant to pick up Scala because I haven't read the book yet. The battle between the planner and doer in me is raging wildly and it is damaging me at least as much as it is helping me.

In software I see these two battling philosophies at play each day. It's the good old fashioned hacker vs architect battle. The architect collects all the requirements, writes hundreds of documents, gets everyone on board, designs, meets, designs, makes some drawings, meets, meets, meets and then starts developing. The hacker spins up the IDE, jumps in, writes some code, goes snowboarding, gets yelled at by the boss Monday morning, mainlines caffeine, writes more code and repeats until the most godawful piece of spaghetti code is produced, it then gets fired, attaches ninja/hacker/guru before their title in their resume finds a partner and founds a start-up.

It is funny because both types of programmers know how to do things right. The planner does realize that spending 50% of the time on documentation is insane and the doer always has this grand plan to take the crappy system and transform it into the unified theory of everything. Yet our minds are too ill equipped for feats of such awesomesauce we simply cannot do it alone. So we are tied up into teams where the planners take all the managerial positions (the alternative would lead to anarchy, rebellion and feces on the walls) the hackers are minced through a well designed machine of bureaucracy where they secretly rebel going off at their own time to work in their own project getting ready for that start-up.

Then there is agile, and then there was laughter. Let me explain, if you put a dictator (no offense) a tripped out hippie (yes offense) and a couple of mediocre guys who don't care much (maybe offense) in a room and ask them to make a space rocket the methodology will NOT affect the outcome. If we are what we eat, then we are also what we produce (this is a disgusting statement) or closer to the truth we produce things according to our image. So it is all up to the developers and the team they compose, the right rookie in the right team can become a solid developer whereas the "graduated from MIT at 16" can also be ground to a mindless pulp by the time he/she reaches 20.

I have seen great code, I know it exists and I no doubt believe there exists the perfect team. But finding such a team, studying how it works and then trying to implement the idea to other teams is in itself a bureaucratic meat grinder at the organizational level. People, like atoms, like butterflies are who they are, we need to love ourselves and those around us, we need to accept our weaknesses and enjoy our strengths. The same bureaucratic operation that oppresses my mind into guilt and agony when I skip a page of a book is the same one that tries to sell you "advice" on being agile, productive, sustainable, insert buzzword here.

Teams are like clouds. All you can do is set the conditions and hope for the best. You can't program people to act like robots, no matter how hard you may want to (and I do!)

Till next time,
Stratos out.