[OT] dealing with lower level programmers

[Noah Roberts]

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me. I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team. Let me
illustrate a couple examples:

I've decided upon a project based svn structure so that each individual
project within the source control has the three standard directories:
trunk, tags, branches. To me it seems sufficient to point that out and
say that's what we're doing. I knew this stuff before I ever even
entered college. But I go beyond that and document what these
directories are used for, why they are there, and watch to make sure the
other developers can create their own project structure from scratch.

Well, this guy under me that I figure seems to understand things pretty
well...I let him sort of go for a while without really watching
everything he does trusting that since I've described what to do, why,
and seen him do it at least once...that he can do it again--and I need
to get some stuff of my own accomplished! Today I'm messing around in
those areas and here's a project he created without trunk, tags,
branches in the source control. I can fix that pretty easily but it's
really got me questioning how I can possibly inform my team what I need
and trust that they can do it in the future.

Another example: I tell this one guy who's been a developer for like 20
years or something to work on setting up a property editor. I tell him
that I want a type-map based factory that I can request the appropriate
field editing widget from based on a string meant to represent what I
want to edit. He goes off "researching" some boost::fusion based crap
for two weeks and when I go to check on how he's progressed on something
that would take me an hour...he's nowhere. Now, I do encourage some
researching into ideas so that I can get input that I wouldn't have
otherwise but I explained repeatedly to this guy that we're in a hurry
and this just needed to get slapped out.

Yet another example: I set up a MVC pattern with the Controller being a
state machine based on what tool is currently activated by the user that
sends commands to a document for processing. MVC, State, Command,
right? These things are central to ANY UI based product (if not exactly
these patterns then ones derived from them) Dude wrote a state
controller for a tool that sent a command (without any checking to see
if it should even be done) that was filled with a call to the
document...where he implemented ALL the logic. Three days later I'm
still struggling to teach him how this stuff works and why doing it the
way he did is going to cause us trouble.

He keeps coming back with completely messed up code asking if it's
correct. Inside I'm screaming as I gently say no and try to explain how
and why.

People here must run into this problem. What do you guys do? How can I
make sure the project is done reasonably well without micromanaging,
which is just a waste of my time, or saying to hell with it and doing it
all myself? How do you mentor a whole team of people and still get
something written?

I'm just frustrated as hell with the situation and sort of dispairing
that I'll ever be able to adequately communicate what I see as basic
stuff to people who don't seem to be getting it. These guys seem
intelligent enough...what am I doing wrong? This project is two months
overdue on milestone 1...with a whole festival of features left to add
before we're done. I'm getting really worried that I simply can't get
it accomplished.

 

[Alf P. Steinbach]

* Noah Roberts:

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me. I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team. Let me
illustrate a couple examples:

I've decided upon a project based svn structure so that each individual
project within the source control has the three standard directories:
trunk, tags, branches. To me it seems sufficient to point that out and
say that's what we're doing. I knew this stuff before I ever even
entered college. But I go beyond that and document what these
directories are used for, why they are there, and watch to make sure the
other developers can create their own project structure from scratch.

Well, this guy under me that I figure seems to understand things pretty
well...I let him sort of go for a while without really watching
everything he does trusting that since I've described what to do, why,
and seen him do it at least once...that he can do it again--and I need
to get some stuff of my own accomplished! Today I'm messing around in
those areas and here's a project he created without trunk, tags,
branches in the source control. I can fix that pretty easily but it's
really got me questioning how I can possibly inform my team what I need
and trust that they can do it in the future.

Another example: I tell this one guy who's been a developer for like 20
years or something to work on setting up a property editor. I tell him
that I want a type-map based factory that I can request the appropriate
field editing widget from based on a string meant to represent what I
want to edit. He goes off "researching" some boost::fusion based crap
for two weeks and when I go to check on how he's progressed on something
that would take me an hour...he's nowhere. Now, I do encourage some
researching into ideas so that I can get input that I wouldn't have
otherwise but I explained repeatedly to this guy that we're in a hurry
and this just needed to get slapped out.

