Many of our developers have had to move to a more advisory role. Their duties now include writing specifications, both functional and technical, which are very detailed. The detail needed to "coach" the development of the required code is not much less than the effort actually required to do the coding work itself.

I have run a company myself, started with two (myself and my partner) and 5 years later grown to over 40 people. I learned management and especially projectmanagement the hard way: by doing it, and trying to read something about it at the same time, and having the problem of recognizing good texts from hype and air.

Management is an issue here. The development of Perl is managed by a small group of people. Most of whom should just be developing, programming, testing. Instead of going to conferences or managing programmers that have way less experience and skills than they have.

Project management is another issue. Again, many project managers lose a lot of time on management issues, that they could have spent better just programming themselves.

Many projects and good products have gone down the drain because of the multi monkey approach. That is: put more monkeys on a project and the project will be finished sooner with a better result. But that approach seldom works. The opposite is more true. The best programmer in a team is appointed to be project manager, which is not his (her) best virtue. This programmer does not have the time to program, but tries to tell the other programmers how to do their work. Too often I have seen a team of programmers expand, staying at the same productivity rate and the project manager go nuts. While this manager as a programmer could have half of the work himself (herself) would he (she) have been left alone with just a bit of management from a real manager.