For the past two days, I've been trying the Better Gmail extension for Firefox, which packages together a number of Greasemonkey scripts so that you don't have to worry about manually installing all sorts of extensions and scripts.

The only useful part for me (at least so far) is the keyboard macros - which aren't even enabled by default in the extension.  Gmail's keyboard shortcuts were somewhat useful, but having to change over to the mouse limited the potential.  Now, I can do pretty much everything without a mouse.  "gin" to go to the inbox.  "gsp" to go to the spam folder.  "lpy" to label a message as related to Pylons.  "XurXn" to select all unread messages and mark them as read and then to unselect all.  And there seems to be some sort of queueing, since I can get quite a bit ahead of what the Gmail interface is showing me sometimes.

My current employer, CareerJunction, has two Python developer positions open at the moment, to build a second Linux/Python development team to be able to develop more Python stuff faster.  The developers on the first team started with Bryn and I, and now also Shayan (who applied after a previous job post), and Shaun is our "making sure the technology is actually remotely useful to the user" person - designing our pages in terms of what's on them and how they look, being critical of differences to the spec, and generally keeping everyone honest.

http://www.careerjunction.co.za/car/job/jobvuw.asp?adno=576705
http://www.careerjunction.co.za/car/job/jobvuw.asp?adno=576714

There's also a "Project Manager" job for the same team and some other
(mostly ASP) jobs at:

http://www.careerjunction.co.za/internaljobs/

(For non-South Africans or those South Africans not doing much online recruitment activities, CareerJunction is the biggest and best online job board in South Africa.)

Since the beginning of the year, I've been trying to distill some lessons from some of my failures on KnowledgeTree.  Part of this process has been doing a lot of reading about development - to make sure that I'm not seriously out of step with my underlying beliefs, and to see how I can improve on what I've done before.  Most of this reading, strangely enough, about project management.

I've reread the staples on the subject - The Mythical Man Month and Peopleware - with a deeper understanding and finding greater resonance in this reading - I assume due to increased experience.  And I've also read some more recent texts; the latest is Scott Berkun's The Art of Project Management, which Brad recommended.

This isn't a review of the book, but I feel I must say that this book is probably the most succinct instruction book on how to get a team to deliver a project, no matter what technologies they use or what development methodologies or business processes exist.

I like how Berkun starts by defining his use of "project manager" as being "whoever is involved in project leadership and management activity", and offers that some people might want to translate it as "person thinking about the project at large".

To me, it seems the project leader is the person who lives the project - the one who has the clearest idea of what the vision of the project is (and probably the goals), and who keeps this in mind in approaching every decision that is made.  The leader is the person who cares the most about the project, and who seems to make the most cogent arguments about the project as a whole ("Which feature should we drop?", "How do we best fulfil the spec in this case?", and so forth), and to whom these questions tend to become asked of first.

This person doesn't have to be a project manager or the "lead" developer.  It could be a designer, for example, who feels excited by the prospect of delivering something worthwhile to the users of the project.  This person instills this excitement and/or caring, in some small way, to the rest of the team, and provides a degree of reward (it feels nice to make someone happy in addition to just doing your job).

Excitement and attachment, though, have their downside.  If the de facto leader is restricted from providing such leadership (even if it is only a perceived restriction) by the de jure management (for example, a project or line manager), problems start to appear that are hard to diagnose.  Things that "just happened" stop "just happening".  It becomes harder to make decisions or reach concensus about the project.  Things that were decided are forgotten, arguments about previous decisions start up again, and so forth.  Mostly, morale goes down.

My current experiment is trying to understand who holds the de facto leadership power in situations, and to understand my own role in things in terms of non-granted (ie, earned instead of granted) power - both in the past and going forward.  Even if I'm not right about defining the "project leader", this exercise has had some interesting results so far.