Young hires are left to flounder on their own while still being expected to be highly productive a day after graduation.
Did you read Jack Ganssle's recent "Embedded.com" column on Apprentiships? As part of this piece, Jack mentioned that – in the not-so-distant past – junior engineers coming out of college to start their first real-world job were teamed with more experienced engineers who acted as mentors. Jack also mentioned that there's been a decline of this mentoring concept due to cutbacks, with the result that young hires are left to flounder on their own while still being expected to be highly productive a day after graduation.
Reading this article took me back through the mists of time (just imagine that the image on your screen is wobbling a little bit to get into the mood of things). When I graduated with my B.Sc. in Control Engineering in 1980, my first job was at International Computers Limited (ICL) in Manchester, England. At that time, I was inducted as a member of a team designing CPUs for mainframe computers. We were working with CMOS ASICs from Fujitsu (I think they each contained around 2,000 equivalent logic gates and were at the 5 um process node, which was pretty hot technology for the time).
Of course we didn't have any EDA tools. We designed at the gate-level with hand-drawn schematics. Timing analysis was done with a pencil and paper and layout (place-and-route) was all done by hand – Ah, the good old days.
But we digress. . . The point of all of this is that ICL was strongly into mentoring. Each new engineer was put under the "wing" of a more-experienced engineer. My mentor was a guy called Dave Potts and he did a fantastic job. Rather than dump a huge design task on me in its entirety, he would feed it to me one (manageable) piece at a time.
If I had to design a barrel shifter, for example, he would say something like: "OK, you have a 64-bit word to be shifted left or right by anywhere from 0 to 64 bits in a single clock cycle and you're going to split this across eight identical chips each of which will be responsible for 8 of the output bits."
So I'd wander off into my cubical and beaver away designing my ASIC and eventually come up with a design which Dave would check. Then he'd say something like: "Oh dear, I forgot to mention that the shifter needs to be able to perform both arithmetic and logical shifts," and he'd explain what he was looking for and I'd trot off and add this new functionality.
When I returned with my new offering, Dave would say something like : "This is looking good, but I just remembered that we need the option to shift the entire input word as one 64-bit value, or as two 32-bit values, or as four 16-bit values, or . . ." And, once I had this working, Dave would continue: "Also, we need to be able to do different things with binary values versus BCD values. . ."
And so it went. If Dave had dumped the entire specification on my desk on the first day, I would have been totally overwhelmed. Instead, the way he layered the specification allowed me to wrap my brain around things much more easily and gave me much more confidence in myself.
So, for myself, I think it's a real shame when young graduates are simply thrown in at the deep end and told to sink or swim. Quite apart from the tremendous pressure on them, I think that folks become much more productive much faster when a mentoring program is in place, so cutting back on this sort of thing is a false saving.
This is just my "2 cents" – what do you think?
Questions? Comments? Feel free to email me – Clive "Max" Maxfield – at email@example.com). And, of course, if you haven't already done so, don't forget to Sign Up for our weekly Programmable Logic DesignLine Newsletter.