Re: GNUism in groff tests, was: pic anomalies

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Fri, Jan 03, 2020 at 04:35:52PM +1100:

> Right.  I've started to adopt the philosophy that _especially_ for
> critical stuff, a senior engineer should not be writing an
> implementation--he or se should be producing a spec, which junior
> engineers then implement.
> 
> A senior should also, of course, participating in code reviews and
> helping out with validation and verification.
> 
> But the Thing-Itself-Which-Is-To-Be-Maintained?  The senior should not
> be directly touching that at all.  If there's a stumper of a problem,
> the senior should be working alongside the juniors to solve it.  But the
> keystrokes and commits to resolve the issue should belong to those
> juniors.
> 
> This, I believe, is how expertise is built and transmitted in a
> collaborative environment.

This seems excessively strict to me.  Yes, i know rms@ is no longer
writing much new code nowadays.  But it's not like that in all
communities.  For example, in OpenBSD, the most senior engineers
(like Theo de Raadt, Marc Espie, Mark Kettenis, David Gwynne, Kenneth
Westerback, ...) are writing a lot of code all the time.  It is not
holding back the youngest engineers (like Klemens Nanni, Scott
Cheloha, Theo Buehler, Anton Lindqvist, Martijn van Duren, ...)
from contributing and growing, often collaborating on exactly the
same regions of the code and the same projects, and inspiring them.
Heck, for the vast majority of active developers, i wouldn't even
be able to decide whether they are "juniors" or "seniors".  Of
course everybody (including juniors) participates in code review,
and the seniors do not behave like rockstar code cowboys.  In fact,
the seniors are among the most zealous when it comes to reviewing
and polishing legacy codebases.

So it doesn't have to be the way you describe, even though i agree
it is like that in most places.

Incidentally, the worst rockstar code cowboy i ever had to deal
with in the industy was quite a young man (oops - i almost mentioned
the name; he also contributed marginally to some free software
projects).  So it's more a matter of the attitude of project members
and the climate in the project/company than of seniority.

Consequently, i wouldn't object at all to Doug writing some come
for groff, if he wanted to.  ;-)

> What is stopping us?
> I'm tempted to say "engineering managers" but I suspect that is
> painting with too broad a brush.

Of course that brush is broad; there are some individual managers
who have more and some who have less of a conscience (and of technical
competence).  But it's not so far off the mark in so far as you
*can* regard "management" as the personification of the *structural*
effects that are actually causing the problem.  As long as society
is organized around making profit and around owning personal property
rather than around sutainablity and cooperation, many consumers
will be forced to look more closely at the price tag than at the
quality (if they even manage to get the education to understand
what the latter is - chances are their education already taught
them to hurry and scramble more than anything else), and producers
will suffer from a pressure to get some results (or too often: any
results whatsoever) as fast as possible to sell them and start
making money.

Hom much does spending the last 90% of work to get the last 10% of
quality contribute to the success of an *average* company, really,
on current markets?

The fact that *you* would be willing to buy the considerably more
expensive product due to its quality doesn't really matter, on
the scale of society as a whole.

Anyway, in a project like groff, we do have the freedom to review
and polish legacy code, to build unit tests if we want to, and to
develop new features in a sustainable way...

Yours,
  Ingo