When hiring for a "hot" technology

I ran across this article, which outlined a manager's thought process when deciding whether to overpay some entry-level developers due to skills in a particular technology:

http://itmanagement.earthweb.com/entdev/article.php/3921006/Should-Younger-Developers-be-Paid-More.htm

When going over the pros and cons of hiring these developers, the author failed to look at the fact that these entry-level developers with skills in mobile technologies are still just entry-level developers.  Many of the skills learned in the course of programming are easily transferable from one medium (web, desktop, mobile, etc.) to another, and these skills are usually best learned through experience.  So what else could the manager have done?

I think this is a perfect opportunity for the company to hire temporary workers.  These workers could be paid relatively large amounts of money without needing to worry about having over-paid employees on the payroll when the supply for mobile developers catches up with demand.  This has the added bonus of making the salaries more justifiable to existing employees, since it is reasonable to pay your current employees less salary in exchange for more stability.

What other options do you see available?

Multitasking

I came across this blog about the drawbacks of multitasking.  I have noticed that I can get more done if I simply focus on a single task at any given time.  I also find my work more enjoyable, and I usually have more energy at the end of a day with a smaller amount of multitasking than the other way around.  While I multitask occasionally, I try to avoid it whenever possible.  Then I read this rebuttal and realized that "multitasking" can mean different things to different people.  So how would I define multitasking?

• Focus your attention on a single task at a time.  If another issue emerges that is more important, that should get 100% of your attention.  If it is not more important, then it can wait.
• Multitasking is about the attention to a task and does not refer to the number of thoughts you must keep in your head at any given time

So avoiding multitasking doesn't mean closing off all contact with the outside world while you're working on a particular task.  You could designate certain times during the day for contact for non-urgent issues, with the understanding that you would be available by phone at other times if needed.  You could treat e-mail the same way - check e-mail periodically throughout the day, but only respond to non-critical e-mails at certain times.

Avoiding multitasking also doesn't mean that you can't put aside a particular task if you're stuck.  It means focusing 100% of your attention on whatever task you are trying to accomplish at any given moment.  If you are not making any headway, going to another task temporarily is not multitasking in my view; it's serial single-tasking.

Finally, the author of the rebuttal blog seemed to think that doing complex tasks qualifies as multitasking.  As a programmer, when I get a request for a feature change to software that I'm building, I need to consider many different ideas:

• The most effective way to implement the solution
• The needs of power users
• The needs of the first-time user
• Costs for my client
• Unintended consequences that might arise because of my fixes

However, all of these ideas are working towards a single goal: determining how best to implement a feature requested by my client.  It is a single, multi-faceted task.  When a single task gets too complex to control, then I break it down into multiple tasks and address each one separately.  I'm still not multitasking, and by single-tasking the components I have an easier job putting the pieces together in the overall task.

So if multitasking makes one work less effectively and accomplishes nothing worth noting, then why do it on a regular basis?

Tips for mentoring others

LHere is a great blog post that was written about mentoring new programmers, but could easily be applied to other disciplines and experienced hires too:

http://blogs.techrepublic.com.com/five-tips/?p=212

These tips are rather incomplete, though.  I'd like to expand on their tips:

1. The issue with mentoring seems not to be lack of will, but lack of time.  More on this in a bit.
2. Make sure your road map covers more than just the first few hours.  It is all well and good to show the new employee the location of the documentation, but have a plan that covers at least the first six months.  This plan should include ways to make the employee more independent as time goes on.
3. Be tolerant of mistakes, but try to prevent common or serious ones.  Confidence building is key.
4. Try to assign projects at first that have a training purpose as well as a practical purpose for the company.  This should be a mixture of easy projects to give the employee confidence and stretch projects to keep him or her engaged.

While most of us would agree with these tips, very often they're not followed.  Why?  The biggest reason seems to be that people usually aren't hired for a potential need, they're hired to fill a current one.  While that approach lowers the risk for the company of hiring someone who will need to be laid off, it also makes it harder for managers and experienced co-workers to get the employee up to speed in a fashion that benefits both the employee and the company.  The easiest way around this that I can see is to keep track of potential future needs (perhaps by using risk modeling tools such as these) and hire based on that.  Outsourcing and contract-to-hire positions can mitigate the risk of over-hiring, if needed.  Good mentoring is a lot easier when one feels like there is time to do it well.

Programming assumptions

A database specialist and blogger I follow came across this post:

http://stackoverflow.com/questions/888224/what-is-your-longest-held-programming-assumption-that-turned-out-to-be-incorrect

which got me wondering, what assumptions have I made that turned out to be incorrect?  The one that came to mind for me was the idea that going to the database is slower than pulling in all the data you need at once and querying the stored data when necessary.  It really depends on your situation.  When you don't have to deal with remoting or firewalls, it is very often faster to query the database than to use a stored list.

More importantly, though, this question should make everyone ask themselves: what assumptions do I make today that are based on incomplete, out-dated, or inaccurate information?  A post like this one is good in that it helps everyone to see what assumptions had been proved false and allows all the posters and readers to learn from others' mistakes.  However, the goal should be to question our current assumptions, not just take pride in previous lessons learned.  Looking back is certainly a valuable exercise, but looking for new lessons to be learned is more important.

The 60 hour work week

Here's an interesting article about the effects of working more than 40 hours per week:

http://archives.igda.org/articles/erobinson_crunch.php

Basically, it states that the output you get from an employee who works 60 hours a week is roughly the same as one who works 40 hours a week.

So by pushing employees to work longer hours, a company is not only likely driving away its best employees, but it's also not getting any more work out of the employees who stay.  I have to think this is more pronounced for I.T. workers.  Since most of the good I.T. workers I've encountered get energy for their job by working on fun projects on the side, they would likely approach burnout quickly as a result of working too much.  What makes matters worse, burned out workers produce less, which in turn increases the pressure put on them, which increases the feeling of burnout, which in turn lowers productivity....  You get the idea.  I can't see any advantages to pushing employees this hard, so it's a wonder so many firms out there do it.

Should programmers be middle managers?

Recently, I wrote about whether programmers should get an MBA here, and said that an MBA would be helpful for the programmers who wanted to get into management.  Related to that, I came across an article on CIO.com about the inherent skills needed for programmers, middle management, and executives.  I don't have any particular insight into the article, or what it means for I.T., other than it's an article worth reading.  I think I might put the book on which the article is based on my reading list.