What if...?

• What if you woke up early morning, fully refreshed, without an alarm clock?
• What if instead of being obese, you were strong and agile?
• What if you could devote your complete focus to your work, without being distracted by every little thing that went on around you?
• What if you returned home after a driven eight hours, and instead of feeling tired, you were charged  for a run at your pet project?
• What if everything in your life was exactly as you wanted it to be - right down to your home, the furniture, the decor, your mate and your friends?
• What if...?

Book Review: Crucial Conversations, by Patterson, Grenny, McMillan & Switzer

Crucial Conversations: Tools for Talking When Stakes are High by Kerry Patterson
My rating: 3 of 5 stars

Twenty five years of research poured into a 235 page book. While easy to read, Crucial Conversations is a book I wager you'll want to return to again and again, as you discover additional insight into its teachings.

I think reading this book is key to solving most interpersonal problems one may face at home, at work and at life.

View all my reviews

2011 in retrospect

The two most significant events last year for me were joining Thoughtworks and moving to Gurgaon.

This retrospective is an adaptation of the feedback cycle seen at Thoughtworks which takes place every month or quarter for every project, as well as the office itself. Nearly all Thoughtworkers involved in the project or the office participate and informally discuss things that went right, wrong, and build a set of action items for the next cycle. Here, I am the only participant, and as such, the views represented here are my own.

Things that went right:

• Being able to clear all rounds of a Thoughtworks interview in itself is no small task, and to do so successfully implies a skill level above most. It was great being considered a 'strong pursue' at the end of my interview rounds.
• If you've never experienced agile software development before, your first days at Thoughtworks can be extremely unnerving. It certainly was so for me; test driven development and the development process from 'Ready for analysis' to 'Customer signoff' were the biggest learnings from the last year I've spent here.
• I'd never spent a year in the company of as many smart and interesting folk as I have at TW. Even though I'm leaving, the company remains a place I'd recommend to anyone interested in intellectual company.
• I learnt you could be successful without compromising your ethics. TW is the most humane company I've worked for. They regularly turn down projects for clients with questionable business practices, and channel a substantial portion of their profits into funding projects with a social impact.
• Shifting to Gurgaon gave me an opportunity to move away from home and clear my head. I was able to - for the most part - shed a considerable volume of personal baggage and look at myself with a little more clarity.

Things that went wrong:

• I did not capitalize on my being able to join Thoughtworks. I treated it as an end goal in itself and did not improve as much as I would have liked.
• I did not pay attention to my personal heath. Losing weight and getting into shape was one of my targets for 2011, and I failed miserably.
• I did not build any personal discipline, was unable to build a daily routine, and several other aspects of my life suffered as a consequence.
• While I did learn Ruby, I didn't push for mastery in it, as I ought to have. I was content with merely skimming the surface, and I should have done more.
• I discovered my discomfiture with pair programming. While it is something I do not intend to attempt again, I need to understand why I am uncomfortable with it.  

Action Items for the year ahead:

• Re-establish a working stream at home. For every two hours of work, I should put in one hour of practice at home. By practice, I'm not merely referring to working on what I'm doing at work, but also the exploration of new paradigms, technologies and ideas.
• Build new habits for exercise and diet - ones that make me healthier.
• To manage both points above, I will need to get more disciplined.
• Pursue mastery in Javascript. Understand how browsers work. understand how jQuery and Sencha work.
• Master my environment - I should get extremely comfy with vim and the shell.
• Returning home, I'd like to get more involved around the house, especially with helping the folks out.

Book Review: Steve Jobs, by Walter Isaacson

I read Isaacson’s biography of Steve Jobs in fits and starts. I was forced to put the book down every now and then in order to reconstruct my image of him with yet another bewildering facet of his personality.



