I know, I know... This blog is about Ruby and Ruby on Rails, right?
Yes, but... sometimes when interesting subjects come to my mind I feel the compulsion to write about other things.
This question appeared while I was chatting and having some beers with some buddy programmers, developers, tech leaders and project managers. Of course such a chat cannot stay away from working things for too long and someone raised this question, which floated among us as an uncaptured exception for a while.
Of course any of us had a well-defined set of ideas about this subject, but the discussion went for a while without any conclusion. Our ideas were far too different to be united in a single set of principles!
What you will read here is a subset of my own ideas, more a few things I picked up amomg my friend's ideas. Not an exhaustive set, of course.
1) Find enthusiastic people. Great programmers are generally people capable of celebrating with shouts and dances when a particularly difficult piece of software works as expected. This rules has exceptions, of course, and I met two or three icemen during my 31-years-old career, great programmers capable of facing success in a hard software task without even a smile. But the rule still applies. Enthusiastic people are always seeking success. And success for them is success for your project, if you are smart enough to engage them sincerely in what they are doing.
2) Find those "ethernal students". It is not important if he or she knows the language or the framework your project will be using. I've been into this time enough to tell you that learning new languages is an easy taks if you already know one of them and has the mind of an "ethernal student". And I don't mean those who just learn new things when necessary, but those who love doing so. Those who ask for tasks leading to new knowledges. Those are the guys and girls I'm talking about. You know them. If you are a great programmer yourself, then you are probably one of them. If you reached a top tech position, you surely are one of them.
3) Find people capable of disagreeing in a healthy manner. This is difficult, but you must try hard, because it is quite necessary. Working as a team is not easy. Differences will appear soon. People will disagree in many things, specially in a longer project. It is vital for the team that all members are capable of listening to opposite ideas without getting and axe and start cutting people like maniacs. A great way to detect rational and soft disagreeing people is disagreeing with them right in the interview and watch their reactions. If the person picks an axe, run and don't hire. If you scape, of course! Some say finding people like this is almost impossible, due to rule #1 above. In fact, there is just a thin line between "enthusiastic" and "maniac". You'll discover this easily if you say "I prefer emacs" to a VI user, or "Windows is a great platform" to a Linux addict. So, good luck and remember no to let axes close to your cadidates.
4) Find at least one person thinking differently from the rest of the team. This is one of the reasons why rule #3 is necessary. If, for instance, most of your team already told you they love DDD and Anaemic Domain Model, hire a guy/girl which is a critic of these patterns (or anti-patterns, as you like). It's always good to have someone thinking differently of the rest of the group. He or she will help you to detect failures in the general thinking. It will be a great inner censorship, you may be sure.
5) Don't give much attention to academic degrees, but to what people already did. Most of the great programmers I've met during the last 31 years were school or college dropouts. And some of the weakest had PhDs. This is not a rule, of course. You'll surely find PhDs which are also great programmers. And school or college dropouts which are nothing more than unadjusted personalities or complete failures. But this is not the point. The point is that academic degrees are not decisive factors to be a great programmer. So, don't push this point too much when you are selecting people, ou you'll risk losing great people by doing so.
6) Be sure they really did what they say they did. A personal experience led me to this rule. I was selecting a team to a very complex project and one guy appeared with a long list of projects in which he, supposedly, had taken a key role. I hired him and in two weeks I noticed he had done nothing good in his whole live. In fact, he barely knew how to write C code, which was a "must have" in this project. The only thing he knew, in fact, was personal marketing. We all met people like him. In school he must have been that guy who does nothing in group tasks but is smart enough to show the results in front of an audience and gets most of the credits for this, while other people worked hard. And he was very persuasive and with a great programming vocabulary! From this occasion on I decided I would only hire people whose work I already knew or capable of doing somenthing right-here-and-now for me to see.
7) Find a great leader. A great leader is not necessarily a great programmer, but someone capable of motivating people. And this requires from us some self-criticism. If you find out your are not a great leader, give this task to someone else and just manage things at a distance. Right there on the field of action, when bits ans bytes are flowing from programmers fingertips, you need someone capable of raising the morals of the group and keep people working hard even when they are exhausted. A person capable of doing those speeches before the battle, speeches strong enough to send people to certain death with a smile in their faces. Find someone like this and your project is half-way to success.
8) Keep this leader away from programming! As I said before, this person needs not to be a great programmer. His task is not this and to mantain the respect of the team for him/her you should keep this person away from programming. If you name someone a tech leader, this person must be great in both things. A rare type, I must say.
9) Give them freedom enough, but not too much freedom. If you create too many rules at work, good programmers will spend a lot of their time trying to break them. You say Facebook is forbidden and they will take time to find a proxy server to use Facebook anyway, even if they don't like Facebook. This is not the point. Breaking the rules is the point. So, if you give your team freedom enough they won't spend much time to search for it. Believe me, programmers do not accept restrictions easily and the sooner you learn this the better. But... never leave them completely at their will. Be close and oversee their results. Because programmers tend to do useless things if they are not monitored. They will use some of the time you paid them to finish the website someone hired them to do on the weekends. They will use some time to work on a free software project they are engaged. They will write articles to their tech blogs. How much you must allow of these things is your business, not mine. But if you do not keep an eye on things, they will soon get out of control and your project will suffer as a whole.
10) Use the Force! Try to use your feelings, young padawan! Do not conform to any set of rules, including this one here. Feel your environment, try people around you, know the people working with you. Most of the problems you will face may be solved by some talk and some actions. And if you do not gather a ready-made great programming team, you may certainly try to turn the team you have now into one. It will take time. It will take effort. But it will pay if you succeed.