Yet another example: I set up a MVC pattern with the Controller being a
state machine based on what tool is currently activated by the user that
sends commands to a document for processing. MVC, State, Command,
right? These things are central to ANY UI based product (if not exactly
these patterns then ones derived from them) Dude wrote a state
controller for a tool that sent a command (without any checking to see
if it should even be done) that was filled with a call to the
document...where he implemented ALL the logic. Three days later I'm
still struggling to teach him how this stuff works and why doing it the
way he did is going to cause us trouble.

He keeps coming back with completely messed up code asking if it's
correct. Inside I'm screaming as I gently say no and try to explain how
and why.

People here must run into this problem. What do you guys do? How can I
make sure the project is done reasonably well without micromanaging,
which is just a waste of my time, or saying to hell with it and doing it
all myself? How do you mentor a whole team of people and still get
something written?

I'm just frustrated as hell with the situation and sort of dispairing
that I'll ever be able to adequately communicate what I see as basic
stuff to people who don't seem to be getting it. These guys seem
intelligent enough...what am I doing wrong? This project is two months
overdue on milestone 1...with a whole festival of features left to add
before we're done. I'm getting really worried that I simply can't get
it accomplished.

Hm, I've guided and mentored people and had charge of hundreds of students, and
of student lab staff, but in developing work I've always either been in a
small team or directly under a technical manager (helping others as needed but
except for a few single persons not directly supervising them). So I can't give
you advice from your point of view. However, I've been at the other end.

Some of what you describe may be due to incompetence, unclear or lacking
communication and/or resentment of your leadership (like, I'd rather be the
lead, and I'll make sure you're doing badly). It does sound like some
incompetence + communication, i.e. faults at both ends. Although with good
people they'll just ask if it's unclear, and keep you informed.

Regarding resention, at all places I've worked there have been people with a
negative-sum way of thinking, that what's bad for others must be good for me. At
two places of work, one a vocational school in Bodø, and the other Accenture
(then Andersen Consulting), there were even people stealing odds and ends from
around everywhere. At AC when my stuff started to disappear I was a bit afraid
I'd started to forget, or my mind was going. Happily, or sadly, later on,
working in another firm, it was not far away, the AC people I met told me that
thing was still going on. Ah, not me! I think, based on my personal experience,
that in any large workplace there are Bad People. Also, latest news in Norway
today was about a fire station in Kristansand, I think it was. Resentment of the
new management was so acute that one worker who came back after sick call found
his boots filled with gypsum (I think that's it in English), and others
experienced various other sabotage. He was on "wrong side" of the conflict.

But as I wrote, I don't think the problem you describe is resention or active
sabotage, rather, some incompetence, and some unclear communication, and too
little communication, and then Murphy's law sort of exponentiates the whole
thing. ;-)

A bad manager (from my point of view as underling) sees that as a control
problem; how to better control these screw-it-ups.

A good manager (still from my point of view) *communicates*, and *listens*, and
the best ones also *inspire*. And communication is two-way. So do not despair:
talk with your people (and also your boss), explain the dire straits of the
project, ask for suggestions, take them seriously, make them feel responsible
for the project and individual tasks, and praise them when they do something
good (but not otherwise, no false praise). But perhaps not ask them directly
about your leadership style (just change it if this isn't what you already do),
because, and I'll probably draw a lot of heat for saying this, as I view it most
people react primarily or instinctively to surface appearance, and an appearance
of weakness invites all sorts of counter-productive behavior.

That's as far as the general goes.

Regarding the dude who's asking about correctness all the time, it may be that
he's received (what he has perceived as) contradictionary signals. Perhaps not
from you, perhaps from others, it doesn't matter. But when the good/bad signals
aren't perceived as consistent then just about anybody, including dogs , will
ask for correctness all the time, trying to deduce what-the-heck is this "hidden
factor" that I've not grokked, or simply because they've got the impression that
that's what you want them to do. At the end he may give up on understanding and
just do it his way. So again, if I'm right, it's about communication.

In short, if you don't do it already, communicate, that's my advice -- from
down below. ;-)