Not having read any other of Isaacson’s works I have no frame of reference to determine whether he’s writing at his peak. But set any doubts aside; the writing is very good, and he does not hesitate to expose the darker aspects of Jobs alongside his virtues. He almost dissects Jobs’ relationships with Wozniak and Markulla to show why Apple became a market leader early on; then the series of errors with NeXT that gave him the learning he needed to return to Apple a better leader; and the range of products that made Apple the most innovative computer company in the world.


His grudging respect for Bill Gates was a bit of an eye opener, as was his obsession for owning products of only the highest standards. Impute, meaning to create a sense of something in someone else, was a  word added to my vocabulary.


I was left with questions around his relationship with the materialist Larry Ellison - how they came to be the best of friends remains a mystery the book did not solve. I would have also liked more insight into his famed meanness, which was missing.


Overall, I rate the book ⅘. 

Things I learned this week

1. Commit promiscuously. Commit now. Not the start of tomorrow morning, not the end of day, now.
2. Pull promiscuously. Pull now, and every 15 minutes thereafter. Else be prepared to face merge hell.
3. Learn your repo tool inside out. Know every command, and how and when to use it. When you fail at #2 and face merge hell, you will need every trick in the book to set things right.

Game Review - Deus Ex: Invisible War

Three intense days. Deus Ex: Invisible War completed. Probably not the best way to spend time at the ThoughtWorks beach, but it was a good deal of fun.

The graphics are certainly better than the polygon-exposes of the game's revered predecessor, Deus Ex. The characters look a lot more realistic, and their movements are better mapped; the slightly crouched pose the soldiers assume when alert is a good touch. The beginning is a lot more eventful than that of its parent; when the entire city is destroyed just to get at your company, and you begin the game in a complex that's under attack, your engagement in the game is a certainty. The use of a dilapidated UNATCO setting at the end is an especially nice nostalgic touch.

And that, I'm afraid, is all the good I can say about this release from Eidos/Ion Storm. From a promising start and a very involved middle game, the impact begins to taper off, and the flaws begin to shine through.

Flaw one: The character development is a shadow of what the original game had. Gone are your abilities to specialize in a certain family of weapons; Alex D is a master of all trades, no matter who plays him/her. This was a critical aspect of the parent game, because it forced you to choose a set of skills that in turn affected your approach to the game overall. You could be a gun toting Quakebot or a stun-prodding pacifist (and a myriad shades in between) .

Flaw two: Having one type of ammunition for all weapons reduces the tension and hardship experienced when one runs low on ammo in the middle of a firefight. It also removes the exhilaration experienced when coming upon say, some sniper ammo when you're dry and having searched the entire level and the one before for some.

Flaw three: The biomod option design allows you to make choices that make playing the game relatively trivial. In Deus Ex, you could choose to make yourself invisible to either organic or inorganic adversaries, not both. In Invisible War, you can waltz through an entire complex without being noticed. Nice in real life, but hardly exciting in a game.

Flaw four: The decision options at the end of the game were somewhat unfulfilling; all four of them appeared equally dystopian, with three of them demanding the enforcement of a draconian model of social control.

To summarize, Deus Ex: Invisible War is a shadow of its predecessor, and I am hoping the newly released Human Revolution does better.

First class functional frivolity

Toying with dynamic languages with first class functions can be a lot of fun, even if you get nothing more from it than a couple of mind benders. Try a coding session like this, for instance:

>>> def g(arg):
...     print str(arg)
...
>>> def f(arg=None):
...     if arg is None:
...         pass
...     else:
...         g(arg)
...         return f
...
>>> 

With g, I've defined a wrapper for the print function, simply passing the argument to it. f, on the other hand, is a method that - if arguments are passed through it - executes method g with the arguments provided, and then returns a self reference to the method f itself. Looks like the rudiments of function chaining!

>>> f("Hello")
Hello
<function f at 0xb76f3aac>
>>> f("Hello")("World!")
Hello
World!
<function f at 0xb76f3aac>
>>> f("Hello, ")("World! ")("You ")("suck!")
Hello,
World!
You
suck!
<function f at 0xb76f3aac>
>>> f("Hello, ")("World! ")("You ")("suck!")()
Hello,
World!
You
suck!
>>> 

