[jfoutz]

> Could you explain how you get around the knowledge silo problem?

IMHO, you can't. Imagine either extreme. In one case, everything is so well documented and test, and every developer has all of the necessary domain knowledge for every problem. In the other case, everyone is hyper specialized, and hasn't the foggiest idea what's happening on the other side of the interface they're calling.

The reality is, some people like small, diverse problems, and want to make small-ish changes over a big codebase. Some people like big, deep, gnarly problems. Furthermore most people vary from week in their productivity and quality.

It's a puzzle. each person is a tile, and you have to cover the whole problem with tiles. As people produce solutions, you have to consider, how much of the codebase could be handled by your most jr developer. Does the code need to be so simple anyone can work on it? Generally, yes, but not universally. There can be some scary parts of the code where, perhaps only half the team can be trusted to mess with it. The thing that sucks, is when you have a scary corner of the code that only one person can handle.

Both extremes suck. Be judicious about how much scary code you're willing to tolerate. All i can really offer is hand wavy advice. I don't have a formula, and i kind of think a formula can't exist, because there are so many constantly changing factors. Time pressure, turnover, inconsistency, changing needs, there's just a ton.

Trying to match people with stuff they like to work on, and not being afraid to pull people back when they start getting a little too clever seems like the best heuristic.

[wiz21c]

I like this answer. I'd say it differently : provided you work on some non-genius-level code like your average (no disrespect!) website, the problem will be more human than technical. Figuring who's good at what is quite connected to who likes to do what and how they want to do it (small fixes, small projects, long projects,...). Some people are super good at coding batches but will just stop working if they have to interact with a non-cooperative person (say, a customer). Other will do marvel at understanding one's need but will make very approximate code. Some will like to review someone else's code but will hate to be reviewed. Some will need constant attention or else they'll drift to facebook, youtube, whatever.

Managing people is so much more about soft skills than technical ones. I've managed people who learned to code alone, people who learned at college, or university level, up to phD. Each of them is different.

The only thing I don't know how to do is : how to motivate people who work-for-eat, who are not passionnated about their job. I have no idea and it drains a lot of my energy :-(

[thetmkay]

Thanks for the response, I appreciate the pragmatism in your advice. As with everything it seems to be a question of balance and circumstance.