Cheers & hth.,

- Alf

PS: Communication can be overdone. E.g. your staff may be reading this, and
you're writing under your own name. The point is that if so, then they'll know
that your boss and others in the firm will be reading this, about them, and able
to identify them, and they may resent that, and anyway if you are in a larger
firm it was very thoughtless of you, albeit understandable. So while it is a
good idea to ask for help, I think you've done it, perhaps exasperated and
desperate, in a possibly sort of counter-productive way. The Norwegian solution
to this kind of problem is what we call "lay down flat", to admit to the blunder
and apologize and outline how you're going to deal with things.

 

[Paul N]

* Noah Roberts:

I'm not exactly an expert at this, but it might help if you tell them
what you want their code to achieve - not necessarily how it should
achieve it - and make sure they are clear about that. Then ask them if
they know how to achieve this. If they say yes, then leave them to it
for a bit, if they say know, then they have at least agreed to listen
to you.

Then, after they have supposedly written their code, test it against
what it is supposed to achieve. Get them to demonstrate to you that it
does do it. If it does, then hopefully all is well and good; if not,
ask them to justify why it doesn't. Hopefully this will make them
realise what it is they need to hear from you. They'll be more
receptive of what you say if they first realise that they need to
listen to it.

(snip)

A bad manager (from my point of view as underling) sees that as a control
problem; how to better control these screw-it-ups.

A good manager (still from my point of view) *communicates*, and *listens*, and
the best ones also *inspire*. And communication is two-way. So do not despair:
talk with your people (and also your boss), explain the dire straits of the
project, ask for suggestions, take them seriously, make them feel responsible
for the project and individual tasks, and praise them when they do something
good (but not otherwise, no false praise).
Indeed.

