The Heart Must Pause

I've been blogging for almost 5 years now. For the last few months, I've been feeling that this blog is more and more out of synch with who I am, what I care about and what I really want to write about.

I started writing on this blog because, when I asked someone how to get good enough to write a book, I got the reply, "First learn how to write a blog entry, then write articles, then write a series of linked articles and then you are ready for the book".

Good advice. What started as pure technical practice, along the lines of practising scales in music, turned into a medium for exploring and clarifying my thoughts. On the way, I gathered an audience and generated a "blog persona" (very unlike the real me but it was a lot of fun),met interesting women and got job offers. All good. The problem with developing such a "persona" or "voice" is that when your perspective shifts radically in a short time frame, it is hard to maintain continuity.

And so, and this is the last post on this particular blog and using this particular "voice". I do plan to write again, in the future, but whether such writing takes the form of a blog, and if so, whether I'll have an "open to all" blog, remains to be seen. If I do write, it will probably show up on my (rather bare now, but that will change, in time) website.

Anyone who has spent time reading this blog and approved or (sometimes violently) disapproved, Thank You for your time. T'was a lot of fun.

"One Man Hacking" is now dead. R.I.P

PS: for those who care about such things, this post's title comes from a poem

So We'll Go No More a-Roving by Lord Byron

SO we'll go no more a-roving

So late into the night,

Though the heart still be as loving,

And the moon still be as bright.

For the sword outwears its sheath,

And the soul outwears the breast,

And the heart must pause to breathe,

And love itself have rest.

Though the night was made for loving,

And the day returns too soon,

Yet we'll go no more a-roving

By the light of the moon.

The Implict Assembly Line

George Lakoff in his book "Metaphors We Live By", notes that we model our conceptual system on metaphors but are often unaware of how they shape our thoughts, speech and acts. In other words, we use one concept to explain, understand, articulate, and work with another concept.

For example, one metaphor that is very pervasive is "Argument is War". We use war as a metaphor in thinking about argument. Witness, "He won that argument" "His criticisms were on target", "I destroyed his argument"

The point George Lakoff makes is that argument really doesn't have much to do with war, except that we make it so by choosing war as an analogy. For example, argument could be (but often isn't) a "joint search for truth" or a "game" rather than a form of abstract combat with winners and losers. Changing the underlying metaphor may change how you see something.

Once upon a time (but somewhat passe these days)the underlying metaphor for software development was "constructing a building (or bridge)" from which we still have "architects" and "engineers" , UML "modeling", and so on.

These days there seems to be a shift of metaphor. The underlying metaphor for much discussion on software development seems to be "Software Development (of the services variety) is an assembly line process".

The so called "Lean Development" (or "lean agile" or whatever the fad du jour is) talks about "pieces of work" being "flowing" through a development "pipeline" and endeavors to "reduce cycle time" through "kanban" using the "Toyota Production System".

Using this metaphor, software developers become equivalent to assembly line workers which managers or methodology experts "optimize". You can work on a "good" assembly lines like Toyota, where you have a degree of freedom to tinker with some of the details or a "bad" assembly line (uhh Wipro maybe? ) where you endlessly perform the same meaningless motions forever.

There are "kanban" or "lean" or "agile" experts out there who will "advise" you on how the assembly line should work, but will never work on an assembly line themselves! The assembly line worker doesn't have any choice on what he will work on, how long he will work on a particular assembly line, practically never comes into contact with a real customer (at best there is a "customer representative" or a "usability expert"), is relatively easily replacable. "Requirements" from an analyst "flow" to a developer and then "flows" to QA dept and so on ad infinitum.

The funny thing is that most developers subscribe to this metaphor.

I choose to think of programming skill as just that. A skill. Just because you have a skill at metalwork(say) you don't have to work on a boring job on a third world assembly line. Developers who build startups step beyond the "assembly line" mentality. They choose what to work on, how to work on it, what technology to use, what customers they target interact directly with their customers and so on. Others choose to work on opensource kernels or compilers. Others are dragged kicking and screaming into Project manager-dom.

Of course, you don't even have to make your money with your programming skills. You can be an investment banker (or astronaut or actor or musician) and do your brazing and welding on the weekends.

In my (totally personal) view, knowing how to program well is like being literate in a largely illiterate world. One day everyone (or almost everyone) will know how to write. But in the meantime you don't have to work as a scribe just because you know how to write. You could be a general or merchant or prince or cleric or warrior for hire or Dragon Slayer (umm ok note to self - less D & D) and your writing skills would give you a significant edge over your illiterate peers.

Just because you are a good programmer (you are, aren't you ? ;-)) you don't have to work for that 200,000 employee outsourcing company 12 hours a day on systems you don't care about with "industry standard",read "middle of the road" technology.

Unless you choose to.