Ronn Blankenship wrote:
>
> At 06:02 PM 6/6/02, Julia wrote:
> >Ronn Blankenship wrote:
> >
> > > And, no matter what
> > > you do, don't "promote" your best systems programmer to "management" where
> > > he will be busy twelve hours a day doing that kind of crap and either never
> > > get to write code again or stay late every night trying to write a little
> > > code in addition to all the Bravo Sierra until his health and marriage go
> > > down the toilet. (In case you are wondering, yes, I am thinking of
> > > specific cases I have seen in real companies.)
> >
> >However, encourage some of the better programmers who have leadership
> >skills to take care of the coordination of *projects*. Encourage those
> >who are not ready to take charge of whole projects to do things to
> >improve those skills they'd need for it.
>
> Here is something on which Julia and I may differ.
>
> All along the way I have met programmers, engineers, tech writers, etc.,
> who are very happy being programmers, engineers, tech writers, etc., and
> who absolutely do not want the additional stress and busywork involved in
> managing other programmers, engineers, tech writers, etc., regardless of
> the fact that they have more experience, more talent, and the necessary
> leadership skills. I met some like that in the Air Force, where the "up or
> out" policy states that you have to be promoted to the next higher rank
> within a certain number of years or get out of the service, and the only
> available positions for someone with their experience where they could have
> achieved the next higher rank were positions that involved no longer
> _doing_ the engineering they loved, but _managing_ other engineers who were
> doing the engineering they loved, so they got out. Is it necessary to try
> to force a person who is happy doing exactly what he is doing into a
> position he doesn't want? As I mentioned in my previous message (quoted
> above), at one computer company I worked at for a couple of years, they
> took the top systems programmer, who was talented and happy writing
> assembly-level code, and made him "head programmer" which meant he now
> spent the entire workday being a manager and stayed late into the night
> trying to keep his hand in as a programmer. He would have been far
> happier, and probably far more productive and useful to the company, had he
> remained a programmer and someone else been made manager. Though in
> thinking about it, I think the same thing would have been true of any of
> the other senior programmers they had at the time (including the one who
> could not spell "mnemonic" but wrote the text editor program from scratch),
> so maybe this particular person was forced to take the head of programming
> job because *someone* had to do it. (I know this was the situation in
> other departments in that company, where no one, particularly the members
> of the department with the most seniority, wanted the hassle of being
> "manager" of the department, so it finally fell on someone who said "Oh,
> well. If you insist," but wasn't too happy about it.) This is very much
> the situation described in the Heinlein book, and why the Brooks book
> refers to it. In fact, it was at about this time that I first came across
> "The Mythical Man-Month," which may help explain why it made such an
> impression on me.
>
> That was also about the same time I came up with a modification of an old
> saying that in my experience is far more true than the original: "Those
> who can, do. Those who can't do, become managers."
If you have a programming project that is realistically going to need 3
programmers working on it because you need it in 6 months and it'll take
1 person 12 months to do it (this taking into account that 1 person for
12 months is NOT equal to 2 people for 6 months), get one of the
programmers to "own" the project. Since he's a programmer, he'll have a
better idea as to how the program should be structured, and hopefully
he'll figure out fairly soon how to distribute tasks to the other two
programmers based on their abilities.
The biggest problem with this is when you get someone who's really good
at working out the algorithms and has a good idea as to the other
programmers' strengths and weaknesses, but doesn't have the people
skills necessary to get the others working well. In that case, you
might want the manager to step in and help with that part of the project
administration.
But you let the programmer in charge of the project do as much of the
coding as he feels comfortable with. You don't just put him into the
position of doing nothing but managing the project, but you put him in
charge of making sure it gets done, and provide him with the resources
he needs to get it done.
Any project that requires more than 4 or 5 programmers, you should
probably break into smaller projects so that you can keep the
coordinating programmers from becoming overwhelmed with it. And if you
have the option of letting one programmer handle project X, and once X
is done let another one from the same small group handle Y, do so. It
can be a drag being the one in charge of the project all the time.
Does this sound more reasonable to you, Ronn?
Julia