But perhaps not ask them directly
about your leadership style (just change it if this isn't what you already do),
because, and I'll probably draw a lot of heat for saying this, as I view it most
people react primarily or instinctively to surface appearance, and an appearance
of weakness invites all sorts of counter-productive behavior.

I think there's more to it than that; I think your conclusion is right
even where your premise is wrong There may well be people who will
take advantage if they see you as weak. But also, until you know
people well, a manager has to create a bit of an illusion, be clear
about certain things and shield their subordinates from certain harsh
realities. Your staff will probably be happier knowing that you
require X, exactly, than if they think that Y (which is a bit easier)
is *probably* acceptable but might not be.

Just a few off-the-cuff thoughts. Hope it is useful.

 

[Andrew Tomazos]

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me.  I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team.

I have worked at various levels with programming teams of 1 to 200 for
about 15-20 years, including in and around many of the common NASDAQ
software companies. The last large team I worked with was a startup
in Intel Corp's capital portfolio, where PhDs were scattered around
the engineering floor liberally.

My first comment is that I hope your staff don't read comp.lang.c+
+.

My second comment is that it sounds like you have a lot of juniors.
Hiring standards are absolutely key. There are an endless parade of
people that think they know something about programming, just like
there are many people that fancy themselves as writers or painters.
When you try for a software engineering job at Google for example, you
can count on about 9 different interviews, each with a different
engineer - where you will have to work through a total of about 20 or
so software engineering and computer science problems of 30 mins each.

The problem is that a good programmer is not just 20% more productive
than an average one. A good programmer is orders of magnitude more
productive than an average one.

You need to read a book entitled:

The Mythical Man-Month
Frederick P. Brooks
http://bit.ly/gt1t8

Embarrassingly, in the 33 years since it was first published in 1975,
things have not changed all that much in software engineering. I
suspect even though our technology has gotten better - the bottleneck
is still the bottleneck - specifically us, the piddly humans, with our
inherit fallibility.

Finally, if firing them and hiring better programmers is not an
option, than you need to spend money and time on training. If they
don't know how to use subversion, or write a simple inhouse UI tool or
what MVC is - than it sounds like you are going to have to wait over 2
years (if they ever pop) before they are cash flow positive resources.

I wish there was better news. Unfortunately good programmers dont
grow on trees, and it takes a long time to teach.
-Andrew.

 

[Noah Roberts]

You said that one of your developers went off researching stuff for a
couple of weeks, when you were keen to get something knocked off as soon
as possible. I understand the frustration - but many developers are very
prone to wandering off to look at something they find interesting/think
might be useful, and leaving them alone for two weeks does make this
sort of thing likely to happen. If the task's urgent, come back to them
and follow it up - the act of stopping by with a cheery, "How're you
getting on with it?" will make them understand that you're involved with
what they're doing and keen to see results.

Well, that's interesting because I did that a few times. Stopped in and
asked how it was going. A couple of the times I answered questions
about the scope of the project that I thought should have cleared things
up. All along the way I hear, "Going good." Then toward the last day I
don't recall exactly how it became apparent...but it hadn't even been
started. Until then I had been under the impression that he was making
progress, albeit slowly.

On a separate note, what's the physical layout where you are? You say
you "go to check on how he's progressed" - does that mean that you're
not in close proximity office-wise? If there's any way you can get
everyone in the same area, it's probably a good plan. The problem seems
to be partly one of information flow in both directions - and improving
the physical layout can help that.

We're all in the same area but I do tend to focus on writing my own
code. I'm also hashing out features myself and trying to design the
architecture of the project so that it doesn't later fall apart. That's
not exactly easy either

Re. the chap with the MVC code - it sounds like the problem there is one
of lack of training. If that's the case, it's probably not his fault -
you might want to consider sending him on a course / acquiring a good
book for him to read on his own time.

Yeah, I've managed to get a lot of books into the office and I see them
access them from time to time. I think I'm the only one in the office
(including my boss who defers to me on technical issues) who has a home
library and reads it. I've encouraged them to take books home and
nobody does.

I have sent a message to my boss about this and hope to see some
training for these guys. Economy is tanking us a bit though. I'm on
reduced hours.

Part of the latest thing is I took a vacation and gave people a stack of
stuff and tried really hard to provide as much as I could in direction
for the next week while I was gone. I spent two full days preparing. I
came back and it was all ignored. Not a single suggestion I had given
was used, which wouldn't be bad if the thing actually did do what it was
supposed to. Problem is that it only appeared to on first examination.

It's hard sometimes to accept though that there's obviously something
I'm doing wrong to cause some of this. When I have taken the time to
discuss it with them they seem to try and in some respects catch on.
Sometimes enough to disagree and then I get to explain further.

 

[Noah Roberts]

My first comment is that I hope your staff don't read comp.lang.c+
+.

I have suggested it and encouraged it many times.

I don't think I have anything to worry about, unfortunately. I'd be
pleasantly surprised if someone got mad at me for writing the OP.

 

[Noah Roberts]

Thanks for the input guys. I've got lots to think over. Can't really
do anything about the fact that we hire junior programmers; we can't
afford otherwise. To tell the truth it's almost impossible to find
good, dedicated developers of any level. At least the people we have
are willing to learn and may someday be good.

I'll grind over the input you've given me. Thanks.

 

[Pascal J. Bourguignon]

[interesting cases]

People here must run into this problem. What do you guys do? How can
I make sure the project is done reasonably well without micromanaging,
which is just a waste of my time, or saying to hell with it and doing
it all myself? How do you mentor a whole team of people and still get
something written?

I'm just frustrated as hell with the situation and sort of dispairing
that I'll ever be able to adequately communicate what I see as basic
stuff to people who don't seem to be getting it. These guys seem
intelligent enough...what am I doing wrong? This project is two
months overdue on milestone 1...with a whole festival of features left
to add before we're done. I'm getting really worried that I simply
can't get it accomplished.

With the purpose of meeting milestones,


1) you have to accept that not all parts of the code will be done up to
_your_ standards.

