[OT] dealing with lower level programmers

[James Kanze]

Maybe you've never worked with anyone good or on problems
where being good mattered?

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.

 

[Bo Persson]

Ah, so x = 10!

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

 

[Brian Wood]

Or marketing types who think they know how to develop software!

I think more professional programmers succeed despite rather than
because of their management.

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
Ebenezer Enterprises
www.webEbenezer.net

 

[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


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[James Kanze]

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

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.

 

[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]

In message

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

Did you have a question about C++?

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

 

[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]

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.

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]

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]

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.

 

[Pascal J. Bourguignon]

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.

Interesting. While the bug count indeed must be reduced, I wouldn't
say that's the most important factor of code quality. I would put
code maintainability first.

But anyways, your example doesn't involves more than one programmer.
It's good to have testers. And perhaps other kinds of people in a team
around a programmer.

That's basically what is advocated in The Mythical Man Month actually.

 

[Stefan Ram]

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?

You might try to ask the programmers what they /have/ done in
the past and what they /can/ do well and then assign them to
tasks based on this.

The number of years on the job might have little meaning in
this regard. For example, an excellent programmer of software
for engine control or database reports might never have heard
of »MVC«.

Maybe they are not »lower level programmers« at all, but
»subordinate programmers«?

See also:

http://codeofdoom.com/wordpress/2009/03/16/dont-let-junior-programmers-cowboy-code/

 

[Brian Wood]

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.


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.

Losing touch with reality is a common problem and in my opinion
one solution is starting a company. "If you can't join em,
beat em." That's what the pilgrims did. They created a better
country than the countries they left --
http://webEbenezer.net/comparison.html


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Keith H Duggar]

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.

Why aren't you naming this "software in question"? Are you
hiding something?

KHD

 

[Keith H Duggar]

Yup. It's still the project that started in 2003. The name hasn't been
changed.

It seems Stroustrup diasgrees with you. Below is a quote from

http://www.ddj.com/cpp/218600111

"Even after cutting "concepts," the next C++ standard may be delayed.
Sadly, there will be no C++0x (unless you count the minor corrections
in C++03). We must wait for C++1x, and hope that 'x' will be a low
digit. There is hope because C++1x is now feature complete (excepting
the possibility of some national standards bodies effectively
insisting on some feature present in the formal proposal for the
standard). "All" that is left is the massive work of resolving
outstanding technical issues and comments." - Bjarne Stroustrup

So if I read that right, he refers to standards by the
year of ratification (or expected ratification) not by
the year work starts. That also explains why everyone
was referring to it as C++0x and not C++03 (which would
be consistent with your explanation).

KHD

 

[Keith H Duggar]

The project is C++0x, and will continue to be.

That's very informative, thank you. I was under the impression
it was just an unofficial name. Tell me, where on what page does
"C++0x" appear in the latest working draft?

KHD

 

[Andrew Tomazos]

Why aren't you naming this "software in question"? Are you
hiding something?

Yes - but nothing that effects the validity of the point.
-Andrew.