Not so functional yet

Functional programming still seems an elusive concept to me -- something that I am trying to pick up but can't yet apply anywhere. The big boost came from the SICP lectures by Sussman and Abelson which I started watching from sometime in the middle of the year. Now, as the year is about to end, I have watched only till lecture 4A. And I cannot think of any way to apply what I have learned. A few days ago I was watching a talk called the 'The Feel of Scala' and I felt Scala was nothing but Java with a powerful front-end which does a lot of rewrites. Nevertheless it was clear that the features provided were for functional programming. Yesterday I downloaded Scala and tried to get the basic control structures and syntax. But again, I hit a wall when I started thinking -- where do I use these features? I know Scala is giving me immutable lists but so what about that? Maybe I'll have answers after I finish the SICP lecture series.

The first task

I could have written this entry in my general blog as well, since unlike regular technical blog posts this one doesn't involve any code. But I am choosing to put it here because I feel it is an important topic which all technical teams need to understand.
Let me get down straight to the point I want to make - how the developer you hired will perform depends a lot on what is the first major task you give him/her. Don't give your dirtiest task which others in the team are 'too important to do'. I have seen this happen to different people 4 times in my 9 year career. Yes, it once happened to me as well, long ago.

So what I am talking about is the following sequence of events:
1. New candidate is joins a technical developer position after tremendous technical interviews
2. A few days after joining, the 'technical' manager asks the candidate to do one of the following as a prime activity for some time:
a. analyse everyone's regression failures every day and/or delegate them to the right engineers
b. manage some infrastructural role for keeping the codebase in sync with components it depends on

I have observed this so far in Indian technical teams only. I don't know if this is a fall-out of our society's caste system where some 'dirty' work is left to be done by a certain group of people only -- that is something for sociologists to comment on! But in effect it is equally devastating to the new candidate's morale and growth.
I guess some 'technical' managers dream of this as the ultimate way to get started with understanding a new product and team. They could not be more wrong. The best way to get someone started is to give him/her good problems to solve. I understand the best work has to be reserved for more experienced candidates, but nothing can justify giving some non-development tasks to a developer at the beginning. I also appreciate the need for developers to be able to do all such stuff, but that should come in time after a developer has started contributing smoothly to a codebase. Only after you have started managing own your work well can you afford to do some housekeeping for others.