2) you should define the interfaces and unit tests checking the
implementation works as you want, then you can let them implement
however they want.

3) make a good decomposition of the project in independant subparts.
If you can develop a part as a standalone working program, this is
something that won't regress, so you can further advance the
project. This is the unix approach: simple tools doing simple
minded operations, combined in bigger systems.

4) Repeatition is the base of pedagogy. Also, repeating with variants
may help: when somebody doesn't understand twice the same
explanation, try other kinds of explanation, until you identify the
kind of explaining he understands. Some understand theories (give
them axioms and deduction rules, and they'll deduce everything by
themselves). Others need examples to infer the rules themselves.
It's often good to have a mix. Some also understand better by
seeing other doing, hence the idea of letting couples of
programmers working together.

5) read The Mythical Man Month.

6) read about mappers and packers.
http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/


The second point can be applied at different levels. If there's no
light bulb about MVC and you're in a hurry, you could define the
classes and their interface, and have him implement them in this
frame.


Points two and three combine to save your life: if something is wrong,
you should be able to rewrite the bad module quickly enough, because
they should be small, and independant from the others (communicating
only thru the interfaces you defined).


The best you can do for your programmers, is to have good
specifications (use cases and validation tests).

 

[mzdude]

Thanks for the input guys.  I've got lots to think over.  Can't really
do anything about the fact that we hire junior programmers; we can't
afford otherwise.  To tell the truth it's almost impossible to find
good, dedicated developers of any level.  At least the people we have
are willing to learn and may someday be good.

I'll grind over the input you've given me.  Thanks.

Biggest problem in our field is that **management** has decided
that **programmers** will make $X. When you are a good programmer
and you want to make $(X + delta) you must then become a **manager**.
It is an evil plot to eliminate all good programmers :^)

I currently manage other software types. We only have 1 rule.
**Everything** you do must be checked by someone else. If you create
the source tree, someone else must use it. If you check in code,
someone
else must review. We have a build manager, but from time to time, on
a whim, I'll assign someone else to do the build. It ensures good
communication and traceability.

This did not come easily, nor is it without friction at some times.
This is where you earn the $(delta). I've had some people quit,
and I've had to let others go who just didn't want to buy into the
team concept. What has emerged is a fast well integrated team that
appreciates what other team members contribute.

