Resurrection Part 2

My new blog is here.

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.

DevCamp - A report

I am still "offline" but due to popular demand, here is a very brief report on Devcamp.

Bangalore has long missed a conference for serious developers. In Bangalore you often find methodology based conferences (like the Agile confeences) or various company sponsored conferences which are thinly disguised propaganda pitches (Sun/Oracle/Microsoft Tech days for e.g). There weren't too many conferences where people who code (and like to code) could get together and exchange notes with likeminded souls.

DevCamp plugs that gap very neatly. The organizers had explicitly filtered out the usual "hands on training on blub framework X or Snake Oil Methodology Y" type events which proliferate locally.The blurb for the event read "Please assume a high level of exposure and knowledge on the part of your audience and tailor your sessions to suit. Avoid 'Hello World' and how-to sessions which can be trivially found on the net. First hand war stories, in-depth analysis of topics and hands on demos are best". Consequently, most sessions were very compelling, with people demoing their pet code bases and showing off cool hacks. People projecting code (vs slides) and actually coding on stage, made this event a refreshing break from the usual slideware based mumbo jumbo. The unconference format was a particularly good fit, because you didn't have to distort your session to fit some arbitrary conceptual boundary.

I couldn't attend as many sessions as I wanted. But I did catch Bejoy's's LinQ presentation (decent, though a bit shallow), Karthik's Erlang Testing tool (when this is finished it will bury JMeter) and Vivek Singh's session on White (brilliant, brilliant work!). The sessions I would have liked to attend but missed out on were the one on MOOSE and Siddharth's presentation on running linux on a Nintendo DS.

Thoughtworks organized the conference with clockwork precision and everything flowed smoothly. It was great to be back at TW and meet my ex colleagues - which brought home to me (again) how much I miss working with bright opinionated people- aargh I have to fix this. . I am (very) glad I don't write enterprise software any more, particularly the outsourced variety, but I do miss working with bright people.

So what could be improved? Not much really. One of the projectors didn't work with Ubuntu so I had to switch to Windows (bleh) for my presentation. My talk on monads seemed to go down well. Explaining esoterica like monads in a 30 minute session was an interesting challenge in communication, but it turned out ok. I had requests for a repeat session but I was too exhausted. - Some other day. The AC and the network conked out occasionally but these were very minor issues. There were a few too many (imo) "passive" attendees who wanted to listen more than speak, which is against the Xcamp ethos but I am hopeful that will change. Another thing future organizers need to watch out for is disguised product/recruitment pitches. There were at least one "you can code against our APIs and help us make more money" talk with zero technical content. Again not an issue for this conference , but something to watch out for in the future. All in all, a very refreshing change form the usual frivolous frothiness of the BarCamps. Not a single "blogger" or "seo marketing person" or "movie club member" in sight. Just developers and code. Bliss!

Devcamp is something that Bangalore really needs. I look forward to the next one.

[Ann] Blog Lockdown till March 15th 2008

I am "away".

Regds,

Ravi

P.S.: I am attending Devcamp. Sorry for the confusion.

About GRE scores

Ever since I published my GRE scores on this blog, many people write to me asking me how to prepare etc. After writing the nth email with the same content, I thought I'll write the "official" answer here once and for all.

This is the "official" answer to "What advice can you give me on how to prepare for the GRE"?.

The answer is "Nothing"!

I skimmed the Barron's guide vocabulary section and the (16 iirc) sections (in the same guide) for the quantitative section to refresh my memory one day before the exam. I was overloaded with work then and had no time to prepare.

My exam was scheduled for 8 o clock in the morning and I was awake till about 05.00 working on a program. Since I got only about 2 hours of sleep, I was in this weird half asleep/awake state, which had the effect that I was totally relaxed and did not have the bandwidth to track the time remaining etc. I just answered each question as it came up. I got the very last question in the quantitative section wrong because for the first and only time I checked the clock and found I had like 3 seconds to answer and so I panicked and randomly clicked an answer(which turned out to be wrong). Oh well.

Beyond the above I have nothing to say on the GRE. Don't bother asking.

Engineering - Some Working Definitions

This is the third in a series of four blog posts. Read parts one and two, to get some context

Dr Douglas Lauffenberger's (from MIT's Biological Engineering Dept) talk (warning - mp3) provided enough ideas for a (sufficient for my purposes) working definition of "engineering".

(paraphrase begins)

