From: blockedofcourse@foo.invalid   
      
   On 11/26/2025 8:01 PM, Edward Rawde wrote:   
   >>>>> There's also a difference between what is taught and what is needed in a   
   workplace.   
   >>>>> I could use a soldering iron when I got my degree, but most other   
   graduates couldn't.   
   >>>>   
   >>>> I disagree.  Skills are easy to pick up -- how long do you think it would   
   take   
   >>>> to teach someone how to make a reliable solder joint?   
   >>>   
   >>> As far as making a reliable solder joint is concerned I've seen many   
   outcomes.   
   >>> This is from prototype testing not production.   
   >>> Here are some possible outcomes.   
   >>>   
   >>> 1. Perfect joint.   
   >>>   
   >>> 2. Perfect joint after being shown that keeping your wrist on the bench   
   while you   
   >>> make the joint will keep your hand steady.   
   >>>   
   >>> 3. Good effort but here's how to remove grime and oxide film from the   
   resistor's   
   >>> legs before you solder it.   
   >>>   
   >>> 4. Deliberately poor joint because "I shouldn't have to do this".   
   >>   
   >> So, put a number on how many HOURS it would take you to learn this.   
   >> Then, decide which hours of coursework you would forego to learn   
   >> this skill in school.   
   >   
   > None.   
      
   You'd forego none of them?  Or, wouldn't NEED to forego them because   
   you already had the skillset?   
      
   Would you have wanted to learn how to punch Hollerith cards in school?   
   Or, learn JCL?  Or, programming language foo?   
      
   These are all just *skills*.  They don't require hand-holding to acquire.   
   OTOH, learning how a group of actives and discretes come together to   
   provide a particular function -- and WHY -- is likely not something   
   that you can pick up *efficiently* on your own.  That deficiency would   
   be a burden to a future employer.   
      
   > But plenty of present day students seem to have to have a job as well as   
   school.   
   > In my case I did partially have a job while at school because although my   
   father didn't   
   > specifically offer equipment repair to people off the street, I would often   
   find a   
   > non functional piece of electronics waiting for me to find out what was   
   wrong with it.   
   >   
   >>   And, your strategy for picking up that material   
   >> in the workplace?   
   >>   
   >> I can't think of any course that I would have sacrificed to learn   
   >> some skill that I could pick up in OJT.  A colleague at an IBM division   
   >> that I was working with showed me the important aspects of wirewrapping   
   >> as it was directly applicable to the system I was troubleshooting for them.   
   >> And, pointed me at some of the better tools available that I would later   
   >> use (having purchased them for myself) to do that sort of work.   
   >>   
   >> I doubt I would have found such a person who would have sat down and   
   >> taught me about the architecture of a B5500.  Or, the A* algorithm.   
   >> Likely, none of the folks I've worked with KNOW these things!   
      
   >> The "DRAW" opcode in my first processor implemented the following:   
   >>    ; scale the (dX,dY) vector by the associated scale factors (Ax, Ay)   
   >>    x = Ax * dX   
   >>    y = Ay * dY   
   >>   
   >>    ; determine how much each axis can be scaled up to fit under its limit   
   >>    Bx = Kx / x   
   >>    By = Ky / y   
   >>   
   >>    ; find minimum of those factors (ensures neither will exceed its limit)   
   >>    G = min(Bx,By)   
   >>   
   >>    ; scale the "scaled vector" to approach each appropriate limit   
   >>    Ox = G * x   
   >>    Oy = G * y   
   >>   
   >>    ; reduce time by an equivalent factor   
   >>    T = Kt / G   
   >> in just under 2 microseconds.  In ~1980.   
   >>   
   >> Had I not been exposed to the B5500 et al., I would have implemented this   
   >> in a more traditional, serial manner achieving perhaps 5% of the overall   
   >> performance -- instead of having multiple pipeline stages to increase   
   >> throughput!  And, no one would have thought to tell me about the   
   optimizations   
   >> that I could have made in the hardware "from historical perspective".   
   >   
   > I can remember picking up plenty from magazines. Including the cordic   
   algorithm.   
   > Sorting out useful information from nonsense seems to be harder on the   
   Internet.   
      
   Individuals are "noise" in the discussion.  You have to approach the problem   
   as a gestalt to posit a viable "solution"/explanation.   
      
   Should we mandate that students read plenty of magazines?  Which ones?  How   
   sure are you of their applicability to a particular career choice that has yet   
   to be voiced?   
      
   >>>> We teach kids how to design algorithms using a completely bogus   
   "programming   
   >>>> language" that exists nowhere else.  A handful of "opcodes" (move l/r/f/b,   
   >>>> probe, rotate 90/180/270, etc.) that a 10 year old can easily understand   
   >>>> (no concerns about overflow, exceptions, cancellation, races, etc.).  And,   
   >>>> to which he can PHYSICALLY relate.   
   >>>   
   >>> Well you don't seem to be able to buy a simple SC/MP board and solder it   
   >>> together yourself any more.   
   >>   
   >> Because folks have opted to buy "added value" from others.  I am always   
   amused   
   >> at the rationale:  "So, we won't have to design a PCB!"  (Really?  That   
   >> purchased board won't be a daughter card on some OTHER card THAT YOU   
   DESIGN??   
   >> What are you going to do when the supplier makes some change to some aspect   
   >> of the subassembly -- particularly, the software?)   
   >>   
   >> Note that the market for EEs pays considerably less than software engineers   
   >> so *it* has decided where the value added lies.  How many designs benefit   
   from   
   >> all those "mother/daughter cards" designed by a handful of EEs?   
   >   
   > I've had to rewrite a few software messes so that they actually worked with   
   the hardware.   
      
   I got a call from an old client, one time.  A machine I had automated was   
   "hung".  TL;DR one of the motorized carriages would run into a limit and   
   then stick there.   
      
   Superficially, the stopping made sense -- you want to inhibit motion BEYOND the   
   limit switch as failing to do so would cause tens of thousands of dollars of   
   damage in an OhNoSecond.   
      
   But, when commanded to reverse direction (to move OUT of the limit condition)   
   the mechanism just flashed an error.   
      
   [Of course, client failed to chase down the ACTUAL error being signaled and   
   assumed it pertained to being in the mechanism's limit of motion]   
      
   [I'd had an argument with the hardware guy, back then, regarding his choice   
   of how the switches should have been wired -- he naively assumed "switch   
   closed when actuated".  I had to fight him to get him to realize that such a   
   use would cause an ABSENT switch to NEVER signal a limiting condition!   
   By contrast, "switch open when actuated" would effectively appear as a   
   permanent limit condition when the assembly was disconnected or faulty.   
   he tried to defend his inferior solution by blaming any such future   
   problems on whomever could conceivably have serviced the unit.]   
      
   Instead of a naive "inhibit-motion-in-the-called-for-direction-if-the-   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)