标签: ENGINEER

Keeping a record of the design progress, measured results, decisions made, and calculations performed are all part of the job description for any engineer. There are many aspects to any project, and for a project involving microcontrollers and/or programmable logic, this is compounded by programs that are compiled down to object code. The reasons we need to keep the records include (but are not limited to):   Prove that the design works Obtain data for use in data sheets Determine approaches for testing the unit Patents Legal liability Accounting auditing (for tax credits or progress payments) ISO auditing. My current approach is very 20 th Century -- being completely paper driven. I have a 3-ring binder in which I keep requirements, data sheets, listings, schematics, sundry pieces of paper like POs as well as a notebook. In truth the notebook is more of a scrapbook. It contains hand written notes, drawings and calculations along with clippings pasted in like Excel worksheets, photos, ‘scope plots, design reviews and other details. It is all very clumsy and especially stressful when trying to follow a trail during an ISO audit.   The app I want would replicate the design binder (with improvements) as a single file. I imagine it would have to be distributed across a PC as well as a tablet. Of course it would start with the ability to enter text on a keyboard and have the ability to include MSWord and pdf files. It would be possible to add handwritten notes, preferably with a stylus since it works better than my finger for writing. Converting the handwritten text to machine readable format would be a plus when searching for something. The app would have the ability to add notation to the included pdf sheets. It would need a simple spreadsheet since I sometimes gather data at an environmental chamber away from my desk and then execute some simple calculations. But it would also need to be able to integrate more complex calculations from Excel or even Matlab although I would settle for screen shots with hyperlinks to the respective files.   I would like to see a feature to add bookmarks so that there could be cross linkages throughout the file. Cross linkages into source code would really be nice, since some data cannot be included in the source files.   Interfacing to instrumentation like DVMs or ‘scopes through USB or Wi-Fi is probably unrealistic in the short term, although if there was a script or programming language it could be customized.   Obviously there would be a central folder location where all the electronic files reside but synchronization should be as transparent as possible.   There are dozens of apps that address some aspects of my wish list, but so far I haven’t found any that allows any really cohesive approach. We have the technology, and I hope this blog nudges someone to produce this ultimate app. Sometimes I feel that a laptop may answer my hardware requirements and the Windows environment comes closest to the level of integration that I need, but the handwritten input is important and the clam-shell format is often inconvenient. The AceCAD Digimemo L2  also has potential as an input device, allowing the full pen and paper experience, but the approach lacks some of the other features I would like.   How do you document your projects? Do you know of any app that approaches my needs?   Aubrey Kagan

Max's recent blog ( I've been a naughty engineer ) sent me rummaging through my own notebooks for something I wrote a while back:    Keeping a record of the design progress, measured results, decisions made, and calculations performed are all part of the job description for any engineer. There are many aspects to any project, and for a project involving microcontrollers and/or programmable logic, this is compounded by programs that are compiled down to object code. The reasons we need to keep the records include (but are not limited to):   Prove that the design works Obtain data for use in data sheets Determine approaches for testing the unit Patents Legal liability Accounting auditing (for tax credits or progress payments) ISO auditing. My current approach is very 20 th Century -- being completely paper driven. I have a 3-ring binder in which I keep requirements, data sheets, listings, schematics, sundry pieces of paper like POs as well as a notebook. In truth the notebook is more of a scrapbook. It contains hand written notes, drawings and calculations along with clippings pasted in like Excel worksheets, photos, ‘scope plots, design reviews and other details. It is all very clumsy and especially stressful when trying to follow a trail during an ISO audit.   The app I want would replicate the design binder (with improvements) as a single file. I imagine it would have to be distributed across a PC as well as a tablet. Of course it would start with the ability to enter text on a keyboard and have the ability to include MSWord and pdf files. It would be possible to add handwritten notes, preferably with a stylus since it works better than my finger for writing. Converting the handwritten text to machine readable format would be a plus when searching for something. The app would have the ability to add notation to the included pdf sheets. It would need a simple spreadsheet since I sometimes gather data at an environmental chamber away from my desk and then execute some simple calculations. But it would also need to be able to integrate more complex calculations from Excel or even Matlab although I would settle for screen shots with hyperlinks to the respective files.   I would like to see a feature to add bookmarks so that there could be cross linkages throughout the file. Cross linkages into source code would really be nice, since some data cannot be included in the source files.   Interfacing to instrumentation like DVMs or ‘scopes through USB or Wi-Fi is probably unrealistic in the short term, although if there was a script or programming language it could be customized.   Obviously there would be a central folder location where all the electronic files reside but synchronization should be as transparent as possible.   There are dozens of apps that address some aspects of my wish list, but so far I haven’t found any that allows any really cohesive approach. We have the technology, and I hope this blog nudges someone to produce this ultimate app. Sometimes I feel that a laptop may answer my hardware requirements and the Windows environment comes closest to the level of integration that I need, but the handwritten input is important and the clam-shell format is often inconvenient. The AceCAD Digimemo L2  also has potential as an input device, allowing the full pen and paper experience, but the approach lacks some of the other features I would like.   How do you document your projects? Do you know of any app that approaches my needs?   Aubrey Kagan