I've often heard that managing software people is like trying to
herd cats (I think there's a book by that title). Once you get the
group co-operating, realize not every idea you have is great, and
sometimes the ones working in the trenches really do have a better
way.

As a technical lead / manager, I try to limit the management to
8 hours a week, review 8 hours a week and the rest of the time
trying to produce designs and coding.

 

[Andrew Tomazos]

I've often heard that managing software people is like trying to
herd cats (I think there's a book by that title).

There is an old superbowl commercial where some cowboys actually try
to herd a group of about 2000 cats over some hills:

It's fracking hilarious.
-Andrew.

 

[Ferdinand Mitterbauer]

Well, that's interesting because I did that a few times. Stopped in and

asked how it was going. A couple of the times I answered questions
about the scope of the project that I thought should have cleared things
up. All along the way I hear, "Going good."

Maybe don't ask 'how its going?' - everyone will answer 'good'. Instead
ask 'What are you doing at the moment and where are problems?' (or
something like that).

The first questions allows the simple answer 'good' - the second answer
can't be answered with a single word. So the developer you ask has to
form a complete sentence. That make it easier for you to figure out,
whats going on and if there are some problems.

> He goes off "researching" some boost::fusion based crap for two weeks
> and when I go to check on how he's progressed on something that would
> take me an hour...he's nowhere.

What I would try: Explain what it needed and what the developer is
supposed to do - and then let the developer explain the same thing with
his OWN words and how he is going to implement this. If he has
completely no clue how to do this, you can give him further information
/ instructions and/or tell him where he can get the information he needs
(code sample from other project, a book, web page).

And - very important - check, what the guys are doing early. So if you
know, that it would take you only an hour, check back what the guy is
doing after an hour. I have some friends which are real good coders -
and hate to do this - maybe you too ;-)
But: The earlier you detect problems, the cheaper are the costs to fix
them (cost: time and money).

Best wishes,
Ferdinand

 

[Ian Collins]

Well, that's interesting because I did that a few times. Stopped in and
asked how it was going. A couple of the times I answered questions
about the scope of the project that I thought should have cleared things
up. All along the way I hear, "Going good." Then toward the last day I
don't recall exactly how it became apparent...but it hadn't even been
started. Until then I had been under the impression that he was making
progress, albeit slowly.

Try pairing with them for a while.

 

[Stuart Redmann]

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me.  I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team.

Just a thought: How many people are inside your team? I think that
chances are high that they are too many. In our company we have a lot
of students that make a kind of internship. As a rule of thumb one
student take about 25 percent of your time. So if you have four
students, you won't get anything else done. My wife's company has a
project leader that has 10 programmers under him (since they are
professionals, you can give each member a smaller time-slice that
1/4). This project leader had to hire an assistant for managing this
group.

Personally, I work at a project that has two contributors, one of them
keeps heading off to do "research" like a maniac. Sometimes I feel as
if I should watch him work the whole day just to see some progress. So
I feel a lot of sympathy for you.

Maybe you should quit contributing to your project yourself. See your
staff as the extension of your hands: The idea of how everything
should go is inside your head, but you cannot possibly type fast
enough to get it done. Let the others do the typing, concentrate on
making them type the right things. Whenever they get anything good
done, you should be so enthusiastic about it as if you had done it
yourself, and this feeling should be transfered to them.

Regards,
Stuart

 

[Noah Roberts]

Just a thought: How many people are inside your team?

Well, now there's just the one. There was two but I had one guy moved
to another team; I just could not get him to do what I needed. Don't
know or care who's fault that was, it was just necessary. He's doing
great on the other team so maybe it was mine.

The projects are very different too though. I'm working on one that is
meant to implement many of my ideas for process improvement. The other
project does not have the same focus on design, unit testing, etc.

I think that

chances are high that they are too many. In our company we have a lot
of students that make a kind of internship. As a rule of thumb one
student take about 25 percent of your time. So if you have four
students, you won't get anything else done. My wife's company has a
project leader that has 10 programmers under him (since they are
professionals, you can give each member a smaller time-slice that
1/4). This project leader had to hire an assistant for managing this
group.

Here's another big issue. We're not in an area that holds a lot of
programmers. Almost our entire staff is, or was, interns. I could use
some mentoring myself and there's just none to be had. This group and
the writings of people like Martin, Fowler, Sutter, and Meyers are what
I've got. A while back I mentioned in a company improvement meeting
that, "I'm the best programmer you have, and that's a real problem."

Don't get me wrong, I belong where I am: Sr. Developer. I could just
use someone above me that knows more than I do.

Personally, I work at a project that has two contributors, one of them
keeps heading off to do "research" like a maniac. Sometimes I feel as
if I should watch him work the whole day just to see some progress. So
I feel a lot of sympathy for you.

Maybe you should quit contributing to your project yourself. See your
staff as the extension of your hands: The idea of how everything
should go is inside your head, but you cannot possibly type fast
enough to get it done. Let the others do the typing, concentrate on
making them type the right things. Whenever they get anything good
done, you should be so enthusiastic about it as if you had done it
yourself, and this feeling should be transfered to them.

Yeah, it's the getting them to write the right things I'm having trouble
with. It does appear there are some focus things I can do though that
can improve that I hope.

The other member is gone for a while so maybe I can use this time to
document things better and when he comes back there will be easier ways
to discuss what's needed.

 

[James Kanze]

Here's another big issue. We're not in an area that holds a
lot of programmers. Almost our entire staff is, or was,
interns. I could use some mentoring myself and there's just
none to be had. This group and the writings of people like
Martin, Fowler, Sutter, and Meyers are what I've got. A while
back I mentioned in a company improvement meeting that, "I'm
the best programmer you have, and that's a real problem."

Don't get me wrong, I belong where I am: Sr. Developer. I
could just use someone above me that knows more than I do.

Probably not for the programming, but for the process management
issues.

I've not followed this thread in detail, because any real
answers would take more time than I can give right now. But the
important thing to keep in mind is that you can't do it
yourself. You need help. You need help from the people above
you, to create an atmosphere which encourages open communication
and a striving to improve (which means e.g. that people feel
safe going up to there boss and saying they've made a
mistake---until you've acknowledges a mistake, you can't correct
it). And you need help from those below you, to buy into this
philosopy. In my experience, the problem is usually above you,
not below you: most people I've worked with have been quite
competent, and most would be very happy improving the quality of
their work, IF they felt that it was safe, given the attitudes
of management. But until these people feel safe, not just with
regards to you, but with regards to everyone who might be called
on to judge their work, nothing's going to happen.

Once you've gotten past that hurdle, of course, the next problem
is selling your ideas concerning quality. Most people don't
like being told outright that they have to change the way
they've been doing things. One of the reasons the SEI programs
work so well is that they don't come in, and just say, do it
like this and like this. Rather, they start by proposing
various ways of measuring productivity and quality (which also
have to be sold---not every programmer will accept off-hand that
the measurements are valid). Only then to they start trying to
improve productivity and quality. And you start by asking the
individuals what they think should be done. And trying it, even
if you're convinced the effects will be negative. (That's why
the importance of measuring.) And maybe suggesting a few other
things that they might like to try.

