Work history June 2005-Oct 2007

Work history:

 - Around 5 requirement specifications.

 - Around 5 complete functional  and technical specifications.

 - More than 15 designs and implementations.

 - Project engineering manager - enterprise manufacturing intelligence solution for IMAX.

 - Software engineer – framework for a HMI solution (IMAX).

 - Startup - created ReviewOften.com.

 - 3 Managers.

 - No confirmed HR voilations.

Google web history and personalization

Google announced web history a few days ago. It makes it easy for users to view and search the pages they visited. The interesting thing about maintaining this history by google is that they will have at their hands a very powerful personalization tool. They would be knowing what people are interested in. They can actually tell what a person is interested in. They can tweak their algorithms so that my searches are according to my interests. Its like a step towards very intelligent searches. I mean your searches will not only be reflecting your search history but your web history.

The question is though, do you want your web history to play a part in your search results. I mean identifying interests is one thing but do I want my search results to be affected by my interests? Personalization sounds like limiting my circle if search. Do you really want that? For example, if google knows that im interested in software and i search for “zip”, it brings me results for the highest page ranked compression/uncompression software, taking for granted the fact that since I am interested in software “zip” would be meaning “zipping software”. Now what if, what I really mean from “zip” is my jacket zip? I can mean that, can’t I? But this personalization might be narrowing down my domain of searches which I really don’t want.

So, I am really looking forward to know how google has brought personalization and web history together and what impact this is having on my search results. We can only know that over time.

Benchmarking – not just for selling

I want to talk a little about performance  and usability benchmarking of the software product you develop.

Benchmarking is usually used to quantitatively measure the developed product against other competitor products. It is done to get some figures to sell a product (because of the undeniable fact that management loves numbers, and if the numbers say your product is doing better than IT IS doing better). This means that when the product is near to shippment, it is benchmarked to see how well it does. Is it really the right time to do that?
     
The real question is though, do developers need benchmarking? Do they care about numbers? No they don’t. To tell you the truth, they care about what numbers say less than their work chairs. But that doesn’t mean you don’t have to do benchmarking until the last minute, when there is nothing which could be done about it. To improve performance, you need to identify bottlenecks and benchmarking is the best way to do that. Developers must know the performance limits of each and every part of their written code. Without that they can’t improve it.

Actually most of the software developing houses keep their focus on features at first and then on bug fixes and then comes benchmarking. All these things should keep on running in parallel to acheive performance and usability  goals and acheive them rapidly. I believe that development decisions could be greatly effected by benchmarking and it should be done where ever possible, may it be deciding which third party component to use or which technology to start with.

“Small” code or “Less” code?

A lot has been written about how programmers should aim for writting “small” code (actually I was just reading Jeff’s post). But programmers usually mis-interpret the term “small”. Small code does not mean that you start reducing lines by trying to push everything in one line of code and eventually make it a meaningless gibberish that not even aliens can understand. What those people really mean is that if you can get the same amount of things done with “less” code then do that. Make it small by thinking of a smarter way of doing that thing. Or using a better data structure. Or removing useless variables. Or removing repeated code.

Reducing code by doing something like the following is not always of much help. At times, its worse actually.

var c = F1(F2(F3((a==b) ? F4() : d)))


One of the most important use of smaller code is to make it easy to manage. I am not making it easy to manage by writing something like the above code. I am making it even harder to understand and hence even more difficult to manage later on.

Write ”less” code. Keep it clean and easy to understand. Write comments. Use meaningful variable names. Have fun!

What can we learn from packaging?

Last week I was going through this flu phase (weather change or I don’t know what). Anyways, instead of taking all those heavy anti-biotics to strengthen my anti-bodies alongwith my will to die, I decided to get packets of a herbal tea, Joshanda.

At night when I was so down with flu that everything seemed blurry, I decided to give Joshanda a try.

I tried opening the packet by the usual chips packet opening method. I wasn’t able to open it.

I tried tearing the corner. I wasn’t able to. Not even with my teeth.

I couldn’t find that black box printed, which usually tells which side to try opening either.  I couldn’t think of anything I did wrong to whoever designed that packet either. Did they not want me to open the packet easily or something? They probably wanted to pack it good enough, so Joshanda’s essence doesn’t go out, but was that the only way of doing that?

I finally decided to use a knife, which I thought would definitely open it. Even that slipped off the glossy packet the first time.

