From: cross@spitfire.i.gajendra.net
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. 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.
Similarly, see https://man.omnios.org/man7/style.7, which
describes in some detail the level of C proficiency expected for
working in a System V-based kernel.
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.
There was a companion "C++ primer" document that Google
published internally for C++ programmers, but I don't know
whether that was published externally; I can't find a copy. It
was one of two places where I actually used troff in my time
working there.
>> So the way that I write software is likely to be far different
>> between projects/teams and across organizations. If I am
>> working on a project where excellence is the norm, then
>> parenthesizing every boolean expression is going to be tedious
>> and actually slow folks down; if I'm assuming all new-grads,
>> less so.
>
>You could also state this initial target audience in the above document.
Agreed. Whatever convention one uses (whether a file in the
project itself, or some kind of external thing) documentation is
key.
>PS: I'm actually serious about this. _You_, as the original team or
>person to create a project, then get to set what is expected before
>someone later on starts work on the project.
>
>This stops that future person from having to guess what skills are
>required and then finding out the hard way that they are in way over
>their heads. It also avoids having to ask the questions you are
>asking here.
I absolutely agree. I do think that style guides provide some
basis here, but those tend to be implicit. Explicit statements
can be very useful.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
