As you may recall, in Part 1 of this mega-miniseries, your humble narrators (Max the Magnificent and Adam The Amazing) discussed some of the things you could do while at high school, college, and university to further your goal of landing a job in engineering.
Later, in Part 2, we pondered the creation of a resume (a.k.a. curriculum vitae, commonly referred to as a CV) and the joys of being interviewed. Now, in this final installment, we are going to cogitate and ruminate on how you can keep your job, grow in it, and evolve your career.
Let’s start by considering your first day on the job. Much like an interview, unless you’ve been explicitly informed otherwise, you really can’t go wrong by wearing a suit and tie. Even if your first position is with a small, casual startup company, they will appreciate the effort. Once again, remember the saying, “You only have one chance to make a first impression.”
Over the course of the first few weeks, in addition to wrapping your brain around your new duties, take some time to work out who’s who. In the case of a large company, start with your own department, and then ask around to work out how your department fits into the division and how the division fits into the company as a whole. What’s the corporate hierarchy? Who is in charge? Who reports to whom?
If you are lucky, the company you join will have a mentorship program in place. The idea here is that each new junior engineer is assigned an older, more experienced engineer whose task it is to guide them. If your company doesn’t have such a program, keep your eyes open and try to find someone who might be amenable to acting in a mentorship role.
I’ve told the following tale several times (it’s Max speaking here). My first position was as a member of a team designing CPUs for mainframe computers. I was assigned a mentor who we will call Dave Potts (because that was, and remains, his name). Dave 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...”
Dave’s policy was to lead you by asking 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 question him as to the time).
Suffice it to say that the first project assigned to me was to design a pretty complex logical function in the form of a 128-bit barrel shifter and rotator that could execute in a single clock cycle, that could operate in multiple modes, and that could be implemented in a handful of gate-limited ASICs (this was circa 1980 and we’re talking about 2,000 equivalent logic gates per device). If Dave had presented me with the full requirements document up front, I would have ended up a gibbering wreck. Instead, he gave me a small portion of the task to work on. As I finished each step, Dave added a new requirement into the mix, guiding me step-by-step until I’d successfully completed the design and learned an incredible amount in the process without my brains leaking out of my ears. If only every junior engineer could be so lucky.
Depending on your personality, the first few days in a new job can be a little nerve-wracking. Don’t panic! Everyone has gone through this, including the people you are going to be working with. Try to project confidence without giving the impression of being cocky.
If you’ve recently graduated from university, you may be feeling somewhat self-important: “I am an engineer” (with “fear my wrath” in subtext). You may also feel superior to anyone who isn’t an engineer, including sales and marketing. Trust us on this, engineering, marketing, and sales are like a three-legged stool -- take any one of the legs away and the other two are useless (you don’t want to know what the guys and gals in the sales and marketing groups think about the folks in engineering).
Similarly, you aren’t going to get very far without the support of the office staff, the people who work in the warehouse, members of the janitorial department, and so forth. Remember that a cheerful smile and a kind word go a long way. The bottom line is, no matter how puffed-up you feel about yourself, nobody likes anyone who acts like a complete Richard or Richenda.
Speaking of which, one thing that really gets on non-engineers’ nerves is when they ask you a simple question and you try to show off and baffle them with techno-speak. Taking complex topics and making them understandable is a skill. Don’t try to convince people how clever you are -- this is something they will work out one way or the other for themselves pretty quickly -- it’s much better to explain things in such a way that your audience feels that they are the clever ones for understanding what you are saying.
The counterpart to the above is that you shouldn’t be afraid to ask questions. When I started my first position (it’s Max speaking again), every couple of weeks our department would hold a 1-hour lecture on something related to business or engineering. Invariably, the presenter would say something I didn’t understand, but I would be too embarrassed to put my hand up in case my peers and my superiors thought I was a fool. On every occasion, one of the more senior engineers, Joe Taylor, would raise his hand and pose the question I’d been pondering, at which point I would think, “Thank you Joe!” It was only much later that I realized Joe already knew the answers -- he was asking questions for the benefit of the junior engineers.
With regard to keeping your job and evolving into it, a good start is to always maintain an engineering logbook. By the end of your career you should have a collection of these little beauties on your shelf. Among other things, use this to record all the interesting things you learn (and where you read/saw them), the possibilities you consider (“Should I use circuit A or B”), the decisions you make (“I rejected circuit A because... and I opted for circuit B because...”), and the results from any experiments you make. With regard to the latter, never ever fudge the results to make them fit what you think they should be. There will always be underlying reasons for your getting results that differ from what you expect and discovering those causes will teach you a lot. It may be that you have to put any strange results on the “back burner,” but recording them now will allow you to return to them in the future when you have an “Ah Ha!” moment. As Isaac Asimov famously said, "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny...'"
Another point is to never stop learning. Don’t get blinkered into thinking only about your current narrow area of expertise. In my case (Max here), in addition to copious amounts of science fiction, I like to read books on subjects like computing, physics, chemistry, and biology, both for my own edification and also to give me a broader perspective (some recommendations would be, Nine Algorithms That Changed the Future, The Order of Time, The Disappearing Spoon, and Wetware: A Computer in Every Living Cell, respectively).
One thing I like to do (Max again, I’m afraid) is to always have one or two hobby projects on the go. I find that it’s a lot easier to learn something new if I start with a goal – something I want to do – and then work out how to achieve that goal. I find focusing on something that’s not work-related to be relaxing. In addition to giving me something to talk about and write about and show off to my engineering friends, I invariably end up learning a bunch of “stuff.” For example, one of my current hobby projects is a 12x12 array of ping pong balls, each containing a tricolor LED.
In addition to a bunch of other stuff, I ran across a clever way to implement a simple simulator that others can use to develop programs to run on my array. And, just a couple of days ago as I pen these words, someone introduced me to the concept of Core Wars, in which two little programs fight each other to survive in a virtual memory space. I’m now looking at implementing a Core Wars simulator on the Arduino, using my 12x12 array to display a representation of the ongoing battle.
If at all possible, get your company to send you to relevant conferences and exhibitions. While you are there, do your best to network like a champion. In addition to networking with people who work in similar fields to yourself, also try to meet people in other disciplines. You never know when you might need to ask someone a question about something, and people are much more amenable to sharing their valuable time helping someone they’ve met face-to-face.
We’ve said this before, and we’ll say it again – practice your writing and speaking skills. As you evolve in your role, you might want to think about starting a blog and submitting articles to print or online publications (get permission from your manager first), because this is a great way to “get your name out there.” Also, you might think about submitting proposals to present papers at these conferences. You might think you have nothing to say and that everyone already knows what you know, but this is rarely the case. The people who already know what you are talking about can go to another presentation, while the people who aren’t familiar with your area of expertise, but who want to learn more, will come to listen to you. This is another great way to “get your name out there,” both in the wider world and within your own company.
One of our friends, Jaime Villela, is passionate about persuading engineers to improve their communication skills. As part of this, Jaime has started posting a series of video interviews. At the time of this writing, three of these videos have been posted (with more on the way): Yours Truly (Clive Maxfield), Bill Schweber, and Adam Carlson. Bill is known throughout the industry for his analog expertise, while Adam manages to be a mechanical engineer who designs electronics and an aerospace engineer who designs submarines.
Be careful what you say on social media (nuff said).
As part of this project, we asked some friends if they had any thoughts they would care to share on this topic, a few examples of which are presented below:
Charles Pfeil: Respect. When starting a new job, the most important thing to do is to earn the respect of coworkers. This requires listening to, and understanding, their perspective and motivations.
Peter Smith CEng: Remember that other engineers are not your only audience. Communication skills are critical. How you communicate with senior staff will not be necessarily the same way you communicate with other engineers.
Antonio Giacomelli de Oliveira: If you are going to behave like an arrogant genius, make sure you are a genius!
Matthew Eshleman: Listen carefully. Work just a little harder than you think you can (but not too much; burn-out is real). Learn how to accept and process criticism. Be an engineer (seek out the deeper problem and the root cause of failures). Learn from others' mistakes. Show up on time. Do not lie. Be considerate when working in shared workspaces.
Member Dnj on EmbeddedRelated: I wrote my first program in 1967, so I think that I've seen a lot of things and met a lot of people. Here’s some advice to new "whiz kid" graduates at their first jobs:
Don't go into a new job thinking that you are the smartest person in the room. You probably aren't and this attitude will only generate resentment. Some of us were the best in our classes too and we've had to keep up with new technology without formal training.
If you are the smartest person in the room, then find a different company because this one isn't going to present enough challenges to keep you interested. Always find competition that is better than you so that you can learn and progress.
Show up, on time, every day.
Unless you've been at the office all night to complete something or to solve a nasty problem, don't get caught sleeping on the job. It never happened to me, but I have seen people lose their jobs for it.
Listen ten times longer than you talk -- a hundred time longer if you are in a large group. Listen and learn.
It's not a job if you love what you are doing and are amazed that people will pay you for what you would almost be willing to do for free. Don't tell anyone that you would do it for free. You'll never work a day in your life if you have true passion for what you are doing.
For software developers: Software engineering is the art, craft, and applied science of solving problems with the use of a computer. A programming language is only a means through which you express your solution. Don't get bogged down by trying to use one language to meet every solution. Learn languages. Languages come and go, so keep up with trends and new methods. I can't tell you how many languages that I've had to learn over 50 years, but it has been a bunch. I learned Univac SPURT for my first real programming job. I got laid off (last in, first out) when the company lost a big contract. That made me an EX-SPURT programmer and I'm not ashamed to proclaim that.
Wilmer Companioni from KEMET Corp: After reading Parts 1 and 2, Wilmer felt moved to contact us to share a couple of points as food for thought:
Be adaptable and be willing to learn and apply new techniques. The only real failure is not trying or not learning from your mistakes.
Opportunities are subtle, so keep your eyes open. Real life is not like the movies. Opportunities do not always knock -- most of the time, they tap gently.
Do not wait to be told to take ownership of something. Live by the motto: “Get up, get after it, and be relentless.”
Unlearning is perhaps just as important as learning. Do not get stuck in your ways or keep following the same well-trodden path just because that is the way things have always been. Sometimes you have to forget what you think you know to move ahead.
The comfort zone is a trap. Only doing what you are already good at will only get you so far. Learn how to use the skills in which you excel in different situations and to tackle new challenges.
Be a translator. Business has many languages: technology, finance, marketing, manufacturing, and sales. Learn them all to the point where you can translate among them.
Richard Fletcher: Richard was also kind enough to offer a wealth of points, many of which reflect and emphasis what we (and others) have said in different ways:
Understand that an engineer’s job is to solve problems in a commercially viable way.
Communication will set you apart -- make sure that your message is tailored to your audience. Don't talk technical to sales -- they are more interested in what the product or service can do for the customer.
Learn, learn, and learn some more. Go into engineering expecting it to not only be a career but also a hobby. The very best engineers have side projects at home and are continually pushing themselves to learn and apply more ideas and techniques.
The best solutions are usually the simplest. Avoid the temptation of trying to show how clever you are with a complex solution. There are often many ways to solve the same problem but only some of them are viable.
Try to understand the bigger picture. What is the purpose of what you are working on? Keeping that in mind can help when solutions become tricky and a tangential approach might be useful.
Get good at estimating. How complex is the task? What are the risks? What could go wrong? What is the definition of “done”? It can be easy to overlook a major task and end up way out in your solution.
Deadlines are important and not just theoretical points in time. Plan to hit them and communicate if they are going to be missed. Don't wait until the last moment to flag an issue with a delivery time as other people are depending on your output.
Ask for help. Engineers are usually very helpful towards each other and happy to listen to an issue and offer advice.
When you hit a brick wall, stop, take a break, and reflect on the issue. Better still, go and explain the issue to someone -- anyone. Talking about your issue forces you to reframe it. It can even help if you explain it to an inanimate object.
Use Google and RTFM. Treat all forums and sources with caution. More so than ever, there are a wealth of resources to help; use them but use them with caution. Don't blindly copy what someone if a forum has suggested. Use ideas from others for inspiration, but calculate, simulate, and check.
Wow! Looking back, there’s a lot to digest here, but we really hope you will take the time to reflect on all of these points, and we’d love to hear your thoughts on anything we’ve presented.
Our penultimate point is: “Try to become indispensable.” Be interested in what others are doing, offer suggestions to your colleagues if they are amenable to accepting them, and cheerfully help out if asked as long as doing so doesn’t impact your own work. If you keep your finger on the pulse of everything that’s going on and you help out when you can, you will become a “go-to person” to whom others come for advice, and this will be noticed by those who don the undergarments of authority and stride the corridors of power.
At the beginning of this column, we advised you to seek out a mentor. Our final point (for now) is that, once you have some experience under your belt, it would be great if you can become a mentor yourself. As junior folks come onboard, take them under your wing and try to help them get started on their engineering journey. As part of this, if the company you work for doesn’t already have a mentorship program, maybe you could talk to “the powers that be” and try to get them to start one, thereby benefitting both the company and newcomers to the profession for years to come.
As always, we welcome your comments, questions, and suggestions.