From: cross@spitfire.i.gajendra.net

In article <68bb6904$0$710$14726298@news.sunsite.dk>,
Arne Vajhøj   wrote:
>On 9/2/2025 9:35 AM, Dan Cross wrote:
>> In article <10943ve$3r9go$1@dont-email.me>,
>> Simon Clubley   wrote:
>>> On 2025-08-29, Dan Cross  wrote:
>>>> This is all true.  I think one might paraphrase this as meaning
>>>> that you write code for the programmer that is slightly below
>>>> the median, and only hire engineers at median level or higher.
>>>>
>>>> But this is slightly different than what I meant, which might be
>>>> similarly reframed as asking, how does one figure out what
>>>> "median" means?  What is the base level of competence one might
>>>> assume when working on any given project/codebase/etc?
>>>>
>>>> For instance, this demonstrably differs between organizations; I
>>>> would argue it often varies across projects within an
>>>> organization as well, and probably even within a project as the
>>>> project evolves over time.  So how does one calibrate the median
>>>> point to which one targets ones programming standards, and how
>>>> does one ensure that it remains applicable?
>>>
>>> You could always create a "!!!Change_Skills_Required.README" in the
>>> project (or subproject) root directory, stating with specific detail
>>> what skills, knowledge, and experience level, are required before
>>> it is appropriate for someone examining the project to start work
>>> on it. Include references to appropriate papers or tutorial and
>>> background material. Include the actual material in a references/
>>> directory tree if appropriate.
>>>
>>> Also include contact details for advice when they get stuck. Try to
>>> list departments or teams instead of specific people if possible.
>>> People change roles much more quickly that the overall team or
>>> department does.
>>
>> This all seems reasonable.
>
>Horrible idea.

Style guides and documentation are a horrible idea?

>It works fine as long as original team is around and the language
>used is still a main language in the company.
>
>But a lot of software stay around for a very long time. 20 years,
>30 years, 40 years.
>
>Employees and skills does not.
>
>Companies merge and spinoff. Developers get new jobs. Main
>languages are changed.

That's all orthogonal to Simon's suggestion.

>And suddenly there is a need to make a fix or an enhancement in that
>old program (which may still be making lot of money). And none from
>the original team is around and the language is no longer a main
>language so no real experts in that language around  any more.

Yes, so that's why you document and have standards.

>Some developer get assigned to do the fix/enhancement and start by
>finding the "You need to be an expert in this language and if you
>have questions ask A or B" file.

A or B is a team or project.  References are available for
languages.  Something that outlines the expectations seems
reasonable to me.

>Depending on the personality it will end in:
>* laughing
>* crying
>* cursing
>* writing to TheDailyWtf
>
>Useless.

What are you talking about?  Did you even read what you're
responding to?

>There is an old joke with a very good point:
>
>"Always code as if the guy who will maintain your code is a violent
>psychopath who knows where you live"

Well then, I'd better try to keep him happy by writing code that
is consistent with the local style and documenting how to
approach the code base.

>>                       I would go a bit further and suggest
>> that this is largely what style guides _should_ provide.  For
>> instance, see the Google C++ style guide, which is extremely
>> detailed: https://google.github.io/styleguide/cppguide.html
>> All engineers working in C++ at Google are expected to read and
>> internalize these rules, and a side-effect of the level of
>> detail expressed in them is that they do a reasonable job of
>> outlining the level of expertise expected of those programmers.
>
>That works great in current situation.
>
>But what if Google sell the product in 15 years due to some
>corporate restructuring. The buying company will not adopt
>that guide.

Wow.  Have you ever actually worked on a project that was
acquired from some organization?  You really think they throw
out all the documentation and just start doing their own thing
on a >>1MLOC code base?

>What if Google in 20 years decode to drop C++ as a main
>language and drop the guide. Maybe not likely with that
>company and that language, but in general companies change
>preferred languages occasionally.

Now we're back to "what ifs" and the associated risks that you
were so quick to dismiss in another thread.  Bluntly: much as
Google _would_ actually like to dump C++, what you are
describing just isn't going to happen.

What happened to all the senior management mandates that you
said made this problem so easy?

>> Google also scatters "OWNERS" files throughout the monorepo;
>> this is mainly for the vectoring code reviews (a review from an
>> OWNER is required for integration), but also gives a good
>> pointer to a team of folks who can help with any given project.
>
>Now. How many of them will be in the company in 25 years and
>still remember anything?

OWNERS files were maintained via automated crawlers that made
sure they were up to date; if an OWNERS file became empty, the
issue was escalated to the OWNERS of the enclosing project.
Eventually you are at the root of the monorepo.

It's amazing how automation and a strong engineering culture can
address these strawman concerns.

	- Dan C.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)