Dr Lauffenberger begins by breaking down engineering into two aspects - science ( the study of things that exist ) and technology ( making things that don't exist).

So,

engineering = science (analysis - studying things that exist, break down into components, and methods of combining them) + technology (synthesis, building things by putting together the components identified by analysis ).

Engineering further adds a "design principles" (how things get put together) focus to both analysis and synthesis.

All engineers study mathematics. (This is a given).

An engineering discipline has a base of science for its components and methods of combination. A branch of engineering picks a branch of science to base itself on. So, for example, Mechanical Engineering has a base of Physics and Materials Engineering has a base of Chemistry ( + Physics and the omnipresent Mathematics).

Another way of thinking about engineering is

"measure (properties of systems of interest), (use mathematics to ) model, manipulate (components and methods of combination, guided by the model) and make (things that don't exist)". --> (1)

Yet another way to think about engineering,

Engineering = mathematics + science + application area --> (2)

There can be various combinations of (and subcomponents to) each of these three components.

The "science" component in that equation needs to be manipulatable, quantifiable, modellable etc.

(paraphrase ends)

Later in the speech, Dr L goes into why Biology only recently became modelable etc and so before that, how the various branches of BioEngineering used Physics, Chemistry etc as the underlying science, rather than biology. Biology was often the "application area", but not the underlying science. Thus at MIT biology would be a minor and other engineering disciplines like mechanical or electrical engineering (including comp sci like robotics and algorithms) would be applied to a biological domain like pharmaceuticals or prostheses.

Dr L goes on to explain how this changed and why and how Biology is, these days, a science you can base an engineering discipline on (and you really ought to listen to the full speech), but for the purposes of this post (1) ind (2) are what I am interested in. ie,

engineering = mathematics + science + application area and

(doing) engineering = measure (properties of systems of interest), ( use mathematics to ) model, manipulate (components and methods of combination, guided by the model) and make (things that don't exist).

I suggest that programming fits into the "model" part of things, complementing mathematics. This is just an insight, not rigorously tested etc, but there are a couple of straws in the wind that make me think I am right.

First, a scientist I work with explicitly identified the combination of programming and mathematical skills as a "force multiplier" that enables someone who has mastered both to zoom past someone who is strong only in one, explicitly mentioning a programmer (a genius at programming, way better than I am, who couldn't make as much progress as I could because he couldn't wrap his head around the "maths as a modelling tool" idea) and another person, a scientist this time, who gets stuck periodically because he couldn't write production quality code.

There are analogues in enterprise programming where someone who has mastered a domain *and* programming can provide an order of magnitude more business value (which is the main metric in enterprise programming) than someone who knows only banking or J2EE.

Richard Hamming says in his speech "You and Your Research" (if you haven't read this you really ought to do it right away!)

"... ``How will computers change science?'' For example, I came up with the observation at that time that nine out of ten experiments were done in the lab and one in ten on the computer. I made a remark to the vice presidents one time, that it would be reversed, i.e. nine out of ten experiments would be done on the computer and one in ten in the lab. They knew I was a crazy mathematician and had no sense of reality. I knew they were wrong and they've been proved wrong while I have been proved right. They built laboratories when they didn't need them. I saw that computers were transforming science because I spent a lot of time asking ``What will be the impact of computers on science and how can I change it?'' I asked myself, ``How is it going to change Bell Labs?'' I remarked one time, in the same address, that more than one-half of the people at Bell Labs will be interacting closely with computing machines before I leave. Well, you all have terminals now. I thought hard about where was my field going, where were the opportunities, and what were the important things to do. Let me go there so there is a chance I can do important things. ..."

If that were true in 1986, when Hamming made his speech, how much more true is it likely to be now?

The mistake most scientists make is to consider programming a "blue collar" activity, not worth focusing on (this might be true for the top 1% or so whose native genius will carry them through, but most scientists I know can use all the tools they can get). I hypothesize that in the 21st century a scientist (or engineer) who can't code is handicapped - not so badly as a poor public speaker or a poor writer would be (and both are very vital skills for a research career), but handicapped nonetheless. Maybe there is a case for making (say) SICP + python + algorithm analysis + usage of basic version control tools a part of the science curriculum.

The mistake most programmers (who loathe their cubicle farms and the brain dead enterprise codebases they maintain) make is to think that research and engineering are somehow beyond their ability to tackle. One crucial contributing factor to this perception is that most people learn mathematics as a bunch of formulae to memorize for an exam than as a powerful modeling tool that penetrates and simplifies complex systems. It doesn't help that, in India at least, the engineering and science educational system is fundamentally broken and emphasizes rote learning and obedience to authority over curiosity and intellectual rigor.

I write my blog to help me clarify my thinking. I couldn't care less if no one reads it. (Having said that, I have "met" some brilliant people through the blog). This and the two preceding blog entries came about because I have been struggling with nailing down a research statement - something beyond the current "I am interested in Robotics and Compilers". One of my mentors asked me to do this. I think this is good advice. More on this in the next (and last in this series) post.