Earlier this year, Juan Pablo Dellaroquelle, vice president of engineering at the Silicon Valley software company Medallia, made waves when he claimed in a blog post that good engineering managers don't exist . According to Dellaroquelle, engineers who aspire to “move up” into management aren’t good engineers -- otherwise they would have been happy in their roles -- and make even worse managers. Conversely, the best engineers may exercise influence through informal channels, but have no interest in becoming managers.   Certainly, nobody would aspire to be the pointy-haired boss from Scott Adams’ Dilbert comic strip, and as Alex Wolfe pointed out in a Design News blog, most engineers are happy in non-management roles. But is there such a thing as a good engineering manager? If so, do good engineers have the qualities necessary to be one?   I believe that good engineering managers really exist, because I’ve worked for them. (In fact, I happen to work for one right now.) I’ve also known people who were great engineers, but not-so-great engineering managers. And, of course, I’ve seen people who weren’t much good in either role.   One important thing to remember is that there’s a big difference between an engineering manager and a senior engineer. An engineering manager isn’t, or shouldn’t be, directly involved in detail-level design work. If you enjoy detail-level design work -- which you presumably do, since you chose engineering as a profession -- making this transition may be difficult. In fact, it’s the main reason why most engineers try to avoid management roles: you have to spend a lot of time doing things you don’t like (i.e. going to meetings), and little or no time doing things you like (i.e. designing innovative technical solutions).   It’s also one of the main reasons why some engineers don’t succeed as managers: the temptation to get involved in detail-level design is too great. You may be extremely bright and technically knowledgeable. However, if you’re in a management role, it’s unlikely you’re as well versed in the details of a project as the engineers who are working on it every day: they’re the ones who actually do the work. If you try to micromanage these details, not only will your engineers resent you, but, more often than not, you’ll make bad decisions. Furthermore, your engineers will make bad decisions, as they try to follow your (real or imagined) “mandates” rather than their own engineering judgment. You’re not the expert anymore, so don’t try to be.   So what should an engineering manager do? - Provide your engineers with high-level direction on project goals. - Empower them to make good decisions on their own - Don’t second-guess them, but challenge them to explain their thought processes to you. - Most importantly, find out what non-technical obstacles they’re facing, and work to address them.   Another important function of engineering managers is to communicate engineers’ work to upper management and other departments. There’s a persistent stereotype that technical people have poor communication skills, and there’s a good case to be made that engineering schools need to do a better job teaching these skills. However, good communication skills, by themselves, aren’t enough. When the 19th century Russian biologist Peter Kropotkin conducted field expeditions in Siberia, he would often take the time to explain his research to curious peasants. His aristocratic colleagues ridiculed him for trying to explain advanced biological concepts to illiterate villagers. Kropotkin replied: “You can explain anything to anyone -- provided that you understand it yourself.” As an engineering manager, you won’t be able to accurately represent your engineers’ work to upper management unless you have a strong technical understanding.   For this reason, being a good engineer is a prerequisite for being a good engineering manager. However, it’s a necessary but not sufficient condition: not every good engineer will make a good engineering manager, or even want to be one in the first place. This is why good engineering managers are few and far between. The good news is that they really exist. Furthermore, it’s something you can get better at. It’s a myth that some people are simply born to be managers. Like anything else, management and leadership skills are learned. The best engineering managers, like the best engineers, spend time trying to get better at what they do.   Readers, what do you think? Let us know in the comments section below.   About the author Dave Palmer is a licensed professional metallurgical engineer, specializing in failure analysis and materials selection. He  works as a metallurgist for a major marine engine manufacturer.  He holds a BS in Materials Science and Engineering from the Illinois Institute of Technology, and is completing his MS thesis at the University of Wisconsin-Milwaukee.