I was almost crying with annoyance when I finally got it open and when I did, the water I had boiled had got warm. I poured it in anyways and had it. It was good and it helped my flu too but I just didn’t knew if it was good enough to go through all that trouble of opening that packet.

I realized how easily usability is neglected while designing products. I’m sure each of you would have realized this while using one product or another.

Dilbert’s chair

I want to calcuate something about a software engineer. Lets call him Dilbert. Dilbert works around 8 hours a day. He sits 6 hours from those 8 hours in his chair. Thats one-fourth of his day. He works 20 days a month. Thats 245 days a year.

1/4 of 245 = around 61 days of work in a year

61 / 365 X 100 = around 17 %

If he works 40 years of his 70 year life then 40/70 years of 17% = 9.7 %

9.7 % of his life, Dilbert will sit in his work chair.

I don’t know about you but if I was Dilbert, I would want that chair to something awesome. I mean may be not like Santa’s rocking chair but still, it has to be awesome.

“Its the class of code you write”

I’m an Arsenal fan. I love to watch them play. I love their strategy. I love their team play. Its like they are kings of soccer. The weird thing is though, Arsenal doesn’t have the best record of winning games.

When I listen to their manager I get a feeling that he doesn’t really want winning. I mean he obviously wants that but not as much as playing better soccer. And to tell you the truth, that is one of the most important things you need. I mean really, is it about winning matches or about the class of soccer a team plays? Don’t you like a team more if it plays better, even if they loose a few times,  then a team who just wins somehow (not necessarily by playing better)? I mean we all know not the best team has to win always.

And you can see when a team has class. It could be just a tackle or an awesome pass or any other moment of magic they show. Like a beautifully written block of code. Or an easy to use, simple user interface. Right?

On Ruby On Rails

Of the following 3 methods of iteration commonly used in Ruby, for loop one is the most optimized one.


10.times do
#do something
end

1.upto(10) do
#do something
end


for i in 1..10
#do something
end

Oh but what the heck, I want better code readability at times. When I can, I love to use the one which sounds good…!

Digg deeper: Stack, Swarm & BigSpy

Digg is supposed to tell us which content users think as worth reading. In simple words, its a place where users rate stories by voting for it (Digging it) or against it (Burrying it). It’s really important that this information is represented well. The question is that by looking at the story listing and its Diggs, can we really judge if the story is worth reading.

I mean, are users more interested in reading whats popular or whats getting popular or what getting popular more rapidly. Consider the movie ratings at imdb (http://www.imdb.com). If a movie is rated 10 its doesn’t necessarily mean that its a really good movie. You have to look at the number of users who have voted for it also. If more people have contributed to the 10 rating THEN its good. So if a new movie gets listed, then its rating would be very unreliable.

How Digg took care of this problem is that you can view digg lists of a certain period of time (24 hours, 7 days, 30 days and 365 days). For new stories I will look at the 24 hour list and the Diggs for those stories help me judge whats popular.

To Digg deeper, Digg labs have introduced Stack, Swarm and now recently, BigSpy. http://labs.digg.com. These are real time representations to tell whats popular.

Stack. Stories are represented by stacks of diggers (represented as small blocks). Around 100 stacks are lined up and the diggers are falling from top and stacking up on the story they are reading. The bigger the stack of a story, greater the number of people who read it. Diggs are represented by the color of the stack. The brighter the color, greater the diggs. So, besides telling how many people voted for a story as worth reading, it also tells how many people actually read the story (it doesn’t tell the actual figure but it gives an idea).

Swarm. Stories are represented by small circles and diggers (represented by smaller yellow circles) swarm around these circles and make them larger. So the size of the circle gives an idea of how many diggers read the story. This representation shows less number of active stories but it also gives an added information. It tells how many diggers are reading the story currently and how they move to another story when they are done reading.

BigSpy. The representation lists the story titles as they are being dugg. So its kind of a real time list. The newly dugg stories keep coming from the top nad keeps pushing the older stories down. The font size shows the number of times a story is dugg. Its more oriented towards whats being dugg recently. Although it doesn’t give some of the information which stacks and swarms give, it is much simpler to follow.

I think different representations would work for different people but its important to have a real time representation to give a better idea to know whats popular, whats getting popular and whats getting popular more rapidly.

RSS feeds to GIF files

Check out http://www.rsstogif.com
All you have to do is enter the URL of the RSS feed and modify some settings like the background color you want etc. and it generates the HTML for that image. The idea is that you can transform your RSS feed into an autoupdated image.A very interesting use could be to use the image as your signature in forums or email.