Friday, March 13, 2015

Sophia Dagli - Rest In Peace

Sophia Dagli

Will always remember your energy and enthusiasm. I will miss our the rare but long discussions. I will miss a True Friend.

Rest In Peace

Sophia on Facebook
Sophia on Slideshare

Share your memory of Sophia on "In Memory of Sophia" page

Monday, February 02, 2015

Introspection : am I really a good programmer ?

Sometime back Prateek Jain posted a link to an article title 'Signs that you're a good programmer' on Geometric's internal portal. It has list of 'signs' that you are a good programmer. It made me introspect and see how signs actually apply to me. Turns out that by this checklist, I am a reasonably good programmer. :-)

I realized I have done following from the list.
  1. side projects.
  2. Dabbling in other programming languages, especially ones from a different "family".
  3. A tendency to suggest wacky and unrealistic solutions in meetings.
  4. Willingly throws away weeks or months of work in order to adopt another programmer's superior code.
  5. Refers to it as "the code" rather than "my code", unless accepting blame 
  6. Doesn't take the spec by its word and tries to find out who wrote it and what they were thinking
  7. Owns a book written by a guy called Martin Fowler. (Actually I own multiple books by Martin Fowler)
  8. At least 10% or more of their commits reduce the line-count of the project without adding new functionality
  9.  Shoves through a crowd at a party to get near someone who just used the word "Bayesian"
  10. Envies but doesn't resent people with degrees in something they don't know 
  11. Blogs about their work 
  12. Not hesitant to pick up a marker and approach a whiteboard 
  13. Commits changes to the repository that consist only of comments (but not commented code)
  14. Is oblivious to how many times their cubicle-mate has gone for coffee, the bathroom, or the hospital (I don't even hear any sound if I am concentrating on the code).
  15.  Not bothered by office politics 
  16.  Can predict a bug before the code is ever run  (Done that a few times)
  17.  Assumes their own code is the source of a bug before blaming the compiler, library or operating system
  18. Disinterested by the outcome of elections 
  19. Stock options and bonuses are ineffective 'retain'-ment techniques 
I have done all the signs/symptoms in section "Thinks In Code"
  1. In casual conversation their readiest metaphors come from programming constructs (some time back I gave an example of classes/instantiation while explaining 'business offerings')
  2. Spends the majority of their time "goofing off", but commits more bug-free code each day than their colleagues
  3. Glances over your shoulder and points at a bug in your code with their finger
  4. Correctly diagnoses bugs over the phone while drunk or in bed
  5. Comes up with their best code while taking a shower*
  6. When confronted with an obstinate bug, their instinct is to get up and go for a walk
  7. They suddenly pause and stare into space in the middle of a conversation, then abandon you to hurry back to their terminal with no explanation (AKA "A Columbo Moment" or "Gregory House behavior")
Also few signs/symptoms in "Indifferent to Hierarchy"
  1. Getting into arguments with the CEO (done that, probably multiple times, still in Geometric because I like working with Geometric CEO, Manu Parpia)
  2. Quitting on principle 
  3. Organizing teams without permission (I believe its easier to say 'sorry' than get permission)

Overall not a bad score. 

Sunday, August 24, 2014

Classics of Computer Science

Some times you hear about quotes from Edsger Dijkstra like 'goto considered harmful'. However, you rarely find the details of actual arguments. So I have decided to collect such gems which I consider classics, which someway helped me understand new concept and references/links to original papers/books.

I am planning to keep on updating these list.

Papers/Articles of Edsger W. Dijkstra:

  1. Humble programmer 
  2. Goto Considered Harmful :  Transcriptscanned PDF of original paper 
    This paper introduced concept of 'structured programming'

Papers/Article of David Parnas:

  1. On the criteria to be used in decomposing systems into modules,
    Written in Year 1971, this paper introduced basic concepts of object oriented design (especially concept of encapsulation). I find that programmer still confused the concept of 'encapsulation' as 'hiding the data' rather than 'hiding the change'

Papers/Articles from Google

  1. MapReduce: Simplified Data Processing on Large Clusters
    Paper that triggered big data processing architecture revolution and triggered the opensource Apache Hadoop project.
  2. Detecting influenza epidemics using search engine query data
    Demonstrated how big data analytics can be used to solve some existing problems in entirely different way.
    "Here we present a method of analyzing large numbers of Google search queries to track influenza-like illness in a population. Because the relative frequency of certain queries is highly correlated with the percentage of physician visits in which a patient presents with influenza-like symptoms, we can accurately estimate the current level of weekly influenza activity in each region of the United States, with a reporting lag of about one day."
Please add your comments, suggestions for inclusion in this list.