By nature, most engineers are introverts. Software engineering is often on the list of “best careers” for introverts, with counselors supporting this recommendation with statements like, “Spending time alone with a computer could be a dream come true for any introverted techie.” And yet, these are the same people who become entrepreneurs and grow into leaders in their companies and their industries.   Of course, not every leader from our industry has had to overcome those personality traits. Most of us have been awed by the charisma of Steve Jobs and the persuasion of Jeff Bezos.   For the majority of the “left-brained” crowd with a technical background, one of the hardest parts of being a leader of a technology startup is moving away from the natural tendency to be introspective. Let me be upfront: No CEO has been successful without stepping out of his or her comfort zone.   As the founder, an entrepreneurial engineer will learn quickly that he or she is the chief sales executive. It’s up to him or her to sell and promote the company ceaselessly. That means meeting with, and selling to, potential investors, customers, employees, and partners. The company leader is expected to be the chief promoter eating, drinking, sleeping the messaging, positioning, and product story and delivering it to anyone who will listen 24/7.   The first “sales” test comes early for the entrepreneur when he or she raises money from venture capitalists. Those skills get honed quickly. Any entrepreneur who thinks this can be delegated is mistaken.   The challenge, then, is to learn to be outgoing, and it is something anyone can learn to do.   As a young engineer, I had a goal to move from engineering into marketing as a stepping-stone to management roles. I had a solid understanding of technology and knew I could learn the tenets of good marketing, but was concerned that I was a bit too reserved to be a good marketing manager. I was lucky enough to snag an interview with a legendary marketing executive, Bruce Bourbon. I shared with him my concern, and he said that I could learn to be more outgoing -- and I did.   On a much larger stage, we have witnessed the maturation of Mark Zuckerberg from an insecure engineer who handed out the infamous “I’m CEO, B****” business card to the respected leader of a publicly traded company.   Of course, this process takes time, as do many things, because the natural tendency is to stay within the comfort zone. Fortunately, as engineers, we are taught to unravel challenges, and this is yet another challenge.   The first step for a fledgling leader would be to become a better networker and to get more comfortable. Starting slowly is the best course of action. My advice is to set a small goal -- say, introduce yourself to five people you don’t know. Second, have a set of five questions or so to ask people you meet that can range from asking what they do to what keeps them up at night.   The final bit of advice is to appear confident and self-assured. Remember that, as the founder of a company, you have some bragging rights, and you can shine a new light on the challenges faced by your peer CEOs, even if they are a lot more experienced and running much larger companies.   Once the fear of networking has been overcome, it’s remarkable to note how informative industry events can be. All of a sudden, the new leader will be able to map where the company’s technology fits within the ecosystem. Other companies’ strengths and weakness could become apparent from discussions over drinks and canapés. In some cases, it may force a company to do a pivot and retool a product. Finding the product niche is important and will only happen by networking with potential customers and partners.   Whether we’re grooming ourselves to be a leader or not, an important point for each of us is to find our personal style, which means learning to play to our strengths. In some cases, the relaxed hoodie and jeans look fits like a mantle, while others of us follow a Wall Street appearance. All kinds can be successful. Choosing the style that’s true to who we are and sticking with it will help make people believe in us.   Michel Courtoy is a former design engineer and EDA executive who sits on the board of directors at Breker Verification Systems.

When we were about 10, all the kids in our neighbourhood shared a red Radio Flyer wagon. Nobody knew who owned it; it was community property. But then one day, after several years of hard use, a wheel fell off. We all gathered around to look at the wagon like a rider looking at his crippled horse. It'd have to be put down. There was a boy on our block, about two years older than the rest of us, who was a tough kid. His hair was combed back in a DA, he never smiled, and he kept to himself. The word "greaser" didn't exist back then. When he saw us standing around, he ambled over to check out our wagon wake. Then he left and went to his house down the block. A few minutes later he returned with one of his mom's bobby pins. Without saying a word, he flipped the wagon over, put the wheel back on the axle, and stuck the bobby pin in to serve as a makeshift cotter pin to hold the wheel in place. Then he turned the wagon back on its wheels and it worked again, and we all stood in awe of the boy. For just a moment I saw a slight grin on his face when he said, "There." Then he got on his Schwinn, like the Lone Ranger astride Silver after saving a town, and went off on his solitary way. I've met hundreds of engineers in my work life since then. And for all their advanced degrees, the best of them were all variations on that theme: approach a seemingly intractable challenge, see to the heart of the matter, and by addressing that single key point the fix falls into place. Engineers may be the most taken-for-granted and under-appreciated people in the world. We see the courage of fire fighters and the skill of airline pilots, but the engineer's face is always well hidden. Tom Mahon is a freelance writer for EE Times with a deep affinity for engineers.