My development group at work, for the last couple of years, has been composed of three senior level programmers—two highly experienced (including myself) and one hard-working, but not as experienced. This week, the other highly experienced developer left our group for supposedly greener pastures.
A couple of things resulted from this change. First and foremost, we have a lot of slack to take up, so the rest of the year will be very busy for us. Second, I am now the de facto lead developer in the group. A group for which we need to hire two more developers (we had an open position before the loss of our comrade).
Two fresh, new, dreamy eyed developers. For me to lead, to teach, to mold. I like to think of these potential developers as my minions, willing to do my bidding.
For a while, we filled our open developer position with a temporary employee. We tasked this person with the creation of a process work flow for our development efforts. Something we could use to identify tasks, categorize them, prioritize them, assign them, and sometimes even work on them. The final result of this effort looks something like this:
No, no, no. This will never do. I can’t use this. Look at how many boxes there are. Not only that, look the sheer complexity introduced by all those decision branches! I could never trust my minions with so much independent thought. Also, I have no desire to confuse my minions any more than they already are. So I designed a new process flow, which I believe is far simpler and easier to remember.
Yes, this is more like it. I suspect even the simplest of minions can effectively follow this process. And if they can’t, well, we have ways of dealing with them.
So I need minions. There are a few requirements, however.
- Familiarity with Perl (other programming languages are acceptable—except Python)
- Experience administering Linux (or another Unix-like system, I guess)
- Fascination for grid computing
- Misplaced enthusiasm for supporting users
- Blind devotion to me
Not necessarily in that order.