Re^3: Where are future senior programmers coming from?

To make it work, you need developers who are true team players and recognize the future value of a good programmer. If your developers hate being bothered and think passing on knowledge to the younger generation, or think of it as pain, then you're pretty much already in a bad situation.

I've found that in these situations, the developers are always under the gun and suffering from a lack of time. I've also often found that they suffer from a dysfunctinal development process and several other self-defeating set-ups which suck up all of their time.

The time to teach other people anything isn't losing productivity since it should make both sides better. If you're just counting lines of code or time at the keyboard, you probably don't realize how much you're actually losing by creating information silos. If you can't come up with a way to effectively integrate a new person into your group, you'll be hurting when you lose key people (like I once did when he drove his sports car into a tree).

Every situation is different, so it's difficult to perscribe anything that works everywhere. Good developer docs (which means, not just the APIs, but how to use them), good task tracking, can help. Start new people off with small tasks, maybe related to wish list items or tool smithing, and gradually bring them up to speed on the whole project. Let them sit in meetings, etc. If you want a good programmer, you probably also want to keep them for a long time. A transition time of even several months sure pays off more than several short term bad programmers over the same time period. I've seen both situations.

The communication problem really isn't that bad. Give every new hire a sponsor: someone who you trust to be a good programmer (not necessarily the best), who can take the newbie under his wing for a while. Of course, this sponsor also has to have some skills at managing that, which a lot of programmers lack. Programmers, as employees, need to be more than just code slingers. A "senior programmer" who just slings code isn't really worth the title.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Comment on Re^3: Where are future senior programmers coming from?

Replies are listed 'Best First'.
Re^4: Where are future senior programmers coming from? by tilly (Archbishop) on Sep 07, 2006 at 04:19 UTC
While I know the kind of environment that you're talking about, very little of what you say is rings true for where I work, and I suspect that most of it doesn't at many other good Perl shops. We have none of the drawbacks that you mention. While we keep busy, the pace is relaxed. Our development process is working well. We document pretty well. (Several DBAs have mentioned to me that they have never seen a team of developers that documents so much!) Turnover is fairly low - in the last 5 years we have lost 3 programmers. (All three have worked in a series of startups, and moved on to yet another one. But to be fair, I expect turnover to increase in the future.) We certainly try to avoid creating "information silos". None of our programmers are just code monkeys. The will is not a problem. The problem is that we recognize, individually and collectively, that adding a junior person would result in fewer projects out the door. And we don't really have that many projects that would be appropriate for a junior person. So when we add a person, we always choose to make it a very senior person. We couldn't even give a junior person stupid HTML projects since we already have an HTML designer. (A very, very good one in fact - and he's learning Perl.) As for the communication problem, I am not talking about not wanting to take the time for a junior person. Instead I am talking about the one that Brook names in The Mythical Man-Month. Which is that with n people there are n*(n-1)/2 possible lines of communication, which means at some point with a flat organization, adding a person can cost more time from other people than that person can contribute. (This isn't just true of human organizations, for instance it is why SMP doesn't scale to large numbers of CPUs.) We are seeing this issue even though our team is small. Our solution has been to split off some people into specialized roles to cut down lines of communication. For instance that is why I mostly do reporting now. But still we are reluctant to add people unless they really carry their weight. And hence we always choose to hire people who are already good programmers. As a business choice, that is reasonable. I'm just concerned about how good it is long-term if every company does this.	[reply]

Replies are listed 'Best First'.

Re^4: Where are future senior programmers coming from?
by tilly (Archbishop) on Sep 07, 2006 at 04:19 UTC

We have none of the drawbacks that you mention. While we keep busy, the pace is relaxed. Our development process is working well. We document pretty well. (Several DBAs have mentioned to me that they have never seen a team of developers that documents so much!) Turnover is fairly low - in the last 5 years we have lost 3 programmers. (All three have worked in a series of startups, and moved on to yet another one. But to be fair, I expect turnover to increase in the future.) We certainly try to avoid creating "information silos". None of our programmers are just code monkeys. The will is not a problem.

The problem is that we recognize, individually and collectively, that adding a junior person would result in fewer projects out the door. And we don't really have that many projects that would be appropriate for a junior person. So when we add a person, we always choose to make it a very senior person.

We couldn't even give a junior person stupid HTML projects since we already have an HTML designer. (A very, very good one in fact - and he's learning Perl.)

As for the communication problem, I am not talking about not wanting to take the time for a junior person. Instead I am talking about the one that Brook names in The Mythical Man-Month. Which is that with n people there are n*(n-1)/2 possible lines of communication, which means at some point with a flat organization, adding a person can cost more time from other people than that person can contribute. (This isn't just true of human organizations, for instance it is why SMP doesn't scale to large numbers of CPUs.)

We are seeing this issue even though our team is small. Our solution has been to split off some people into specialized roles to cut down lines of communication. For instance that is why I mostly do reporting now. But still we are reluctant to add people unless they really carry their weight. And hence we always choose to hire people who are already good programmers. As a business choice, that is reasonable. I'm just concerned about how good it is long-term if every company does this.

[reply]