Friday, April 15, 2005

Options!

This one is abt options; one of the characters in a novel I read long time back ("No comebacks") was reported to be use this approach. He used to evaluate all the available options, take into consideration the pluses and minuses of each, and then pick up the safest and the most suitable option for his context.
Nothing new! Probably a lot of people do this already. So? I was amazed with this being documented and written with clarity. So called managers of the world might have given this a fancy name and must already be practising this, preaching this. But you don't need to be a manager to do things smartly! (no offence meant!!)
This was for the real world.
What I always tell my team is abt the relevance of this in software developement:
Understand why one approach is preferred to other ones existing. It helps you understand and evaluate the best of the available options. You get into such situations when you have to evaluate a bunch of frameworks, vendors to work with your product or application.
From my side, I make it a point to forward to the team, some important mail conversations that discuss the pros-cons of available options. I believe its a good way to learn things.

Friday, April 08, 2005

Guys we come across

Ok, this is once again outta context!

Interviewd a guy with 3 yrs of software programming experience in the skills that we desire. From the earlier rounds of interviews taken by a colleague, the feedback was this guy was decent with basic fundamentals and very confident.

He'd quoted having worked on frameworks like Struts, Hibernate and Spring. As usual, I started off with digging into the internals of Struts, and caught the guy in a few mins.
The guy had superficial knowledge of Struts, which may be considered OK by others, for working on projects. I have this habit of testing the knowledge of how-things-work, in interviews or in conversations with my colleagues/team-mates. When we hire experienced guys, I insist that they really know how things work the way they work. So, it may sound very demanding, but I think it matters a lot when you're designing/developing anything new, maintaining existing code or debuggin a problem. These open source frameworks are a result of greate efforts by people in the open source community; a lot of thought has gone into developing these and making them robust and industry standard. There're definitely many design priniciples that one can learn from and use in their own work.

Thinking back, I think I did the right thing when I rejected the guy.

Will have to talk to my superior though, whether I shd be this insistant going further!

:)