As soon as I penned the title to this column, the tune to Where Have All the Flowers Gone? by Pete Seeger and Joe Hickerson popped into my mind, where it’s been playing in a loop ever since, but as usual I’m wandering off into the weeds and we haven’t even started yet…
I just received an email from a young engineer that made me feel rather sad, but that reminded me how lucky I was when I started out my career in engineering. Maybe we can offer this youngster some advice…
Let’s start with the original message, which reads as follows (note that I’ve edited this a little in order to protect her/his identity):
Hello Max. My name is ###### ###### and I am fan of you and your writing. I purchased your Design Warriors Guides to FPGAs while I was in school and found it very informative. I am writing to you because I am a young engineer in need of advice. I currently work as an ASIC/FPGA engineer at a large aerospace firm in ######.
My problem is that I am lacking the guidance I need from senior engineers to truly learn the discipline well. I find myself frequently getting stuck and staying stuck for much of the day because senior personnel are too busy to help. I ultimately resolve my issues, but I feel like I am not learning the trade very well.
I am very interested in knowing what it takes to become good at this. I believe that I am capable and bright, but I lack the coaching. Many of the senior engineers had great mentors that they shadowed and they learned the trade very well, so it’s puzzling to me why that sort of system is practically nonexistent these days.
I was thinking about enrolling in professional training courses but they are costly. I would appreciate any words of wisdom! Regards, ###### ######
As I say, this made me feel very sad. It’s horrible to be dropped in at the deep end, to not know which way to turn, and to not have anyone to ask questions and bounce ideas off. It also reminded me as to how lucky I was when I started my own career. I can’t help myself… join me if you will on a brief trip down memory lane…
------ Start of trip down memory lane ------
After graduating with a B.Sc. in Control Engineering in the summer of 1980, my first position (“Look Mom, a real job!”) was with International Computers Limited (ICL) in Manchester, England. At that time, ICL made honking big mainframe computers and I was hired as a member of one of their Central Processing Unit (CPU) design teams.
It didn’t take me long to discover that little of what I’d studied at college had much bearing on my new job. I also quickly realized that tasks that had appeared easy in the classroom (when the lecturer was doing the bulk of the work) were somewhat trickier when you had to do them in earnest. Fortunately, ICL had a really good policy whereby junior engineers like me were partnered with more experienced team leaders. I was lucky in this regard to be assigned a mentor called Dave Potts, who taught me far more than I’m sure he ever realized. Working under Dave was somewhat frustrating, however, in that he would never answer even the simplest question directly; for example:
Max:Hey Dave, what time is it?
Dave:Where is the sun in the sky? Which way is the wind blowing? On what side of the tree does the moss grow? How…
To cut a long story short, Dave’s policy was to lead you through a series of questions, thereby guiding you to discover the answers to life, the universe, and everything for yourself. In many ways this proved to be a superb learning experience (but you quickly learned not to ask Dave what time it was).
As one example, my first task at ICL was to design a 128-bit barrel shifter and rotator; that is, a unit that could shift or rotate the contents of a 128-bit bus by any amount from 1 to 128 bits in a single clock cycle. Dave informed me that the project called for this unit to be implemented using eight Application-Specific Integrated Circuits (ASICs), each of which would handle a 16-bit chunk of the data bus. Furthermore, all of the ASICs were to be functionally identical in order to keep the project within budget.
Note: As an aside, I should point out that we were designing gate-level schematics using only pencil and paper; also that the ASICs in question each contained only around 2,000 equivalent logic gates (these devices were considered to be pretty much state-of-the-art at the time).
Initially, my task didn’t appear to be particularly strenuous. The only tricky details involved handling logical versus arithmetic shifts and working out what to data to “stuff” into the “ends” of the shifter / rotator. Part of the solution was to employ a couple of the pins on each ASIC to act as a device ID, thereby instructing each chip as to its position in the chain.
When I’d completed this part of the exercise, Dave deigned to inform me that he’d neglected one slight detail, which was that – in addition to processing all 128 bits – the shifter/rotator also had to be capable of working with only the least-significant 64 bits or the least-significant 32 bits. OK, my task had just become a tad trickier, but it still wasn’t all that bad and a few days later I returned with my latest offering. “Ah, Ha!” said Dave, “Now we’re getting there, but in addition to binary shifts/rotates, this device also has to be able to handle 128, 64, or 32-bit Binary-Coded Decimal (BCD) data.”
Dave then proceeded to explain BCD in general along with what shifting/rotating this form of data entailed (what values do you insert when performing an arithmetic shift right on a BCD representation, for example). The great thing was that Dave was endlessly patient and he was always available to answer questions and to offer suggestions as to different ways to do things and cunning logic tricks one might employ.
And so it went. Every time I finished a problem, another feature would be added to my portion of the project. In reality, of course, the main specification already contained all of these details, but if I’d been presented with the full requirements on my first day, my brains would have leaked out of my ears and I would have been reduced to a gibbering wreck. ------ End of trip down memory lane ------
Looking back with hindsight (the one exact science) I realize just how lucky I was. If I had simply been presented with the full-up specification for the shifter/rotator on the first day, I wouldn’t have known where to start. The result could well have been to ruin my self-confidence and to leave me feeling like a failure, which would almost certainly have negatively affected the rest of my career.
So my heart really goes out to the young engineer who sent me the original email. The problem is that I really don’t know what to suggest. There are various online training resources, but there’s nothing as good as having access to someone more experienced with whom you can ask questions and bounce ideas around.
One thought might be to see if there’s a local chapter of the IEEE or ACM and to join it. Maybe one could find a mentor there.
Thanks for your feedback. It's always interesting to hear the way other folks think about things ... I would like to know if others who shared your non-mentoring experience also share your ensuing neutral opinion of mentoring...
Well, in the early days of my 45 year engineering career, I had NO ONE to "mentor" me. At my first company, after a brief acquaintance period, I was given a project. The company was not a "small" company, with over 300 employees. The task was to design a 1 KW power (tube type) amplifier for a new product line being introduced. I had no assistance, except for the cooperation of the personnel in the mechanical engineering dept. and the drafting dept. All I had was my previous experience & 4 years worth of college level textbooks & a KEUFFEL & ESSER sliderule. In the intervening years, I've been responsible for the design of many sophisticated products in several fields. Some products are still being marketed fully 20+ years after first being introduced by my employer. I have a very neutral opinion of mentoring as a result
ASIC/FPGA manufacturers give lot of information in their appplication notes. Readingn them and using the starter,trainer and advanced boards will give a light on these devices. The real thing is to give a right solution for the application specified by the employers. This calls for updating themselves in these specific application areas and think creatively. Success comes for all those who does the same thing in a different easy to usable way.
Recently there was an article related to the topic (http://www.eetimes.com/electronics-blogs/pop-blog/4217625/What-happens-when-you-re-gone-). I recently retired from a large aerospace company, probably typical of most large companies these days. This company is hell bent on ridding the company of any old guys, as management theory states that only new grads have knowledge of the "latest technology". As anyone who's practiced engineering for any significant time knows, there's a wide gap between the theory of engineering and the practice of engineering (just as there is a gap between the theory of management or law or medicine and the practice of management or law or medicine). Maybe the gap is even wider in the aerospace industry as much of the practice really is gained on-the-job, under the mentorship of one who has gone before (certainly my path through design in an aerospace company was eased by my mentors). Over the last few years any semblance of mentoring or new employee skill development has been trimmed to increase the current quarter's financials. There once was a great mentoring and training program in place. The more senior, experienced engineers who comprise the pool of possible mentors, are encouraged to retire or just move along to other companies if not close enough to retirement age. And yes, this company bemoans the fact that they can't find enough qualified engineers.
With few exceptions, I haven't seen a "know it all" attitude among young engineers for a long time. The rare exceptions were in the pre-recession good old days, and were usually those whose only interest was in climbing the management ladder and doing as little engineering as possible.
You know the type -- the guy who is eager to learn "how long do you have to work here before you get to be a vice president?" Those guys were few and far between, and didn't tend to last very long :)
I was partnered with really smart test engineers as an "engineering aide" -- glorified technician -- working myself up to logistics engineer while going to night school to get my degree. For most projects these experts were contract personnel hired for projects who needed help and the aides needed the benefit of the contractors' experience. It was a win-win situation because it was part of the company's fabric to match our need for experience with our mentor's need to finish the project in time. I would suggest to the young engineer to hook up with an experienced FPGA designer to help them work thru a real design challenge. That's how one learns the discipline well.
I wrote to my local Almamatre and volonteered to Mentor young engineers. I never got a reply.
I joined Mentor.Net, but I am now 0 for 2 in getting soomeone who wants to be mentored.
I will keep trying to find local students who would like to learn science and engineering, but the best luck I have so far is after I joined Element14. I have helped a number of young and old people who have questions and appreciate the perspectives of an engineer who has survived 30+ years of making things work.
PS, My old college can kiss any Alumni donations goodbye.
Senior Engineers should be rated 50% on how well they do their own work and 50% on how well they mentor and help others. This should balance and help the problems just described. Otherwise the company is encouraging "every man for himself".
And if the company doesn't encourage mentoring and helping others by including it in employee ratings, then all it's talk about "teamwork" is just a bunch of B.S.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.