Add to this a notion of personal responsibility---each
programmer is expected to (measurably) improve his code, and
you're just there to offer suggestions and aid in his attempts
to do this, and the results usually end up what is wanted.

 

[Zachary Turner]

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me.  I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team.  Let me
illustrate a couple examples:

I've decided upon a project based svn structure so that each individual
project within the source control has the three standard directories:
trunk, tags, branches.  To me it seems sufficient to point that out and
say that's what we're doing.  I knew this stuff before I ever even
entered college.  But I go beyond that and document what these
directories are used for, why they are there, and watch to make sure the
other developers can create their own project structure from scratch.

Well, this guy under me that I figure seems to understand things pretty
well...I let him sort of go for a while without really watching
everything he does trusting that since I've described what to do, why,
and seen him do it at least once...that he can do it again--and I need
to get some stuff of my own accomplished! Today I'm messing around in
those areas and here's a project he created without trunk, tags,
branches in the source control.  I can fix that pretty easily but it's
really got me questioning how I can possibly inform my team what I need
and trust that they can do it in the future.

Another example: I tell this one guy who's been a developer for like 20
years or something to work on setting up a property editor.  I tell him
that I want a type-map based factory that I can request the appropriate
field editing widget from based on a string meant to represent what I
want to edit.  He goes off "researching" some boost::fusion based crap
for two weeks and when I go to check on how he's progressed on something
that would take me an hour...he's nowhere.  Now, I do encourage some
researching into ideas so that I can get input that I wouldn't have
otherwise but I explained repeatedly to this guy that we're in a hurry
and this just needed to get slapped out.

Yet another example: I set up a MVC pattern with the Controller being a
state machine based on what tool is currently activated by the user that
sends commands to a document for processing.  MVC, State, Command,
right?  These things are central to ANY UI based product (if not exactly
these patterns then ones derived from them)  Dude wrote a state
controller for a tool that sent a command (without any checking to see
if it should even be done) that was filled with a call to the
document...where he implemented ALL the logic.  Three days later I'm
still struggling to teach him how this stuff works and why doing it the
way he did is going to cause us trouble.

