[OT] dealing with lower level programmers
Noah Roberts
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
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:
> > 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.
Stuart Golodetz
Disclaimer: Everything I'm saying here can be considered to be expressed
tentatively, since I'm only a graduate student rather than a manager.
So - as with Alf (but with less experience than him), I can't speak from
experience of managing people here, but for what it's worth from a
"being managed" perspective:
It sounds like you may to some extent be leaving your team alone for too
long at a time and giving them a bit too much autonomy. There's a fine
line between delegating to your team and trusting them to do the right
thing, and slightly abdicating your responsibility to lead them by
giving them tasks and then not following them up to make sure they're done.
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. If you leave them alone -
which you see as trusting them to get on with it - they think you've got
better things to do, and won't be committed to the task. It doesn't have
to be a major time sink for you (and it's best not to keep bugging them
the whole time when they need to get on with it), but checking in with
them at the start/end of each day for 5-10 minutes is not unreasonable.
To manage effectively, you need up-to-date information about what
they're up to and how it's going - and the best way to get that is
face-to-face. If necessary, have a short daily catch-up. Bring cake.
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.
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.
Re. the svn chap - you might be better off not making it an issue of
trust (implying that you don't trust somebody is corrosive to a working
relationship). It's very unlikely that he's deliberately messing up the
repository structure to disobey you - much more likely is that he didn't
understand how important you believe it to be, or that he simply
forgot/wasn't paying attention. In the first instance, you're probably
best off emphasising its importance to him (firmly but gently), rather
than directing blame/criticism his way, however tempting. If it happens
again, then you have more reason to get annoyed.
So essentially, I'd say:
* Give a really clear lead (even clearer than you're doing at the moment
- maybe even write it down for them) and check regularly on people you
know have a tendency not to listen/do what you ask them to (and find out
why they don't - occasionally they will have cause)
* Improve communication by regular, *short* catch-up meetings and by
improving the physical layout
* Recognise skill deficiencies (as opposed to incompetence) and send
people on training courses where appropriate - don't necessarily assume
that people with lots of experience know everything you'd expect
* Be firm when necessary, but give people a chance first
Hope that helps a bit!
Best wishes,
Stu
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 :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
> 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
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).
--
__Pascal Bourguignon__
mzdude
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:
http://www.youtube.com/watch?v=Pk7yqlTMvp8
It's fracking hilarious.
-Andrew.
Ferdinand Mitterbauer
> 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
> 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
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
> On 9 Jul., 20:38, Noah Roberts <roberts.n...@gmail.com> 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.
James Kanze
> Stuart Redmann wrote:
> > On 9 Jul., 20:38, Noah Roberts <roberts.n...@gmail.com> 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:james...@gmail.com
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
Zachary Turner
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...
--
__Pascal Bourguignon__
Vladimir Jovic
> Noah Roberts <robert...@gmail.com> 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?
Pascal J. Bourguignon
Yes, of course, you have to make your selection, but at least you're
not restricted to the locally available pack.
--
__Pascal Bourguignon__
Andrew Tomazos
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.
Pascal J. Bourguignon
> On Jul 15, 11:04�am, p...@informatimago.com (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.
I mentionned Skype also, for non-verbal communication.
Otherwise, yes, from the free-lance developer or system admin side of
the equation. Works very well.
> 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.
Well as with any project, delocalizing doesn't remove the project
management needs. You can apply the usually spiral development cycle
to get a better idea of the advancement of the project.
But mostly the point here is that you don't have the choice between:
- a good programmer here, and
- a good programmer there,
but between:
- a bad (because you don't have any choice) programmer here, and
- a good (because you have more to choose amongst) programmer there.
--
__Pascal Bourguignon__
James Kanze
wrote:
> Andrew Tomazos <and...@tomazos.com> writes:
> > On Jul 15, 11:04 am, p...@informatimago.com (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.
> I mentionned Skype also, for non-verbal communication.
> Otherwise, yes, from the free-lance developer or system admin
> side of the equation. Works very well.
Not if you want anything maintainable, or of usable quality.
Communication is essential for program quality. And nothing
beats face to face communication.
What you can do, of course, *if* you can come up with a detailed
and rigorous specification up front (not the case that often),
is subcontract out to a company elsewhere: all the programmers
are still located together, just not where you are.
(That doesn't mean that certain phases of the implementation
can't be done "at home" by the programmer. I find that for the
actual coding, I work best when I'm absolutely isolated. But
the actual coding is not all of a quality product.)
> > 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.
> Well as with any project, delocalizing doesn't remove the
> project management needs. You can apply the usually spiral
> development cycle to get a better idea of the advancement of
> the project.
> But mostly the point here is that you don't have the choice between:
> - a good programmer here, and
> - a good programmer there,
> but between:
> - a bad (because you don't have any choice) programmer here, and
> - a good (because you have more to choose amongst) programmer there.
There are good programmers everywhere. The choice is between a
good programmer here, where you can manage him well, and a good
programmer elsewhere, where you can't manage him, so he can't
perform.
Ian Collins
I don't get that. I've worked for clients on the other side of the world
and we'd both say that they had no trouble managing me (not that they
had to) and that I performed well.
--
Ian Collins
Pascal J. Bourguignon
> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> But mostly the point here is that you don't have the choice between:
^^^^
Here, "here" means at the OP's place.
>> - a good programmer here, and
>> - a good programmer there,
>> but between:
>> - a bad (because you don't have any choice) programmer here, and
>> - a good (because you have more to choose amongst) programmer there.
>
> There are good programmers everywhere. The choice is between a
> good programmer here, where you can manage him well, and a good
> programmer elsewhere, where you can't manage him, so he can't
> perform.
In general. But not at the OP's place, where he just cannot find good
programmers, because there's a scarcity of programmers, good or bad.
--
__Pascal Bourguignon__
mzdude
wrote:
>
> In general. But not at the OP's place, where he just cannot find good
> programmers, because there's a scarcity of programmers, good or bad.
>
There may be several reasons for this. The company doesn't/won't/can't
pay competitive wages.
After HR gets done writing the job description, there is only 1 person
on earth that fills all the requirements, so the only ones that apply
don't match any of the requirements.
Finding good people is tough. A personal reference is usually the best
way. Sometimes a users group focused on specifics is another. Before
the internet, there used to be computer groups, and programming
groups that actually met in person (hard to believe). That was always
an excellent way to maintain a network.
Noah Roberts
good, they just lack experience...especially in design.
Ian Collins
> On Jul 16, 6:30 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> In general. But not at the OP's place, where he just cannot find good
>> programmers, because there's a scarcity of programmers, good or bad.
>>
>
> There may be several reasons for this. The company doesn't/won't/can't
> pay competitive wages.
>
> After HR gets done writing the job description, there is only 1 person
> on earth that fills all the requirements, so the only ones that apply
> don't match any of the requirements.
That's easily fixed: don't let HR write the job description!
--
Ian Collins
Keith H Duggar
> 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.
I sympathize with your position and have experience dealing
with exactly the kind of problems you describe. So I'm going
to offer several concrete practical steps and then see how they
would have impacted the cases you described. (These are a bit
rough and it doesn't covering everything. Also there is some
nuance involved obvious. If you need clarification please
ask.) In return, please let me know months down the line if
and how these practices worked out for you :-)
-- Daily Plan : everyone must maintain a Daily Plan text. This
text gives a short description of each work queue item for the
day (and perhaps next few days). Each morning employees update
their Daily Plan and email it to their manager who will review
the plan and if needed discuss it with the employee. This also
serves as a useful focus to help keep everyone on task. Daily
Plan items should be decomposed into chunks they are completed
in at most 1 day so that progress can be clearly observed.
-- Check Tick : one or more times a day the manager will check
with the employee regarding progress on the Daily Plan. Under
"normal" circumstances (no urgent work items or detailed pair
works) I find an after lunch update works well. This gives you
time to help them with problems, steer them on the right path,
etc and still have some hours left to see if progress is made.
-- Home Work : homework doesn't end with graduation. If there
is material they need to learn then assign reading material.
For example, ask that they read a chapter, item, etc and then
discuss it with them the next day.
-- Clear Specs : it is essential that managers write workable
and clear specifications. Code is one of the clearest forms of
communication so provide them with skeletons of what you want
such as interfaces or algorithms where appropriate. All specs
must be written! It's good to verbally explain and discuss the
specs, but ultimately the verbal communication must denoted in
written form and communicated. Employees should take notes in
technical discussions related to work items. If necessary this
fold all the way down to pair programming.
-- Peer Review : all work must be reviewed. Not only does this
help to catch mistakes it also helps to synchronize styles and
techniques increasing the homogeneity of the code. Furthermore
it ensures that more than one person knows the work. Finally
it increases the review skills of the reviewer which will help
them catch errors in their own code while writing it.
-- Early Review : as part of both Check Tick and Peer Review,
start the review process early and it often. You don't want to
let days of work go by only to find out in a final review that
it is far from what you wanted; so star early. Also the only
clear evidence that progress is being made is the work itself!
So when you Check Tick, take a look directly at the work with
your own eyes.
-- Brick Wall : when an employee does not follow clear written
instructions such as a specification, send the work back for
them to fix. Do not fix it yourself. They must learn there is
no option other than doing what they instructed to do and they
also need to see and understand their mistakes to learn from
them. Even fleas stop trying to jump out of a sealed jar ...
eventually. You are the cold Brick Wall that defines the way.
> 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:
Clear Specs. You need to provide clear written specifications
of want you want.
> 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.
Brick Wall. These instructions are crystal clear. There are no
alternative paths. Make them do it over until they get it right.
> 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.
Daily Plan, Check Tick. Early Review. All of these would have
detected the lack of progress in 1 or 2 days at which point you
would have applied Clear Specs and/or Brick Wall to get things
moving. By the way "Research boost::fusion" would not be an
acceptable work queue item for the daily plan. It is far to
vague and general.
> 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.
Clear Specs. Home Work. Early Review. Check Tick. I'm guessing
you were not providing clear *written* specs perhaps in the form
of some rough interface/implementation code skeletons. Also, you
might have assigned reading material for Home Work. Finally your
Early Review and Check Ticks would have prevented days of lost
work.
> 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.
Clear Specs. Give him code code to work with or if necessary
pair program with him some. He will learn from that activity.
> 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?
Micromanaging *juniors* it not necessarily so bad at least in
the beginning when there is a lot to learn. But Clear Spec can
go a long way without micromanaging in the usual sense.
Saying to hell with it obviously will not allow you to distribute
the work loads. Clear Specs will allow you to do that. Remember,
these specs must be written. If you need to spend a day writing
specs, do it. That is the only way you can parallelize work to
juniors.
> How do you mentor a whole team of people and still get
> something written?
Well, 3 people is in my opinion about the maximum you can closely
manage and still do other work yourself. I believe the practices I
outlined above will help you.
> 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?
Are you using mostly written or mostly verbal communication?
> 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.
Focus on getting the 80% or 90% of essential features that you
know you can finish. Worry about the other spice later.
Early Review. You have to view the work product first hand.
> > 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
Sure. However, you need to assign sufficient time to effectively
distribute the work load as well. If you need to write specs then
write specs. Don't feel like you are wasting time. Also, don't be
afraid to delegate "hard" stuff. With the procedures above you
*will* get the code you want and if not Brick Wall until you do.
> > 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.
Don't just encourage, assign them specific concrete Home Work
and discuss it with them the next day.
> 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.
What exactly were you preparing? Written specs?
> 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.
I sympathize. It is a learning process and sometimes a hard
process. It can also be rewarding though so keep trying.
Ian Collins wrote:
> Try pairing with them for a while.
Yes that sometimes works very well as part of Clear Specs and Early
Review.
On Jul 9, 5:10 pm, Stuart Golodetz
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
> It sounds like you may to some extent be leaving your team alone for too
> long at a time and giving them a bit too much autonomy. There's a fine
> line between delegating to your team and trusting them to do the right
> thing, and slightly abdicating your responsibility to lead them by
> giving them tasks and then not following them up to make sure they're done.
Precisely. Daily Plan, Check Tick, Early Review.
> 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
Daily Plan helps to maintain focus and progress.
> 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.
Indeed. Check Ticks.
> If you leave them alone -
> which you see as trusting them to get on with it - they think you've got
> better things to do, and won't be committed to the task. It doesn't have
> to be a major time sink for you (and it's best not to keep bugging them
> the whole time when they need to get on with it), but checking in with
> them at the start/end of each day for 5-10 minutes is not unreasonable.
Spot on. I recommend start (Daily Plan), middle (Check Tick),
and end (Check Tick and Early Review).
> To manage effectively, you need up-to-date information about what
> they're up to and how it's going - and the best way to get that is
> face-to-face. If necessary, have a short daily catch-up. Bring cake.
Yes. It also let you help them resolve problems. Sometimes your
superior experience will let you give them a guiding light that
can hours days or weeks of work. In this way you act more as a
mentor than a manager, and that is a very good thing.
> 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.
Yes. And so can very active and efficient use of a fast internal
email system. Email is usually the best for spontaneous but not
urgent communication since it avoids expensive context shifts
that result from interrupting someone.
> 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.
I think it might have been a lack of Clear Spec.
> Re. the svn chap - you might be better off not making it an issue of
> trust (implying that you don't trust somebody is corrosive to a working
> relationship). It's very unlikely that he's deliberately messing up the
> repository structure to disobey you - much more likely is that he didn't
> understand how important you believe it to be, or that he simply
> forgot/wasn't paying attention. In the first instance, you're probably
> best off emphasising its importance to him (firmly but gently), rather
> than directing blame/criticism his way, however tempting. If it happens
> again, then you have more reason to get annoyed.
The Brick Wall is cold and immovable. It is neither a friend
nor foe neither does it trust nor mistrust. It is simply FACT.
> So essentially, I'd say:
>
> * Give a really clear lead (even clearer than you're doing at the moment
> - maybe even write it down for them) and check regularly on people you
> know have a tendency not to listen/do what you ask them to (and find out
> why they don't - occasionally they will have cause)
Exactly. Clear Spec. Must be written.
> * Improve communication by regular, *short* catch-up meetings and by
> improving the physical layout
Again spot on. Check Tick.
> * Recognise skill deficiencies (as opposed to incompetence) and send
> people on training courses where appropriate - don't necessarily assume
> that people with lots of experience know everything you'd expect
Indeed. Clear Spec and Home Work.
> * Be firm when necessary, but give people a chance first
Oh yeah baby, Brick Wall.
On Jul 12, 7:07 am, Ferdinand Mitterbauer
<ferdinand.mitterba...@gmx.at> wrote:
> 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).
Spot on. Early Review is crucial.
On Jul 9, 5:57 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> You need to read a book entitled:
>
> The Mythical Man-Month
> Frederick P. Brooks
> http://bit.ly/gt1t8
Yes, that is a MUST read.
Home Work.
On Jul 10, 8:13 am, mzdude <jsa...@cox.net> wrote:
> 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.
It takes me at least 12 hours per week to manage a junior.
On Jul 10, 5:32 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> 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.
Agreed. He needs to focus on the 80% of the requirements that
he can deliver.
> 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.
Clear Spec. However, I don't let them implement "however they
want". Early Review and Peer Review will influence (heavily at
times) the implementation of junior members.
> 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.
Yeah, modularity is one of the coolest concepts ever.
> The best you can do for your programmers, is to have good
> specifications (use cases and validation tests).
Agreed. Clear Spec is crucial.
On Jul 14, 4:58 am, Stuart Redmann <DerTop...@web.de> wrote:
> 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.
Those rough guidelines are true in my experience.
> 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.
Hehe ... I know the feeling.
> 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.
That is good advice.
On Jul 14, 11:35 am, Noah Roberts <roberts.n...@gmail.com> 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.
I really do sympathize with you. Perhaps you could form some
contacts in the larger software development community to at
least get some mentoring outside of work. At least you have
some good forums though ;-)
KHD
James Kanze
Were you working alone, or in a group? If alone, how did you do
code reviews, or brainstorming sessions. Good programming is a
team effort---a single individual is incapable of writing a
correct program, regardless of how skilled he is. And team
efforts mean collaboration and communication, which in turn
requires face to face communication.
James Kanze
wrote:
I don't buy that. It's possible that he can't get the required
staff at his place of work, but that's a budgeting or an
administrative problem, not linked to place---he won't be able
to hire a good programmer regardless of where he finds him:
locally or somewhere else.
James Kanze
> > In general. But not at the OP's place, where he just cannot
> > find good programmers, because there's a scarcity of
> > programmers, good or bad.
> I should say "experienced" programmers. The guys I have under
> me are good, they just lack experience...especially in design.
And you can't hire an experienced programmer? In practice,
there are a lot of things inexperienced programmers can do as
well. But you still need a core of experienced programmers for
the critical parts, and for things like mentoring, and bringing
the inexperienced programmers up to speed. (Or is it a
manageerial problem. I've encountered companies where a
software engineer was a software engineer, and all software
engineers were considered "equivalent", with the role of the
personel department being to find the cheepest supplier for this
commodity. Obviously, such companies do end up with teams that
are largely incompetent, since they lower the offered salaries
until the only people who apply are those who no one else would
employ.)
Ian Collins
> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>
>>>> But mostly the point here is that you don't have the choice between:
>>>> - a good programmer here, and
>>>> - a good programmer there,
>>>> but between:
>>>> - a bad (because you don't have any choice) programmer here, and
>>>> - a good (because you have more to choose amongst) programmer there.
>
>>> There are good programmers everywhere. The choice is
>>> between a good programmer here, where you can manage him
>>> well, and a good programmer elsewhere, where you can't
>>> manage him, so he can't perform.
>
>> I don't get that. I've worked for clients on the other side of
>> the world and we'd both say that they had no trouble managing
>> me (not that they had to) and that I performed well.
>
> Were you working alone, or in a group?
Alone.
> If alone, how did you do code reviews, or brainstorming sessions.
Acceptance testing and any reviews where done by the clients.
Brainstorming sessions where done over the phone.
> Good programming is a
> team effort---a single individual is incapable of writing a
> correct program, regardless of how skilled he is.
Maybe, but I've written a lot of programmes for clients incapable of
reviewing the code. "Correct" behaviour can be determined with
sufficient developer and client testing.
> And team
> efforts mean collaboration and communication, which in turn
> requires face to face communication.
True, but the collaboration and communication doesn't have to be between
programmers. Programmer - client communication is at least as
important as programmer - programmer communication.
--
Ian Collins
Pascal J. Bourguignon
> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>> > wrote:
>
>> >> But mostly the point here is that you don't have the choice between:
>> >> - a good programmer here, and
>> >> - a good programmer there,
>> >> but between:
>> >> - a bad (because you don't have any choice) programmer here, and
>> >> - a good (because you have more to choose amongst) programmer there.
>
>> > There are good programmers everywhere. The choice is
>> > between a good programmer here, where you can manage him
>> > well, and a good programmer elsewhere, where you can't
>> > manage him, so he can't perform.
>
>> I don't get that. I've worked for clients on the other side of
>> the world and we'd both say that they had no trouble managing
>> me (not that they had to) and that I performed well.
>
> Were you working alone, or in a group?
Alone too.
> If alone, how did you do code reviews, or brainstorming sessions.
Group work is not a guarantee of implementing code reviews.
Basically, you can do code reviews alone, by just forgetting your
code, and then reviewing it.
> Good programming is a team effort
AFAICSITRL, this is completely wrong. Team programming leads to huge
quasi unmaintenable, bug-ridden programs that nobody can understand
completely, and that work only by miracle (and thanks to
encapsulation).
Mostly, where there's something wrong in a program by one, the one
will pause and correct the wrong thing. When there's something wrong
in a program by many, there is a lot of red tape, and group psychology
to overcome before being able to correct it. In practice most
problems in team programs never get corrected, just wrapped over as
far as there's a customer crying for a bug correction.
> a single individual is incapable of writing a correct program,
> regardless of how skilled he is.
This is obviously wrong, there are several example.
What may be true is that the scope and size of a program written by an
individual might be smaller, but how would that be a bad thing? At
least an individual will produce programs that are understandable and
manageable.
> And team efforts mean collaboration and communication, which in turn
> requires face to face communication.
"Mythical Man Month".
--
__Pascal Bourguignon__
Christof Donat
I've been leading a team in another company a while ago. Since I have
started my own business six years ago, of course I do all the management
as well. Actually I have to admit, that I never had these kind of
problems, because people always very much respected me as their manager
soon. It seems, that you already fell into the trap of not beeing
respected. Now things are a lot harder for you. You have to get your
team to accept you as their manager.
> 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.
So you entered college, when svn was allready in a usable state. This
kind of project structure is not typical with most other VC Systems. I
guess your programmers grew up with cvs or even rcs as a VC System if
one at all.
The structure you describe is really a good idea with svn. Don't move
away from it. I'm just saying, maybe they don't accept beeing lead by
such a young guy - compared to them self. I don't know how you came to
that position and what was up before you got there. Maybe some of the
team members originally hoped to get your current position or they think
you got there not because of your qualification but because your uncles
neighbour had a friend, etc.
My advice:
Show them you don't really need them, you can do everything they do at
least as good as they can. They are just there because you don't have
the time to do everything yourself. That will make them respect you as a
"real man". This is tough for you and really hard work, but if you can
do what they are doing, do it and show it to everyone in the team.
Listen to them. When your team members say, that your work is not good
ask them how you can improve it. That will give them the feeling that
you are respecting their experience. Diskuss their suggestions with them
to show them, that you really want to unterstand and improve your
skills. This seems a bit like the opposite to the above advice, but it
really isn't. In the summ you show them that you are one of them. Be the
primus inter paris.
If someone in the team is cooperating, give interesting projects to him.
Tell the whole team, that guy XY gets the interesting project, because
last time he did such a good work. As soon as one of the non cooperating
people starts cooperating give him an interesting project as soon as
possible. Let him be the lost son that comes back and tell all the other
how good his work was.
Never ever citisize the work of one of yout team members when someone
from outside is listening. Any critics always stays in the team. If some
of the team members starts doing that with one of his collegues, cut
him.
The team should be kind of the inner circle and internal discussions
should stay internal. This gives the team members the feeling like being
a kind of tribe and you are the chief of the tribe. You fight for them
against the bad outside world and they have to support you in this
heroic fight - kind of.
And of course talk to your manager and discuss with him what you are
planing to do. I guess he is a more experienced manager than you are and
he can give you good advice. I also guess,he knows the team members
longer than you do. He can give you some hints about them.
If you can't avoid talking to him about people doing bad work in your
team try not to name them. If you can not avoid doing that, make shure,
that the information stays confidential. When your team members learn
that you have done that, you are no longer the chief of the tribe, but a
traitor.
Christof
Alf P. Steinbach
>
> Were you working alone, or in a group? If alone, how did you do
> code reviews, or brainstorming sessions. Good programming is a
> team effort---a single individual is incapable of writing a
> correct program, regardless of how skilled he is.
Donald Knuth: LeX.
As I understand it and vaguely recall it was an interesting exercise in
"literate programming", a kind of far more sophisticated and powerful version of
today's doc comments (like //@), with the code just part of the documentation. :-)
However I've never seen the code.
- Alf
Pascal J. Bourguignon
A lot of Open Source software are the work of single men, even if
later the original authors are able to aggregate contributors. But
notice that then, all the work is done remotely, with absolutely no
"management".
--
__Pascal Bourguignon__
Brian Wood
wrote:
I think this is a growing problem. Even some of the "good
companies" are poorly run.
> > a single individual is incapable of writing a correct program,
> > regardless of how skilled he is.
>
It may help to recall how Noah and his three sons built the
ark. In that case a single family worked out their salvation
while others were lost to the flood. That family was able to
produce a vessel capable of saving both them and a bunch of
animals including some birds that eventually helped them find
land.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
"As iron sharpens iron, so one man sharpens another."
Proverbs 27:17
Default User
> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> > I don't get that. I've worked for clients on the other side of
> > the world and we'd both say that they had no trouble managing
> > me (not that they had to) and that I performed well.
>
> Were you working alone, or in a group? If alone, how did you do
> code reviews, or brainstorming sessions. Good programming is a
> team effort---a single individual is incapable of writing a
> correct program, regardless of how skilled he is. And team
> efforts mean collaboration and communication, which in turn
> requires face to face communication.
The past 2-1/2 years I've been working with groups half-way across the
country. I've had next to no face-to-face with them. We use online
meetings, telecons, email, instant messaging, all the modrun stuff.
Now, it would be convenient it they were here, don't get me wrong, but
it's certainly not impossible.
Brian
Andrew Tomazos
> It may help to recall how Noah and his three sons built the
> ark. In that case a single family worked out their salvation
> while others were lost to the flood. That family was able to
> produce a vessel capable of saving both them and a bunch of
> animals including some birds that eventually helped them find
> land.
Now tell the story of the Titantic, where a large team of the worlds
best engineers worked together in a flawless professional process to
produce an unsinkable ship.
-Andrew.
James Kanze
> James Kanze wrote:
> > On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
[...]
> >> I don't get that. I've worked for clients on the other side of
> >> the world and we'd both say that they had no trouble managing
> >> me (not that they had to) and that I performed well.
> > Were you working alone, or in a group?
> Alone.
> > If alone, how did you do code reviews, or brainstorming
> > sessions.
> Acceptance testing and any reviews where done by the clients.
I would take that as a given. But if I were a client, the code
would either pass or fail the review, and if it failed, you
won't be paid. As a client, the reason I pay is to not have to
do all of the work.
> Brainstorming sessions where done over the phone.
My experience is that often, the most important "brainstorming
sessions" are the impromptu ones. You cross someone working on
a different component at the coffee machine, and get to talking,
and you end up setting up a brainstorming session.
I'm not saying that with such modern tools as teleconferencing,
it is completely impossible, but I'm very, very sceptical. In
my experience, so much essential communication is impromptu---a
result of discussions with people you meet at the coffee
machine, and not a direct result of concrete planning.
> > Good programming is a team effort---a single individual is
> > incapable of writing a correct program, regardless of how
> > skilled he is.
> Maybe, but I've written a lot of programmes for clients
> incapable of reviewing the code. "Correct" behaviour can be
> determined with sufficient developer and client testing.
Testing can never prove correction; it can only prove that the
code is incorrect. Depending on the application, stricter
proofs may be necessary (in which case, the client will have
someone competent, or employ a competent third party, to
validate them), or the client may simply depend on you to ensure
a certain level of correction.
> > And team efforts mean collaboration and communication, which
> > in turn requires face to face communication.
> True, but the collaboration and communication doesn't have to
> be between programmers. Programmer - client communication is
> at least as important as programmer - programmer
> communication.
Certainly. And programmer--management communication as well.
Generally, the client--implementer communication will be
somewhat structured, but the programmer--programmer, and to a
degree, the programmer--management, communication entails a
significant amount of impromptu communication (as well as some
structured communication).
James Kanze
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> >> > wrote:
[...]
> >> > There are good programmers everywhere. The choice is
> >> > between a good programmer here, where you can manage him
> >> > well, and a good programmer elsewhere, where you can't
> >> > manage him, so he can't perform.
> >> I don't get that. I've worked for clients on the other side of
> >> the world and we'd both say that they had no trouble managing
> >> me (not that they had to) and that I performed well.
> > Were you working alone, or in a group?
> Alone too.
> > If alone, how did you do code reviews, or brainstorming
> > sessions.
> Group work is not a guarantee of implementing code reviews.
Working along is a guarantee that they aren't implemented,
however.
> Basically, you can do code reviews alone, by just forgetting
> your code, and then reviewing it.
I do that too, when I have to work alone. It's still far from
being as effective as having other people do the review.
There's also all of the ad hoc discussions that occur (or should
occur) when you're working in a team. You discuss what you're
doing with someone else at the coffee machine, and he points out
a potential problem. That you then fix, before formel review.
> > Good programming is a team effort
> AFAICSITRL, this is completely wrong. Team programming leads
> to huge quasi unmaintenable, bug-ridden programs that nobody
> can understand completely, and that work only by miracle (and
> thanks to encapsulation).
No doubt that's why all of the companies implementing critical
systems insist on team programming, and why it is required in
such cases.
> Mostly, where there's something wrong in a program by one, the
> one will pause and correct the wrong thing. When there's
> something wrong in a program by many, there is a lot of red
> tape, and group psychology to overcome before being able to
> correct it. In practice most problems in team programs never
> get corrected, just wrapped over as far as there's a customer
> crying for a bug correction.
That's just bullshit. Mostly, programmers are human beings, and
as such, imperfect. They all make mistakes. And they don't see
their own mistakes---that takes someone else.
> > a single individual is incapable of writing a correct program,
> > regardless of how skilled he is.
> This is obviously wrong, there are several example.
Such as?
> What may be true is that the scope and size of a program
> written by an individual might be smaller, but how would that
> be a bad thing? At least an individual will produce programs
> that are understandable and manageable.
> > And team efforts mean collaboration and communication, which in turn
> > requires face to face communication.
> "Mythical Man Month".
Irrelevant here. You're not adding additional people (beyond
the optimal) in the middle of a project, to hopefully make the
project go faster.
James Kanze
> wrote:
[...]
> > > a single individual is incapable of writing a correct
> > > program, regardless of how skilled he is.
> It may help to recall how Noah and his three sons built the
> ark. In that case a single family worked out their salvation
> while others were lost to the flood. That family was able to
> produce a vessel capable of saving both them and a bunch of
> animals including some birds that eventually helped them find
> land.
That family wasn't a single individual. And in the version I
heard, they had some significant outside help, especially with
regards to design and management.
James Kanze
> * James Kanze:
> > Were you working alone, or in a group? If alone, how did you do
> > code reviews, or brainstorming sessions. Good programming is a
> > team effort---a single individual is incapable of writing a
> > correct program, regardless of how skilled he is.
> Donald Knuth: LeX.
That's probably the closest, but don't forget that he was a
professor, and supervised a number of doctorat theses. I don't
think that anyone in accademia really can be said to be working
alone. (I seem to recall reading somewhere that in fact,
something like 80% of TeX was actually coded by one of his grad
students. I can't find the reference, and I'm not really 100%
sure, but it certainly sounds likely, based on what little I
know of accademia.)
Most teams, of course, don't have anyone nearly that skilled,
and most projects today are significantly larger, as well, so
even if he did do it alone, that would be the exception that
confirms the rule. But if it makes you happier, I'm willing to
modify my statement to the effect that "a single individual is
incapable of writing a correct program, unless he is at least as
skilled as Donald Knuth." I still think my original wording is
more exact, but since I don't have any concrete experience
working with people as skilled as Knuth, I can't be 100% sure.
> As I understand it and vaguely recall it was an interesting
> exercise in "literate programming", a kind of far more
> sophisticated and powerful version of today's doc comments
> (like //@), with the code just part of the documentation. :-)
A far more sophisticated and powerful version, yes. One which
starts from the correct philosophy: you write the documentation
first, and extract the code from it, rather than vice versa.
> However I've never seen the code.
I have.
The real problem is that it is still "source code". TeX source
code, rather than Pascal source code, but the TeX markup is
there, embedded in the document. It's still an order of
magnitude better than most other things I've seen (since the
markup isn't that invasive), and later adaptations seem to have
improved it even more, but you're still writing to be read at
two levels: a generated document (where the markup handles
sectionning and other details) and the actual document the
maintenance programmer sees (which contains markup, and whose
formatting depends on what you've entered directly, e.g. spaces,
new lines, etc.).
James Kanze
wrote:
> "Alf P. Steinbach" <al...@start.no> writes:
> > * James Kanze:
> A lot of Open Source software are the work of single men,
> even if later the original authors are able to aggregate
> contributors. But notice that then, all the work is done
> remotely, with absolutely no "management".
Which explains why so much of it is total junk. There are a few
exceptions, like g++, but 1) they do have some sort of
management, and 2) they're only "good" compared with the
commercial equivalents, which often don't have any decent
management either.
Stuart Golodetz
There's a valid point in there to be fair - namely that if you decide
you've gone down the wrong path with a system which you've written
entirely yourself, you're generally more in a position to go back and
rewrite it than you are if you're working in a team. In a team, you have
to first convince all the other people working on the system that you've
gone down the wrong path and that it's worth fixing.
It's not a question of whether programmers are perfect or otherwise --
clearly they're not. There can definitely be advantages to team working
in terms of spotting mistakes, provided you go about it in a sensible
way. None of this greatly impacts on the point just made however.
In terms of programmers not seeing their own mistakes -- I guess you
could divide it up into unforced errors and forced errors, rather like
in tennis. The forced errors (the ones you made because you lacked
knowledge/understanding of the issues) are ones you probably won't spot
yourself (unless your knowledge/understanding increases in the interim,
or you happen across a similar issue whilst e.g. reading newsgroups,
browsing the web, etc.) The unforced errors (the ones where you just did
something silly which you should have spotted the first time) are ones
you've got a reasonable chance of finding yourself.
>>> a single individual is incapable of writing a correct program,
>>> regardless of how skilled he is.
>
>> This is obviously wrong, there are several example.
>
> Such as?
Here's an example: suppose my spec says "write a program which is valid
C++ but does absolutely nothing". My implementation looks like:
int main()
{
return 0;
}
That's a correct program (although I look forward to somebody
challenging that assertion :-)) which meets its specification. I'm a
single individual, and I wrote it. Surely that makes the statement above
false? We can change the terms of debate to "correct *non-trivial*
program" if you like, but even then it's still doable to write some such
program on your own (not every non-trivial program can be written
correctly by an individual, evidently, but it suffices to demonstrate at
least one such program).
>> What may be true is that the scope and size of a program
>> written by an individual might be smaller, but how would that
>> be a bad thing? At least an individual will produce programs
>> that are understandable and manageable.
>
>>> And team efforts mean collaboration and communication, which in turn
>>> requires face to face communication.
>
>> "Mythical Man Month".
>
> Irrelevant here. You're not adding additional people (beyond
> the optimal) in the middle of a project, to hopefully make the
> project go faster.
The Mythical Man Month had other stuff in it besides that. See e.g. p.78
"Organization in the Large Programming Project":
"If there are n workers on a project, there are (n^2-n)/2 interfaces
across which there may be communication, and there are potentially
almost 2^n teams within which coordination must occur..."
Cheers,
Stu
> --
> James Kanze (GABI Software) email:james...@gmail.com
> 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
Ian Collins
> On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> James Kanze wrote:
>
> [...]
>>>> I don't get that. I've worked for clients on the other side of
>>>> the world and we'd both say that they had no trouble managing
>>>> me (not that they had to) and that I performed well.
>
>>> Were you working alone, or in a group?
>
>> Alone.
>
>>> If alone, how did you do code reviews, or brainstorming
>>> sessions.
>
>> Acceptance testing and any reviews where done by the clients.
>
> I would take that as a given. But if I were a client, the code
> would either pass or fail the review, and if it failed, you
> won't be paid. As a client, the reason I pay is to not have to
> do all of the work.
The code either pass or fails the tests.
>>> Good programming is a team effort---a single individual is
>>> incapable of writing a correct program, regardless of how
>>> skilled he is.
>
>> Maybe, but I've written a lot of programmes for clients
>> incapable of reviewing the code. "Correct" behaviour can be
>> determined with sufficient developer and client testing.
>
> Testing can never prove correction; it can only prove that the
> code is incorrect.
Correctness is in the eye of the beholder, in my case that's the client.
>> True, but the collaboration and communication doesn't have to
>> be between programmers. Programmer - client communication is
>> at least as important as programmer - programmer
>> communication.
>
> Certainly. And programmer--management communication as well.
> Generally, the client--implementer communication will be
> somewhat structured, but the programmer--programmer, and to a
> degree, the programmer--management, communication entails a
> significant amount of impromptu communication (as well as some
> structured communication).
So should client - programmer. This is more typical and important when
there is a single client and a single implementer.
--
Ian Collins
James Kanze
> James Kanze wrote:
> > On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >>>> James Kanze wrote:
> > [...]
> > I would take that as a given. But if I were a client, the
> > code would either pass or fail the review, and if it failed,
> > you won't be paid. As a client, the reason I pay is to not
> > have to do all of the work.
> The code either pass or fails the tests.
Since you'll be writing the tests, that won't help me much. And
I want the code not only to work, but to be maintainable.
> >>> Good programming is a team effort---a single individual is
> >>> incapable of writing a correct program, regardless of how
> >>> skilled he is.
> >> Maybe, but I've written a lot of programmes for clients
> >> incapable of reviewing the code. "Correct" behaviour can be
> >> determined with sufficient developer and client testing.
> > Testing can never prove correction; it can only prove that the
> > code is incorrect.
> Correctness is in the eye of the beholder, in my case that's
> the client.
Yes, and no professionally competent organization will accept
code just because it passes some arbitrary set of tests. It has
to be maintainable.
> >> True, but the collaboration and communication doesn't have
> >> to be between programmers. Programmer - client
> >> communication is at least as important as programmer -
> >> programmer communication.
> > Certainly. And programmer--management communication as
> > well. Generally, the client--implementer communication will
> > be somewhat structured, but the programmer--programmer, and
> > to a degree, the programmer--management, communication
> > entails a significant amount of impromptu communication (as
> > well as some structured communication).
> So should client - programmer. This is more typical and
> important when there is a single client and a single
> implementer.
In such cases, one could argue that the development isn't just
the implementer; that the implementer is in fact part of my in
house team. In such cases, impromtu communication is important;
that's why I always work on the customer site. I tried once
working at a distance, but quickly found that I was "out of the
loop".
Also, I don't pretend to fournish finished software in such
cases. I'm part of the customer's team (except for tax and
labor law purposes).
Keith H Duggar
> James Kanze wrote:
> > Pascal J. Bourguignon wrote:
> > > > a single individual is incapable of writing a correct program,
> > > > regardless of how skilled he is.
>
> > > This is obviously wrong, there are several example.
>
> > Such as?
>
> Here's an example: suppose my spec says "write a program which is valid
> C++ but does absolutely nothing". My implementation looks like:
>
> int main()
> {
> return 0;
>
> }
>
> That's a correct program (although I look forward to somebody
> challenging that assertion :-)) which meets its specification. I'm a
> single individual, and I wrote it. Surely that makes the statement above
> false? We can change the terms of debate to "correct *non-trivial*
> program" if you like
I think those are already the terms of an adult debate. In other
words this isn't 1st grade playground my dad can kick your dad's
ass a million gazillion times banter. So you might have known or
at least assumed upfront that James didn't mean nonsense trivial
"look what I can do" programs.
So, it would be nice to explore real world examples. Knuth's TeX
was brought up as a counter example. However, people other than
Knuth found and reported (to Knuth) bugs in TeX. So I don't know
if TeX falls under James' definition of "correct" or not, and if
that 3rd party testing breaks "single individual" or not.
KHD
Ian Collins
> On Jul 19, 9:55 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> James Kanze wrote:
>>>>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>>>>> James Kanze wrote:
>
>>> [...]
>>> I would take that as a given. But if I were a client, the
>>> code would either pass or fail the review, and if it failed,
>>> you won't be paid. As a client, the reason I pay is to not
>>> have to do all of the work.
>
>> The code either pass or fails the tests.
>
> Since you'll be writing the tests, that won't help me much. And
> I want the code not only to work, but to be maintainable.
The code either pass or fails the customer's tests.
>>> Testing can never prove correction; it can only prove that the
>>> code is incorrect.
>
>> Correctness is in the eye of the beholder, in my case that's
>> the client.
>
> Yes, and no professionally competent organization will accept
> code just because it passes some arbitrary set of tests. It has
> to be maintainable.
Then there's a lot of professionally competent organisations out there!
In my case, I'm the one paid to maintain the code. They pay for
additions, I pay for bug fixing. Which gives me the incentive to
deliver what they want and make sure they test it.
--
Ian Collins
Brian Wood
> On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
>
> > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> [...]
>
> > > > a single individual is incapable of writing a correct
> > > > program, regardless of how skilled he is.
> > It may help to recall how Noah and his three sons built the
> > ark. In that case a single family worked out their salvation
> > while others were lost to the flood. That family was able to
> > produce a vessel capable of saving both them and a bunch of
> > animals including some birds that eventually helped them find
> > land.
>
> That family wasn't a single individual. And in the version I
> heard, they had some significant outside help, especially with
> regards to design and management.
>
There were four men and they each had a wife. They had as you
say a lot of "outside help". Anyway, I bring it up as an
example of a large, successful project that involved a small
number of people. I am not arguing against what you wrote,
but saying there's no reason to be afraid of joining a small
team that has a big project in front of them.
James Kanze
> On Jul 19, 5:21 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
> > > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > [...]
> > > > > a single individual is incapable of writing a correct
> > > > > program, regardless of how skilled he is.
> > > It may help to recall how Noah and his three sons built
> > > the ark. In that case a single family worked out their
> > > salvation while others were lost to the flood. That
> > > family was able to produce a vessel capable of saving both
> > > them and a bunch of animals including some birds that
> > > eventually helped them find land.
> > That family wasn't a single individual. And in the version
> > I heard, they had some significant outside help, especially
> > with regards to design and management.
> There were four men and they each had a wife. They had as you
> say a lot of "outside help".
Of a sort most software projects can't hope for. (Most software
projects can't even hope for someone as skilled as Knuth, much
less an omniscient, infallible design specialist.)
> Anyway, I bring it up as an example of a large, successful
> project that involved a small number of people. I am not
> arguing against what you wrote, but saying there's no reason
> to be afraid of joining a small team that has a big project in
> front of them.
I've never said anything against small teams. In fact, it's
generally easier to establish the necessary communication in a
small team. The ideal size of the team will vary, depending on
the size and complexity of the project, and the desired delay.
Optimizing for cost will *NOT* generally result in the shortest
delay, but you will run up against a limit fairly soon when
trying to shorten the delay which results in lowest cost.
James Kanze
The real question is: what do we mean by "correct"? There's a
very real sense that my statement is trivially correct: no
non-trivial program can be guaranteed 100% correct (without any
bugs), so obviously, no non-trivial program written by a single
person can be 100% correct. That's just game playing, like
Stuarts example of a program which does nothing, but the
question remains: how many bugs to we accept? And do we take
into consideration maintainability issues: how difficult is it
to correct the bugs once they are found? (With regards to TeX,
at least seven bugs have been found and fixed since version 3.0
was released. The source is around 40KLOC, so that's not a
particularly low bug rate.)
What I'd really be interesting in seeing is a real life example
of a real program written by a single person which is considered
correct, with a statement as to what is considered correct or
how it is known to be correct.
--
James Kanze (GABI Software) email:james...@gmail.com
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
Gerhard Fiedler
> I don't buy that. It's possible that he can't get the required staff
> at his place of work, but that's a budgeting or an administrative
> problem, not linked to place---he won't be able to hire a good
> programmer regardless of where he finds him: locally or somewhere
> else.
There's always an option, and everything is a trade-off... :)
Not everybody is in a metropolis, or in a densely populated, highly
developed area. It seems to be obvious that for any given specific skill
there are many places where it can't be found locally; not sure why
anybody would want to debate this. The cost of convincing someone with
the skill to move to where the skill is needed may be prohibitive.
This regularly puts people in the situation of having to decide between
a local, lesser qualified (for a particular job or situation) person and
a remote but better qualified person, and of having to calculate the
trade-off between the advantages of the immediate communication physical
presence brings and the advantages proper qualification (for this
particular job or situation) brings. This trade-off doesn't always swing
towards the immediate communication.
Gerhard
Brian Wood
> On Jul 20, 9:16 am, Brian Wood <c...@mailvault.com> wrote:
>
>
>
>
>
> > On Jul 19, 5:21 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
> > > > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > [...]
> > > > > > a single individual is incapable of writing a correct
> > > > > > program, regardless of how skilled he is.
> > > > It may help to recall how Noah and his three sons built
> > > > the ark. In that case a single family worked out their
> > > > salvation while others were lost to the flood. That
> > > > family was able to produce a vessel capable of saving both
> > > > them and a bunch of animals including some birds that
> > > > eventually helped them find land.
> > > That family wasn't a single individual. And in the version
> > > I heard, they had some significant outside help, especially
> > > with regards to design and management.
> > There were four men and they each had a wife. They had as you
> > say a lot of "outside help".
>
> Of a sort most software projects can't hope for. (Most software
> projects can't even hope for someone as skilled as Knuth, much
> less an omniscient, infallible design specialist.)
I disagree. G-d wants to help people and still does so.
More recently, there's David and Goliath. David killed
Goliath even though Goliath was more experienced and
was much bigger physically than David.
If you said, most software projects don't even hope for
someone as skilled as Knuth, much less ..., I'd be more
inclined to agree. But there's something wrong with that.
How could a software project hope for anything? I'll assume
you're not playing some sort of word game.
>
> I've never said anything against small teams. In fact, it's
> generally easier to establish the necessary communication in a
> small team. The ideal size of the team will vary, depending on
> the size and complexity of the project, and the desired delay.
> Optimizing for cost will *NOT* generally result in the shortest
> delay, but you will run up against a limit fairly soon when
> trying to shorten the delay which results in lowest cost.
>
Are you saying there's an organic aspect to projects that
should be considered?
Gerhard Fiedler
> -- Clear Specs : it is essential that managers write workable and
> clear specifications. Code is one of the clearest forms of
> communication so provide them with skeletons of what you want such as
> interfaces or algorithms where appropriate. All specs must be
> written! It's good to verbally explain and discuss the specs, but
> ultimately the verbal communication must denoted in written form and
> communicated. Employees should take notes in technical discussions
> related to work items. If necessary this fold all the way down to
> pair programming.
An important aspect of "clear" specs is that they must be clear to both
parties :) This basically means that the level of detail depends on the
person doing the job. For some, a high-level description is good enough,
because you can trust that they either know what to do, or know when
they don't know -- and go out themselves and efficiently get that
information, as well as you could do it. For others, you need to be more
specific.
It's important to get a feel for this level. Too detailed, and people
feel micromanaged and may get demotivated. Too coarse, and people feel
(or are) lost -- and may get demotivated just the same :)
Ideally the level is so that the person is pround that she managed to
complete it, and what she did is so that you can say "great job!"
Gerhard
Keith H Duggar
wrote:
> Noah Roberts <roberts.n...@gmail.com> 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.
Can you please recommend a few websites or other resources that you
find most helpful for finding and utilizing quality developers over
the Internet? Thanks!
KHD
Noah Roberts
Noah Roberts
> There were four men and they each had a wife. They had as you
> say a lot of "outside help". Anyway, I bring it up as an
> example of a large, successful project that involved a small
> number of people. I am not arguing against what you wrote,
> but saying there's no reason to be afraid of joining a small
> team that has a big project in front of them.
A large, impossible project. I for one think fairy tale solutions to
real world problems is PART of the problem in the software industry.
I gather you believe it, and you're free to do so, but for those of us
who can't depend on miracles and a god's personal intervention (come on,
even you must admit that the lumber alone would have taken 4 people a
decade to produce) need to concentrate on methods that don't involve
divine boogiemen.
Noah Roberts
> I disagree. G-d wants to help people and still does so.
Is there any conversation in which people won't attempt to prostheletize?
Brian Wood
In the United States the national motto is: In G-d we trust.
I believe G-d has been and is leading me with Ebenezer
Enterprises. With many companies failing, I suggest to them
the same help I've got. He doesn't charge anything for his
help.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
"Unless the L-RD builds the house, they labor in vain
that build it; unless the L-RD keeps the city, the
watchman waketh but in vain." Psalm 127:1
Noah Roberts
> On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> Brian Wood wrote:
>>> I disagree. G-d wants to help people and still does so.
>> Is there any conversation in which people won't attempt to prostheletize?
>
>
> In the United States the national motto is: In G-d we trust.
Rewriting/forgetting US history is not a valid excuse for rudely
intruding in a reasonable conversation about important issues with your
religiously led need to convert everyone to your way of thinking. You
can be happy with what one group of lawmakers decided--nearly 200 years
after the formation of the country--to be our national motto (replacing
the original) but it's completely beside the point in professional
conversations (unless of course your profession is religion).
Many of us recognize the fact that cultures go through phases and in the
1950's this country was under the influence of a religious fervor and
fear of "The Communists". A lot of mistakes were made and a lot of
"god" injected where he didn't belong.
> I believe G-d has been and is leading me with Ebenezer
> Enterprises.
You're free to think whatever you want. I'll definitely add you to the
list of companies to run away from should I find our paths crossing.
You may as well be sacrificing chickens at your management meetings or
following the newspaper horrorscope. I'll stick to professionals, thanks.
E pluribus unum
Brian Wood
> Brian Wood wrote:
> > On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> >> Brian Wood wrote:
> >>> I disagree. G-d wants to help people and still does so.
> >> Is there any conversation in which people won't attempt to prostheletize?
>
> > In the United States the national motto is: In G-d we trust.
>
> Rewriting/forgetting US history is not a valid excuse for rudely
I'm not rewriting history. I didn't say that we never had another
national motto. If I recall correctly at one time the national
motto was: Mind your own business.
> Many of us recognize the fact that cultures go through phases and in the
> 1950's this country was under the influence of a religious fervor and
> fear of "The Communists". A lot of mistakes were made and a lot of
> "god" injected where he didn't belong.
>
Some mistakes were made, but making "in G-d we trust" our motto wasn't
a mistake. "Mind your own business" was a fine motto also.
> > I believe G-d has been and is leading me with Ebenezer
> > Enterprises.
>
> You're free to think whatever you want. I'll definitely add you to the
> list of companies to run away from should I find our paths crossing.
> You may as well be sacrificing chickens at your management meetings or
> following the newspaper horrorscope. I'll stick to professionals, thanks.
>
> E pluribus unum
There's nothing wrong with that saying.
Noah Roberts
> On Jul 21, 4:08 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> Brian Wood wrote:
>>> On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>>>> Brian Wood wrote:
>>>>> I disagree. G-d wants to help people and still does so.
>>>> Is there any conversation in which people won't attempt to prostheletize?
>>> In the United States the national motto is: In G-d we trust.
>> Rewriting/forgetting US history is not a valid excuse for rudely
>
Next time you feel the need to prostheletize in a professional
conversation you might take this bit of advice. I'll leave you to your
business, but when you shove it in my face (quite rudely I might add) I
will respond.
JustBoo
> The problem is that I'm having an incredibly hard time communicating
> what I need to communicate to the developers on my team.
Doesn't ALL of this really resolve to understanding the "Control Loop"
described in management texts. Did you cover this in college? Have they
stopped teaching this in college?
An old college book I have:
"Management" by James A.F. Stoner - Prentice-Hall, ISBN: 0-13-549303-X
(Gotta' appreciate the guys name.) :-) *Chapter 21, The Control
Process.* More chapters follow about "control."
Everyone generally freaks out when they see management and control in
the same sentence, but as usual, this tool can be used for Good or Evil.
If done correctly I would really call this a "human feedback loop." To
borrow from Control Theory, instead of HIL (hardware in the loop) or SIL
(software in the loop), think of it as "Human in the Loop" and act
accordingly.
A human "control loop" is kinda' like a programmatic control loop.
Except we have weird (hey, they're programmers right), complicated,
irrational "hu-mans" running around instead of - in comparison - nice
orderly electrons.
Just a thought.
The philosophy exam was a piece of cake which was a
bit of a surprise, actually, because I was expecting
some questions on a sheet of paper.
JustBoo
> On Jul 15, 11:04 am, p...@informatimago.com (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.
>
> 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.
So I guess Rent-A-Coder (search web for info) doesn't exist then? And
managing teams of programmers in India is right-out then!
Yeah now I get it, the year I spent �talking to some guys in India� was
a year spend in a dream world. Thanks, I always wondered about that.
"A wise man adapts himself to circumstances as water shapes itself to
the vessel that contains it." - Chinese Proverb
JustBoo
> What I'd really be interesting in seeing is a real life example
> of a real program written by a single person which is considered
> correct, with a statement as to what is considered correct or
> how it is known to be correct.
Bjarne Stroustrup developing a "program" (note the quotes) called C++?
Linus Torvalds creating the Linux kernel?
And just for fun: Paul Allen creating GW-Basic. Bwha! (See if you can
find Waldo in that one.) :-)
Enjoy.
Noah Roberts
> So I guess Rent-A-Coder (search web for info) doesn't exist then?
LOL! I said rentacoder.com as a joke! Have you actually been there?
Probably 90%, or more even, of the projects are, "I need my homework
project written."
Highest bid I see in there currently is 1500, but having spent time
trying to find worthy projects I can say that's very rare. Most are max
bid < 100.
SoftwareXChange was a better attempt. There were actually some real
professionals and some real projects being bid upon. That site fell
through though and doesn't exist anymore.
JustBoo
LOL. And your point is?
My point is that a system exists and has for years, whereby remote work
is performed and completed via the internet. If it didn't work, then it
would go the way of the flopped site you mention.
Noah Roberts
I think maybe you're missing the point.
The rentacoder model is not an example of managing teams of remote
developers. The rentacoder model is an example of independent
consultants implementing projects for customers.
Customer X needs his homework done. Consultant Y places a bid. When
the bid is won they gather requirements and does Customer X's homework.
It's not about hiring a developer to work on a project and managing that
project. It's about hiring a development "firm" to implement and manage
the project for you.
Furthermore, the projects at rentacoder for the most part are not worthy
to compare with a real world project. Doing someone's homework for them
is not the same thing as writing a large scale commercial product and
the kind of expertise you need for the two are vastly different.
JustBoo
> JustBoo wrote:
>> Noah Roberts wrote:
>>> JustBoo wrote:
>>>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
>>>
>>> LOL! I said rentacoder.com as a joke! Have you actually been there?
snippy all around.
>> LOL. And your point is?
>
> I think maybe you're missing the point.
>
> The rentacoder model is not an example of managing teams of remote
Oh, I remember you now. Never actually reads what people post and hopes
a response with a flurry of words will throw everyone off, and make
yourself feel like you've "won." Remembering that... your topic and its
subject matter makes perfect sense.
Good Luck to you sir, you'll need it.
Balwinder S Dheeman
How about SourceForge.net? I think, one can find and, or invite Hundreds
of thousands of C/C++ and, or other programmers there. Moreover, one can
easily review contributions, patches and, or other project work (mostly
available online) of these volunteer programmers
--
Balwinder S "bdheeman" Dheeman Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Noah Roberts
lol, ok.
fft1976
> ...
Good programmers are 100x more productive than average ones,
especially on hard problems, as I'm sure you know.
If you've been working only with good ones so far, welcome to reality!
Also, bad hiring practices can lead to teams that are 100% idiots. No
amount of "process" will fix that.
Btw, if you want some leadership ideas, watch "Generation Kill".
James Kanze
> On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > ...
> Good programmers are 100x more productive than average ones,
> especially on hard problems, as I'm sure you know.
"Average" programmers (whatever that means) are good
programmers.
fft1976
> On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > ...
> > Good programmers are 100x more productive than average ones,
> > especially on hard problems, as I'm sure you know.
>
> "Average" programmers (whatever that means) are good
> programmers.
>
I should have said "median". Because of the long tail in the
productivity distribution, "average" are indeed "good", or at least
"half as good". The point is the productivity difference between a
regular programmer and someone in the top 10% or so can be 2 orders of
magnitude.
Brian Wood
> On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > ...
> > Good programmers are 100x more productive than average ones,
> > especially on hard problems, as I'm sure you know.
>
> "Average" programmers (whatever that means) are good
> programmers.
>
This reminds me of something from Prarie Home Companion.
They say that all the children in Lake Wobegone are above
average. I wonder if Garrison has ever thought of asking
Stroustrup to be on the program. He could quiz Stroustrup
about programming and take some pot shots at other languages.
James Kanze
Not really. Not in terms of code, anyway, and not in a well
managed environment. If the environment is correctly managed,
in fact, the one or two programmers you have in the top 10% may
actually produce less code, because most of their time will be
used improving the productivity of the other programmers. (And
what makes a programmer "exceptional", or in the top 10%, is the
fact that his presence improves the productivity of everyone
else on the team.)
Yannick Tremblay
JustBoo <B...@boowho.com> wrote:
>James Kanze wrote:
>> What I'd really be interesting in seeing is a real life example
>> of a real program written by a single person which is considered
>> correct, with a statement as to what is considered correct or
>> how it is known to be correct.
>
>Bjarne Stroustrup developing a "program" (note the quotes) called C++?
I don't think he was alone at it although he was the main author for
the original version. Then a lot of peoples tried it and suggested
improvements to it... and now we are at C++0x...
>Linus Torvalds creating the Linux kernel?
Torvalds took inspiration from UNIX. He initially wrote what we
should call an alpha version of a kernel and it certainly was not
correct as in totally bug-free. The several additional contributors
help improve Torvalds early work.
JustBoo
> In article <GRI9m.54005$9P.4...@newsfe08.iad>,
> JustBoo <B...@boowho.com> wrote:
>> James Kanze wrote:
>>> What I'd really be interesting in seeing is a real life example
>>> of a real program written by a single person which is considered
>>> correct, with a statement as to what is considered correct or
>>> how it is known to be correct.
>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>
> I don't think he was alone at it although he was the main author for
> the original version. Then a lot of peoples tried it and suggested
> improvements to it... and now we are at C++0x...
From what I've read, in the beginning and well into the development, he
was alone. Remember all this was new. What's that old saying (probably
paraphrasing here): "Failure is an orphan, where success has many
fathers." It has many fathers *now*. Back then C++ was not a certain
success.
But I�m not �picking this hill to die on.� Take care.
fft1976
> On Jul 23, 7:05 pm, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 23, 2:24 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
> > > > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > > > ...
> > > > Good programmers are 100x more productive than average
> > > > ones, especially on hard problems, as I'm sure you know.
> > > "Average" programmers (whatever that means) are good
> > > programmers.
> > I should have said "median". Because of the long tail in the
> > productivity distribution, "average" are indeed "good", or at
> > least "half as good". The point is the productivity difference
> > between a regular programmer and someone in the top 10% or so
> > can be 2 orders of magnitude.
>
> Not really. Not in terms of code, anyway, and not in a well
> managed environment. If the environment is correctly managed,
> in fact, the one or two programmers you have in the top 10% may
> actually produce less code, because most of their time will be
> used improving the productivity of the other programmers. (And
> what makes a programmer "exceptional", or in the top 10%, is the
> fact that his presence improves the productivity of everyone
> else on the team.)
>
Maybe you've never worked with anyone good or on problems where being
good mattered?
Noah Roberts
> In article <GRI9m.54005$9P.4...@newsfe08.iad>,
> JustBoo <B...@boowho.com> wrote:
>> James Kanze wrote:
>>> What I'd really be interesting in seeing is a real life example
>>> of a real program written by a single person which is considered
>>> correct, with a statement as to what is considered correct or
>>> how it is known to be correct.
>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>
> I don't think he was alone at it although he was the main author for
> the original version. Then a lot of peoples tried it and suggested
> improvements to it... and now we are at C++0x...
C++1x you mean :P
Pete Becker
No, C++0x. C++1x is at least five years out.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Ian Collins
> Noah Roberts wrote:
>> Yannick Tremblay wrote:
>>> In article <GRI9m.54005$9P.4...@newsfe08.iad>,
>>> JustBoo <B...@boowho.com> wrote:
>>>> James Kanze wrote:
>>>>> What I'd really be interesting in seeing is a real life example
>>>>> of a real program written by a single person which is considered
>>>>> correct, with a statement as to what is considered correct or
>>>>> how it is known to be correct.
>>>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>>>
>>> I don't think he was alone at it although he was the main author for
>>> the original version. Then a lot of peoples tried it and suggested
>>> improvements to it... and now we are at C++0x...
>>
>> C++1x you mean :P
>
> No, C++0x. C++1x is at least five years out.
Do you expect C++0x to be ratified this year?
--
Ian Collins
Pete Becker
Next year.
Ian Collins
> Ian Collins wrote:
>> Pete Becker wrote:
>>> Noah Roberts wrote:
>>>> Yannick Tremblay wrote:
>>>>> In article <GRI9m.54005$9P.4...@newsfe08.iad>,
>>>>> JustBoo <B...@boowho.com> wrote:
>>>>>> James Kanze wrote:
>>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>>> of a real program written by a single person which is considered
>>>>>>> correct, with a statement as to what is considered correct or
>>>>>>> how it is known to be correct.
>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called
>>>>>> C++?
>>>>>
>>>>> I don't think he was alone at it although he was the main author for
>>>>> the original version. Then a lot of peoples tried it and suggested
>>>>> improvements to it... and now we are at C++0x...
>>>>
>>>> C++1x you mean :P
>>>
>>> No, C++0x. C++1x is at least five years out.
>>
>> Do you expect C++0x to be ratified this year?
>>
>
> Next year.
>
--
Ian Collins
James Kanze
I've worked on critical systems, where everything had to work.
I've worked with a lot of good people, and some exceptional
ones.
More likely you've never worked in an environment designed to
produce good software. More likely you don't know how to judge
good. Although I've seen a few exceptions, most professional
programmers are competent, and the cases I've seen where they're
not productive, it's been because management has prevented them
from being productive. Sometimes, simply by letting a few
snotty brats who think that they're the only ones who know
anything run things.
Ian Collins
>
> More likely you've never worked in an environment designed to
> produce good software. More likely you don't know how to judge
> good. Although I've seen a few exceptions, most professional
> programmers are competent, and the cases I've seen where they're
> not productive, it's been because management has prevented them
> from being productive. Sometimes, simply by letting a few
> snotty brats who think that they're the only ones who know
> anything run things.
Or marketing types who think they know how to develop software!
I think more professional programmers succeed despite rather than
because of their management.
--
Ian Collins
Bo Persson
See, you solved the equation. :-)
Seriously, there are already some work in progress for the real
C++1x - originally aiming at C++15. We will have to see if we get 0xA
or 0xB, before we know if C++15 is possible. I believe ISO wants a
minimum of 5 years between revisions (not a problem so far :-).
Bo Persson
Pete Becker
Yup. It's still the project that started in 2003. The name hasn't been
changed.
Brian Wood
One reason I started a company was to get away from the
groupthink/immaturity that is pervasive in companies today.
I read the hand writing on the wall in the 1990s and didn't
feel I had a choice. The company was born out of necessity
more than than it being a goal of some sort. Now I view it
as a move parallel to the pilgrims who left Europe on the
Mayflower and some other ships. They didn't have it easy,
but they were successful in producing humbler management
for themselves in America. That worked for awhile, but
lately we've not been getting much out of our "leaders."
Brian Wood
>
> One reason I started a company was to get away from the
> groupthink/immaturity that is pervasive in companies today.
> I read the hand writing on the wall in the 1990s and didn't
> feel I had a choice. The company was born out of necessity
> more than than it being a goal of some sort. Now I view it
> as a move parallel to the pilgrims who left Europe on the
> Mayflower and some other ships. They didn't have it easy,
> but they were successful in producing humbler management
> for themselves in America. That worked for awhile, but
> lately we've not been getting much out of our "leaders."
>
Here's a few headlines from July 25, 2009
http://wnd.com
Analyst says Obama will change healthcare plan
'The president hates one thing more than anything else – losing'
GOP not allowed to say 'government-run health care'
Communications with constituents that use phrase lose franking
privilege
James Kanze
I don't think a professional programmer can succeed without good
management, regardless of how good he is. Programming is a team
effort---one person, working alone, cannot produce good code.
And it takes management to organize the team. (Note that in
some cases, particularly in smaller projects or organizations,
the "manager" may also be part of the team.)
Ian Collins
> On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> More likely you've never worked in an environment designed
>>> to produce good software. More likely you don't know how to
>>> judge good. Although I've seen a few exceptions, most
>>> professional programmers are competent, and the cases I've
>>> seen where they're not productive, it's been because
>>> management has prevented them from being productive.
>>> Sometimes, simply by letting a few snotty brats who think
>>> that they're the only ones who know anything run things.
>
>> Or marketing types who think they know how to develop software!
>
>> I think more professional programmers succeed despite rather
>> than because of their management.
>
> I don't think a professional programmer can succeed without good
> management, regardless of how good he is. Programming is a team
> effort---one person, working alone, cannot produce good code.
I still find that statement rather offensive. I done a lot of solo
projects for several clients in various corners of the globe over the
past decade and I've produced plenty of what I still consider to be very
good code.
> And it takes management to organize the team. (Note that in
> some cases, particularly in smaller projects or organizations,
> the "manager" may also be part of the team.)
Team management is often excellent, it's those who climb higher up the
greasy pole who loose the plot.
--
Ian Collins
dsims
> 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.
If you are new to managing, right now you are being tested by your
subordinates. If someone is not doing what you say ask why they
didn't. But their are many ways to ask this question. The attitude you
broadcast will be returned three times fold.
How are your communication skills? Do you listen to what your are
saying to others? Communication is key. If you walk in others shoes
you will climb mountains.
Obviously you have been managed before,
Who were your best managers and who were your worst?
Which managers made you feel appreciated?
What qualities did they possess to accomplish this feeling of
appreciation?
Do you still talk to these managers?
How is your attitude?
Are you humble and appreciative or demanding and condescending?
Is their a common activity that you can do as a group. Make a game
night or something to that effect.
Richard Herring
<827d8b9d-ef49-4490...@g6g2000vbr.googlegroups.com>,
Brian Wood <co...@mailvault.com> writes
Did you have a question about C++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12
--
Richard Herring
Andrew Tomazos
> I don't think a professional programmer can succeed without good
> management, regardless of how good he is. Programming is a team
> effort---one person, working alone, cannot produce good code.
That is completely incorrect. I have personally seen a 400k line
codebase that was written largely by one person that was (and maybe
its latest versions still is) used by nearly a million people with
minimal marketing. The programmer had never heard of version control
and thumbed his nose at object-oriented programming. There are
countless examples of great pieces of software written by one person.
Programming does not have to be a team effort, anymore than writing a
book needs to be a team effort.
-Andrew.
James Kanze
> James Kanze wrote:
> > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >>> More likely you've never worked in an environment designed
> >>> to produce good software. More likely you don't know how
> >>> to judge good. Although I've seen a few exceptions, most
> >>> professional programmers are competent, and the cases I've
> >>> seen where they're not productive, it's been because
> >>> management has prevented them from being productive.
> >>> Sometimes, simply by letting a few snotty brats who think
> >>> that they're the only ones who know anything run things.
> >> Or marketing types who think they know how to develop software!
> >> I think more professional programmers succeed despite rather
> >> than because of their management.
> > I don't think a professional programmer can succeed without
> > good management, regardless of how good he is. Programming
> > is a team effort---one person, working alone, cannot produce
> > good code.
> I still find that statement rather offensive. I done a lot of
> solo projects for several clients in various corners of the
> globe over the past decade and I've produced plenty of what I
> still consider to be very good code.
It's not offensive, it's a fact of life. I've done a lot of
solo work in the past, as well. Before the importance of
teamwork was fully recognized everywhere. At the time, I
considered the code "very good". And it was, compared to, say,
what other people working alone were producing. But in the last
large project I did that way, the integration and test team
still found four errors. For about 40 KLOC---that's one error
per 10 thousand lines of code. Where as I've seen programmers
who I'd consider considerably less skilled than I produce code
with only one error per 100 KLOC, thanks to things like code
review and such. Today, I simply cannot meet the standards I
set for myself (and others) without help from others.
> > And it takes management to organize the team. (Note that in
> > some cases, particularly in smaller projects or organizations,
> > the "manager" may also be part of the team.)
> Team management is often excellent, it's those who climb
> higher up the greasy pole who loose the plot.
I've seen that, too. One of the reasons smaller organizations
are often more successful than larger ones is that "management"
always wears several hats, including some which involve
programming as well, and so don't loose touch with reality.
James Kanze
> On Jul 26, 9:44 am, James Kanze <james.ka...@gmail.com> wrote:
> > I don't think a professional programmer can succeed without
> > good management, regardless of how good he is. Programming
> > is a team effort---one person, working alone, cannot produce
> > good code.
> That is completely incorrect.
I'm sorry, but it's a proven fact.
> I have personally seen a 400k line codebase that was written
> largely by one person that was (and maybe its latest versions
> still is) used by nearly a million people with minimal
> marketing.
And? A lot of people are using a lot of junk. Note that
working in a team is a necessary condition, but not necessarily
a sufficient one. A lot of junk has been produced by large
teams as well. And the fact that a large number of people use
something is no proof of quality---consider Windows for example
(or Linux---but there are a lot less people using it).
> The programmer had never heard of version control and thumbed
> his nose at object-oriented programming. There are countless
> examples of great pieces of software written by one person.
For example?
Andrew Tomazos
> > I have personally seen a 400k line codebase that was written
> > largely by one person that was (and maybe its latest versions
> > still is) used by nearly a million people with minimal
> > marketing.
>
> And? A lot of people are using a lot of junk.
The software in question won numerous high profile awards in the face
of competition, and people described themselves as "huge fans" of it.
It was noted not only for its nice user interface, but for its amazing
robustness. It was most certainly good software. Its existence
disproves your statement.
Try and figure out why you are wrong, and how it is possible for one
programmer with an informal process to write good software. I know
it's a spanner in the works for all those precious Software
Engineering Process textbooks that are prescribed at universities -
but I'm afraid it is real. Deal with it.
It has been known for some time that good programmers can be 100x
effective than average ones. This is based on empirical evidence, as
demonstrated by the existence of programs like the one descirbed
above. There have been various theories put forth for why this is the
case, but the truth is noone has really figured out why.
Why do some novelists write bestsellers, while the majority write
flops? Why do some mathematicians and physicians think up
groundbreaking theories, while the majority just regurgitate and
rearrange existing knowledge? Who knows.
-Andrew.