From: cross@spitfire.i.gajendra.net   
      
   In article <108ssrb$24jsc$7@dont-email.me>,   
   Simon Clubley   wrote:   
   >On 2025-08-29, Dan Cross  wrote:   
   >>   
   >> Which again, comes back to what I think is _actually_ the   
   >> interesting question: who do we write these programs for?   
   >   
   >You write them for the people who come after you who have to   
   >maintain and extend them. People who have a good understanding   
   >of the language but may have your level of expertise/knowledge/skills.   
   >   
   >You write them for the people who understand most of the algorithms   
   >involved, but maybe not at the level you do.   
   >   
   >You also write them for yourself a couple of years from now and who   
   >is now looking at this code written a couple of years ago and is now   
   >wondering which &*%&^% idiot wrote this code like this in the first   
   >place :-)   
      
   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?   
      
   E.g., am I writing assuming a new-grad with almost no industry   
   experience and under-developed programming proficiency?  Do I   
   assume your typical application developer who does CRUD-backed   
   web sites/business applications? Published researchers with deep   
   domain expertise but only research-quality programming   
   experience?  Sophisticated systems programmers who regularly   
   work on kernels and compilers?  PhD level computer scientists   
   with extensive non-research programming experience?   
      
   The way I write code, and the level of proficiency I expect with   
   specific tools, is going to be qualitatively different when   
   working with any of these groups.  I've spent the bulk of my   
   career working with the last two groups I mentioned above, and I   
   will rightly expect a much higher level of expertise, rigor, and   
   programming sophistication and quality from them than I will   
   from new grads.  Similarly with researchers: I'll expect them to   
   _know_ more in absolute terms, but they have very different   
   pressures and constraints, so their code will likely be of lower   
   overall quality.  My experience is that the application people   
   working on business/CRUD programs have the widest skills   
   variation between individuals.   
      
   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.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)