Sunday, April 29, 2007

Which Programming Lanuguage Are You?

I took this quiz which claims to determine which programming language your personality matches with. Mine turned out to be Modula-2 (strangely i had never heard of this language ever before).

You are Modula-2. You enjoy teaching others, but your rigidness tends to make them dislike you.
Which Programming Language are You?

I don't completely agree with this result nor do i agree with some of the descriptions of the other languages but what the heck.....i am killing time anyways.

Saturday, April 28, 2007

Python revision - Book review

Yesterday i found the book 'Learn to Program using Python' by Alan Gauld in the office. Since i had a few hrs to kill i decide to quickly go through the book.

I have been using python for almost a year now but strangely i have never had any sort of formal training and neither have i learnt python in a structured manner. Its mostly been task based which always makes me wonder if my coding style is indeed the correct way to do things. So i was excited about the prospect of reading this book and learning to do things the right way.

So i sat down to read and within an hr i was on page 100 (which is quite significant considering the book has just 270 pages). I realized that my knowledge of "basic" python was quite good, infact what i was really yearning for was indepth understanding of concepts and good practises and the book didn't quite provide this. That said it was wrong on my part to expect such topics from a book meant to be introductory text for python. That said the book in itself i quite good, it has small chapters and simple language and is a must read for early adopters of the language. I wish i knew about this book a year back.

I did come across a few feature i didn't know about, like:

1. dealing with binary streams, esp using struct.pack(...)

2. nested try/except. I had always hated the fact that you cannot use try-except-finally in a single construct but it never occured to me that i could achieve the same by nesting these clauses,eg.


This ineffect gives me the same functionality as,


NOTE: this is now allowed in python 2.5

3. Another thing i came across (not in this book but i feel this is the right place to record it) is the technique to create a list from another list.

Earlier i used to do the following:

l = [list of objects with method 'id']
k = []
for obj in l:

I always thought this was too much code to achieve too little. So after a bit of searching i discovered the following trick:
k = [ for obj in l]

Now i create new lists in a single line instead of 3, a 3X productivity improvement :D

Monday, April 16, 2007

Back to CODE!!

    Since i have moved to US my job profile and lifestyle has taken a giant leap. I come from an engineering background where the ultimate fantasy in life is to work on some exciting piece of code. Our sense of adventure is limited to trying out a new design pattern or some new framework. We just love sitting in that dingy corner with our giant LCD screen and a powerful PC and churn out line after line of code which we are not even sure if anyone would use it.

    Then i moved to the realm of professional services. Now suddenly i was out of that dark corner and talking directly to customers (i.e. people who actually use the piece of code). It was a earth shattering experience because now i was actually selling what i wrote. This tiny bit of exposure suddenly opened up a lot of doors and answered some questions that i had always wondered about but never found an answer too.

    The biggest pleasure an engineer/developer can ever get is when someone actually uses a feature he/she developed. This takes us to the next question, how does one develop something useful? The answer is customer feedback and this is possible only through customer interaction, direct customer interaction. Strangely a lot of companies do not believe in this concept. Generally the engineering team is fed inputs by a product manager who is supposed to understand customer needs and then translate them in a language engineers understand. Although this sounds promising but there are a lot of dependencies attached to it, like the ability of the PM to correctly capture requirements and then explain the same to the related engineer. Thats expecting a little too much from one person and even if it does work i don't think its a long term solution. Ideally i would like to

involve the respective developer in the requirement gathering process, this way s/he know exactly whats expected out of him/her.

    Well i had such a chance a few days back. As part of services i had to go to a client site, gather requirements , design a solution for them and implement it to. I think this is one opportunity you would kill for. So currently i am quite excited with the turn of events and looking forward to going BACK TO CODE...............

Powered by ScribeFire.