Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > [OT] dealing with lower level programmers

Reply
Thread Tools

[OT] dealing with lower level programmers

 
 
Noah Roberts
Guest
Posts: n/a
 
      07-09-2009
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.
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      07-09-2009
* 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.
 
Reply With Quote
 
 
 
 
Paul N
Guest
Posts: n/a
 
      07-09-2009
On 9 July, 20:54, "Alf P. Steinbach" <(E-Mail Removed)> 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.
 
Reply With Quote
 
Andrew Tomazos
Guest
Posts: n/a
 
      07-09-2009
On Jul 9, 8:38*pm, Noah Roberts <(E-Mail Removed)> 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.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      07-09-2009
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
>
> 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.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      07-09-2009
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.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      07-09-2009
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.
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      07-10-2009
Noah Roberts <(E-Mail Removed)> 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...bout-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__
 
Reply With Quote
 
mzdude
Guest
Posts: n/a
 
      07-10-2009
On Jul 9, 7:18*pm, Noah Roberts <(E-Mail Removed)> 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.
 
Reply With Quote
 
Andrew Tomazos
Guest
Posts: n/a
 
      07-11-2009
On Jul 10, 2:13*pm, mzdude <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is the average IQ of C programmers less than that of C++ programmers? MikeP C Programming 40 04-07-2011 10:19 PM
Re: Is the average IQ of C programmers less than that of C++ programmers? bert C Programming 1 04-06-2011 09:46 PM
Maybe C is the perfect language for really good systems programmers, but unfortunately not-so-good systems and applications programmers are using it and they shouldn’t be. Casey Hawthorne C Programming 18 11-06-2009 05:05 AM
C programmers have a phobia of Java/C++ programmers broli C Programming 3 04-03-2008 12:08 PM
c is a low-level language or neither low level nor high level language pabbu C Programming 8 11-07-2005 03:05 PM



Advertisments