[OT] dealing with lower level programmers

Discussion in 'C++' started by Noah Roberts, Jul 9, 2009.

  1. Noah Roberts

    Noah Roberts Guest

    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.
    Noah Roberts, Jul 9, 2009
    #1
    1. Advertising

  2. * 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. :)
    Alf P. Steinbach, Jul 9, 2009
    #2
    1. Advertising

  3. Noah Roberts

    Paul N Guest

    Re: dealing with lower level programmers

    On 9 July, 20:54, "Alf P. Steinbach" <> wrote:
    > * Noah Roberts:
    > > The problem is that I'm having an incredibly hard time communicating
    > > what I need to communicate to the developers on my team.


    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.
    Paul N, Jul 9, 2009
    #3
  4. Re: dealing with lower level programmers

    On Jul 9, 8:38 pm, Noah Roberts <> wrote:
    > 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.
    Andrew Tomazos, Jul 9, 2009
    #4
  5. Noah Roberts

    Noah Roberts Guest

    Stuart Golodetz wrote:

    > 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 :p
    >
    > 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, Jul 10, 2009
    #5
  6. Noah Roberts

    Noah Roberts Guest

    Re: dealing with lower level programmers

    Andrew Tomazos wrote:
    > 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, Jul 10, 2009
    #6
  7. Noah Roberts

    Noah Roberts Guest

    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.
    Noah Roberts, Jul 10, 2009
    #7
  8. Noah Roberts <> writes:

    > [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).


    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Jul 10, 2009
    #8
  9. Noah Roberts

    mzdude Guest

    Re: dealing with lower level programmers

    On Jul 9, 7:18 pm, Noah Roberts <> wrote:
    > 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.
    mzdude, Jul 10, 2009
    #9
  10. Re: dealing with lower level programmers

    On Jul 10, 2:13 pm, mzdude <> wrote:
    > 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:

    http://www.youtube.com/watch?v=Pk7yqlTMvp8

    It's fracking hilarious.
    -Andrew.
    Andrew Tomazos, Jul 11, 2009
    #10
  11. > 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
    Ferdinand Mitterbauer, Jul 12, 2009
    #11
  12. Noah Roberts

    Ian Collins Guest

    Noah Roberts wrote:
    > Stuart Golodetz wrote:
    >
    >> 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.


    Try pairing with them for a while.

    --
    Ian Collins
    Ian Collins, Jul 12, 2009
    #12
  13. Re: dealing with lower level programmers

    On 9 Jul., 20:38, Noah Roberts <> wrote:
    > 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
    Stuart Redmann, Jul 14, 2009
    #13
  14. Noah Roberts

    Noah Roberts Guest

    Re: dealing with lower level programmers

    Stuart Redmann wrote:
    > On 9 Jul., 20:38, Noah Roberts <> wrote:
    >> 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?


    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.
    Noah Roberts, Jul 14, 2009
    #14
  15. Noah Roberts

    James Kanze Guest

    Re: dealing with lower level programmers

    On Jul 14, 5:35 pm, Noah Roberts <> wrote:
    > Stuart Redmann wrote:
    > > On 9 Jul., 20:38, Noah Roberts <> wrote:


    > 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 14, 2009
    #15
  16. Re: dealing with lower level programmers

    On Jul 9, 1:38 pm, Noah Roberts <> wrote:
    > 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.
    Zachary Turner, Jul 14, 2009
    #16
  17. Re: dealing with lower level programmers

    Noah Roberts <> writes:

    > 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...


    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Jul 15, 2009
    #17
  18. Re: dealing with lower level programmers

    Pascal J. Bourguignon wrote:
    > Noah Roberts <> writes:
    >
    >> 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


    This also depends on how lucky you are, and how "highly qualified
    programmers" are really qualified, no?
    Vladimir Jovic, Jul 15, 2009
    #18
  19. Re: dealing with lower level programmers

    Vladimir Jovic <> writes:

    > Pascal J. Bourguignon wrote:
    >> Noah Roberts <> writes:
    >>
    >>> 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

    >
    > 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.

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Jul 15, 2009
    #19
  20. Re: dealing with lower level programmers

    On Jul 15, 11:04 am, (Pascal J. Bourguignon)
    wrote:
    > 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.
    Andrew Tomazos, Jul 15, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Maciej Pilichowski
    Replies:
    3
    Views:
    3,553
    Duane Hebert
    Jan 9, 2005
  2. pabbu
    Replies:
    8
    Views:
    707
    Marc Boyer
    Nov 7, 2005
  3. broli
    Replies:
    3
    Views:
    426
    Kenny McCormack
    Apr 3, 2008
  4. Gunter Schelfhout

    Designing lower level classes.

    Gunter Schelfhout, Jun 29, 2008, in forum: C++
    Replies:
    13
    Views:
    538
    James Kanze
    Jun 30, 2008
  5. MikeP
    Replies:
    40
    Views:
    1,674
    BartC
    Apr 7, 2011
Loading...

Share This Page