From: arne@vajhoej.dk
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.
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.
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.
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.
Depending on the personality it will end in:
* laughing
* crying
* cursing
* writing to TheDailyWtf
Useless.
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"
> 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.
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.
> 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?
Arne
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