He keeps coming back with completely messed up code asking if it's
correct.  Inside I'm screaming as I gently say no and try to explain how
and why.

People here must run into this problem.  What do you guys do?  How can I
make sure the project is done reasonably well without micromanaging,
which is just a waste of my time, or saying to hell with it and doing it
all myself?  How do you mentor a whole team of people and still get
something written?

I'm just frustrated as hell with the situation and sort of dispairing
that I'll ever be able to adequately communicate what I see as basic
stuff to people who don't seem to be getting it.  These guys seem
intelligent enough...what am I doing wrong?  This project is two months
overdue on milestone 1...with a whole festival of features left to add
before we're done.  I'm getting really worried that I simply can't get
it accomplished.

There's a guy at my work who won't even use a debugger. Ever. For
anything. I'm not kidding. It's pretty much the most frustrating
thing ever, and it takes him days to find bugs that I can find in 10
minutes. And even then, memory corruption bugs, double deletes, race
conditions, forget about it. Someone else usually has to find those
types of bugs. Furthermore, if you mention to him that there's a bug
in his code it turns into a 1-hour argument that keeps changing every
5 minutes when it's apparent he doesn't know what he's talking about
with respect to the first point. And the whole time he'll be staring
at his screen instead of looking at you while arguing, and you can
kind of see from around the back of his head that he's smiling because
he knows he's being a complete doofus but just doesn't want to look
bad.

Everybody knows this guy is a problem, but the company is small and
it's just "one of those situations". I like the guy in some respects
but honestly I just want stuff to get accomplished sometimes you know?

Anyway I don't suppose this gives you any advice on how to deal with
your situation, since we certainly haven't figured out a way to deal
with ours (the obvious solution won't happen for management reasons).
But at least you know other people deal with similar frustrations.

 

[Pascal J. Bourguignon]

Here's another big issue. We're not in an area that holds a lot of
programmers.

Hey look, it's your lucky day!

Computer geeks invented something to solve your problem, it's called
"The Internet".

With "The Internet", you can send specifications to highly qualified
programmers located elsewhere, and get back good quality code along
with an invoice. You pay the invoice and you may send back
specification patches, to get program patches. You may have
"meetings" with these highly qualified programmers, thru "The
Internet", using programs such as Skype, so you can see how grumpy or
professionnal they look. If you hire several of them you could even
display a row of Skype windows on your screen, so your manager would
know that you manage a row of programers...

 

[Vladimir Jovic]

Hey look, it's your lucky day!

Computer geeks invented something to solve your problem, it's called
"The Internet".

With "The Internet", you can send specifications to highly qualified
programmers located elsewhere, and get back good quality code along
with an invoice. You pay the invoice and you may send back

This also depends on how lucky you are, and how "highly qualified
programmers" are really qualified, no?

 

[Pascal J. Bourguignon]

This also depends on how lucky you are, and how "highly qualified
programmers" are really qualified, no?

Yes, of course, you have to make your selection, but at least you're
not restricted to the locally available pack.

 

[Andrew Tomazos]

With "The Internet", you can send specifications to highly qualified
programmers located elsewhere, and get back good quality code along
with an invoice.

And you have tried this firsthand? I have. email and instant
messaging are extremely limited forms of communication compared to
working with someone face-to-face sitting at the same machine. The
number of horror stories about getting programming done via
telecommuting totally overshadow the few cases where it has worked.

Further, this dreamworld workflow of (a) writing a spec, (b) sending
it off, (c) waiting, and then (d) getting a complete working software
package on-spec, on-time and on-budget. That's the funniest thing
I've heard in a while. This is no series of events that occurs in the
natural world. It's not a technology problem, it's a human
condition problem.
-Andrew.