So, f("Hello") executes print "Hello", and returns function f, as expected. The attempted chaining also works; both f("Hello")("World!") and f("Hello, ")("World! ")("You ")("suck!") execute print on the arguments in succession, and return method f at the end. To drop the function return at the end, append a pair of empty parentheses to your chain; this returns nothing, and gives you a much cleaner result, as shown in the last play. Until I find an official term for this, I am calling the empty pair of parentheses, used to terminate this 'method chain' a terminator. :)

It appears this sort of thing is very hard to do with statically typed languages; I'm dimly aware of why, but would rather gain a more complete understanding before venturing forth an explanation.

Let's take this one step further. Say I would like to retain the method chain, but would prefer to be able to change the method being called. First shot:

>>> def gMake(g_arg):
...     def g(arg):
...         g_arg(arg)
...     return g
...
>>> from __future__ import print_function
>>> gp = gMake(print)
>>> def chain(arg=None):
...     if arg is not None:
...         global gp
...         gp(arg)
...         return chain
...
>>> chain("Hello")("World")
Hello
World
<function chain at 0xb74476f4>
>>> chain("Hello")("World")()
Hello
World
>>> def mul2(num):
...     print(num * 2)
...
>>> gp = gMake(mul2)
>>> chain(2)(3)
4
6
<function chain at 0xb74476f4>
>>> chain(2)(3)(4)()
4
6
8
>>> 

Not a very good solution, but it works. By using a function factory in gMake, I'm able to make modifications to the actual method called in my chain method by using a global variable in my chain function. To remove this dependency and make my chain a little more functional, I try:

>>> from __future__ import print_function
>>> def mul2(num):
...     print(num * 2)
...
>>> def chain(func=None, *args, **nargs):
...     if func is not None and ( args is None and nargs is None):
...         rv = func()
...     elif func is not None and ( args is not None and nargs is None):
...         rv = func(*args)
...     elif func is not None and ( args is None and nargs is not None):
...         rv = func(**nargs)
...     elif func is not None and ( args is not None and nargs is not None):
...         rv = func( *args, **nargs)
...     if func is not None:
...         return chain
...
>>> chain(print, "Hello, World")(print, "You suck!")(mul2, 2)(mul2, 3)
Hello, World
You suck!
4
6
<function chain at 0xb7874994>
>>> chain(print, "Hello, World")(print, "You suck!")(mul2, 2)(mul2, 3)()
Hello, World
You suck!
4
6
>>> 

If you'll pardon the cyclomatic complexity - I wrote this in haste - you'll find yourself with a nifty chainer with one caveat: we're capturing any potential return values by the methods chained, and then promptly forgetting them as we make our next call. We're now looking at being able to set up a sequence of operations where a function can act on data provided to it at runtime. Nothing special, obviously, but it begs the question: What if we want to chain a set of methods to a single set of data?

Let's keep that for another day.

Emacs' slimey goodness... in Vim!

Using screen, the Slime plugin lets you effectively add the REPL of your favorite dynamic language to Vim.

To install it:

1. Download the plugin. Extract it to your .vim folder.
2. If you haven't already, install GNU screen.

To use it:

1. Start a terminal, and type $ screen -S replshell . The term 'replshell' can be replaced by any term you prefer.
2. Invoke the interpreter of the language you'd like to use. For eg., $ python
3. Start a new terminal, and open vim.
4. Type some python code.
5. When you're done, move your cursor to the starting line of a 'paragraph' which is effectively an unbroken list of lines. This could be a class definition, or just a function.
6. Hit Esc, then C-c, C-c.
7. You'll be asked to enter in the name of the screen you would like to send the text to. Type in replshell. This happens just this once for this session.
8. You'll be asked to name the window, the default option being window0. Hit Enter.
9. The code should appear on the other terminal. Hit Enter to see it execute.
10. Celebrate!

This can be used for Ruby or even Common Lisp. Have fun!