Monday, December 14, 2009

Part 4:: Who I Want To Hire and Work With::Can they learn

What have they done and what are they doing to learn?

Coninuing and hopefully finish, at least for now, my toughts on hiring I want to talk about learning. Probably the most important thing a programmer does. We have talked about fitting in the team and problem solving but learning is what creates a true long term employee and team memeber.

Learning is the one thing programmers must continually do. Since what we do is solve problems and the problem is continually changing so we must continue to learn. The IT industry is not stagnant and it is not mature. We have new languages, new APIs, new techniques, acronyms and more. Learning along with problem solving go hand and hand and are the most important tasks for a programmer or knowledge worker of any type.

Did they learn from past failures?

We learn many ways and all teach us differently. We learn a lot from failing. Did we do something wrong? Did we NOT do something we should have done? If you have done any development at all you have seen failures both big and small. Sometimes it is a simple direction chosen for a design that was recoverable. Was the design chosen to soon before we had enough information? Was the design chosen with a bias because of past experiences that did not match the current situation? Sometimes it is a combination of too many things and no one admitted it until the end when it was too late to recover. But we learn a lot from these failure, well we should. But too often we keep repeating them.

I also like to see who gets blamed for a failure. The easiest thing to see is what others did wrong that lead to failure. However, in every failure I have been involved in I was a part of the team and there is something I could have done better that may have helped prevent the failure. Maybe I made some of the bad decisions. Maybe I just had a bad attitude that affected others. The same is true for everyone and I want to know if they reallize it and admit it.

What did they learn from past successes?

Of course I do not want someone who has seen only failures or very poor projects. We learn from success as well. What decisions were made along the way that lead to successes? When problems occur how did the team solve them. Every success has plenty of oppurtunities for failure along the way and the team avoided them or were able to recover from them. How did they do it? What was the attitude of the team and how did they keep positive? Who lead the way? There is always a leader is successful projects that encourages the team in tough times. Sometimes it is the official leader but many times it is not. What did they do? What was there attitude?

What are the reading or studying?

We also learn through other means, reading, user groups, discussion groups, and the many communities available on the internet. I have been following a discussion on the agile developer skills group and I think the original goal was to come up with a set of material that could be used as training and mabye certification in agile. It may have some value towards those goals, maybe, but the value in following and participating a little in the discussion is incredible. Every time I have replied I may get a few I agrees but someone always challenges part of what I say. This makes me rethink my position and either clarify it or adjust it. Both of which have caused me to learn. No one that takes a class in the subjects will come away with the learning that the people involved in the debate are getting.

What are they doing to learn?

Learning in discussion is only partial though, you must apply this and put this knowledge to the test. So I want to know what they are doing not just what they are reading or saying. Doing shows us what we have learned and what we did not understand. It also shows us when our assumptions were wrong. I might think something is true but until I have seen it succeed there is a good change I am wrong. In programming we can try it and make a mistake and usually the worse thing that can happen is I lock the computer and have to reboot. :) This trying goes back to the failing section above. We learn, we try, we fail and we adjusts and start again. In this process I get experience.

Another area of learning comes when I get away from the computer and do something else. I want someone who has a life away from the computer. I spend a lot of the time on the computer but I also like to play different sports, play the guitar and listen to music. When I walk away from the computer I come back with a better perspective. I come back with fresh ideas and I am much more productive that when I spend 60+ hours in front of a computer. I am looking for a balanced team member and getting away from the computer is part of that balance.

Conclusion:

I am sure I have left some things out in these short blogs on hiring. And sometimes I do the things that I said earlier were less important like asking what APIs they know or about some strange behaviour in an API that is rarely used. But frankly this is being lazy and it will not accomplish the job of finding a good team member.

One other warning about what I have said. Doing this will make it difficult to hire someone. If you have put yourself in a position to need people fast this will not work. However, if you put yourself in that position someone will have an oppurtunity to learn a lot from the failure you are about to start. Almost every company talks about people being the most important part of there business but for most it is just a slogan. If you really believe people are important, and they are, then hire like it is important. Hire people that will improve your team and continue to improve themselves.

2 comments: