HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
You must login to participate in this chat. Please login.

Good presentation and entire class ... a nice refresh on sytem level approaches to test and debug

collaboration is key, I agree ... teambuilding, eliminating finger pointing, healthy competition to improve

Alex's question on engineering management ...

HP's come a long way from a couple guys in a garage ... now, it's women in glass offices ... :)

 

Managers have different priorities than engineers ... its like the difference between an operating system and a device driver

Most significant elements (for me) of presentation(s) this week were:

1) The anecdotes that amplified the points made in the presentation and

2) A focus on prevention

Day 4 - Slide 20:

During development of the product, the engineers should constantly ask
      What are the potential problems in this design?
      Can I avoid them?
      Will my change affect anybody else?

Thank you Gary and Alex!

key: step by step approach, with or without a collaboration

...again, nothing and nobody is perfect...

Debugging testing on embedded units

I am primarily involved in documentation. So I need to understand a wide range of subjects, and explain in terminology understandable by all.

Iron

Face to face discussions are far more effective than sending email to collaborate.

Iron

You can make a good manager, but you can't make a good engineer.

Iron

Prove yourself wrong first!

Iron

Mixed reaction to the manager question: some good some no so.

Hardware - ASIC/FPGA design

What's the most significant point that you think Gary made this week, point or info that's new to you?

- holistic view on testing&debugging, 'patching' hardware in software (firmware), his book for university

Thank you for the course

  

Iron

Okay all caught up

Thanks Gary 

I agree with letting problems sit

I always think of 

I will serve no wine before its time quote

Ready for the soft skills

One more class and I should be caught up

Thanks Gary, for sharing your knowledge and experience

Iron

Thank you for this week!

Iron

OK Gary, I just got back to the desk. Thanks for the response. It's been a pleasure.

Have to go now.

Iron

@danlafleur: Operations in the military/government are definitely different than the private sector. There are lots of engineering and management training out there. Each company is different on how much importance they put on continuing education. Even within HP it had been up and down over the years.

Iron

@apdobaj: One thing that helps provide a framework for doing things right the first time is to look into the future. What would version 2.0 and 3.0 of your product look like? That gets you steered in the right direction for right now. Another thing to consider is to record all concerns or missing aspects about the design or process. It may be a searchable comment in the code, like this, /* LATER: Add support for the wrong-button input. */

Iron

@MazianLab: Gamma Rays are definitely something that requires special handling given health and security concerns. Modeling the behavior is good but it definitely needs to be an accurate model. One option is to record the behavior of the current source when using the real isotopes and then play that back. Do this for various types of readings. One thing I would strongly suggest is to add some datalogging capability on your side of the device that can capture the timing, the amplitude, the wave shape, etc. Then when you are able to test it with the real stuff, you can compare a real wave form against the simulated wave form. I would also suggest leaving that capability in when you ship the product so that when it is used in an unusual situation, you can retrieve the waveform and figure out why. A good test suite would then be running your code in a test harness and then feeding it each of these different sampled waveforms. I'm limited here by not being able to draw pictures or ask you questions. Contact me if you want more help on this.

Iron

@mark_t00: Hum, sounds like there are already some bad feelings going on. Here are some ideas. Ask them why it's not in their area. Then ask them why again, then again. Challenge the individuals to prove the problem isn't in their area; they can't just state that it isn't, they have to prove it. Proving it may require extra debug code or scope traces. Bring both sides into the same room and walk through the problem, from the beginning, and examine each step in detail. Put both sides in the same room without any managers, mediators, or arbitrators and tell them they can't come out until they resolve it. Take other assigned tasks off their platter so that this is the only thing they are allowed to work on. Bring in an unbiased, third party individual/team to look into it. If they end up successfully working together to fix it, take them out to dinner, or something.

Iron

Never got the audio - it just kept on buffering. Stream must be blocked by IT as I have current Flash version. Will just have to listen to archive when available. Slides need some commentary to be meaningful.

Iron

@Ann R. Thryft: Are management practices different for engineer than for someone else, like marketing? The basic human-to-human aspects are the same, show respect (to both managers and underlings), treat them like intelligent human beings, etc. Differences come in the details. A marketing team would enjoy a reward to go golfing for the afternoon. Engineers would rather pick up the free food, go back to the desk, and keep coding. :-)

Iron

@Rob Spiegel: Have I seen improvements in management? That's like asking if parents today are better than parents two decades ago. You still have different personalities involved for both the manager and the underlings and you still have new people coming into those positions that don't know it yet. Company culture and country/ethnic cultures come into play too. Someone made a comment about parenting. "There is no such thing as a parenting style; it is a parenting hybrid." Each kid is different. I know that because I have six of my own. Same with management. What's effective depends on the people involved.

Iron

Gary, maybe more of a thought than a question...

In my military experience, a promotion usually meant corses to teach the knowledge and skills needed for the new position. Leadership training, admin skills and lots of encouragement to practice them.

 

I don't see the private sector ever having the will to spend money on training people for supervisory or management roles. It's expected that ypu just pick up what's needed and sdtart doing the job.

Iron

Testing only not debuging ...

Iron

thank you you all, it's a great presenation.

Iron

@syakovac: I like your comment, "R&D is about the unknown." To me, that's what makes it fun and exciting.

Iron

Alex,

I almost forgot to answer your question.  I'm involved in both hardware and software with a little bit of management thrown in.  (I try to minimize the management parts.)

Iron

Some have mentioned females vs. males. I agree, females make good managers; I've had a few over the years. In fact, I'd say that two of three best managers I've ever worked under were females.

Iron

but a framework for achieving that goal of doing it right the first time is critical. there are so many moving parts that nobody can remember them all. and not all touchpoints are appropriate for all maturity levels of the project. "The Checklist Manifesto" is a good reference to this concept.

Iron

As expected, lots of comments against managers but everybody agrees there are good ones too. Just like engineers; there are good and bad ones.

Iron

Thanks for you input.  We have a strategy meeting planned next week.  We will be pulling all of the information we have collected together and planning our next steps.  I agree ownership of the problem needs to be shared.

Iron

Thank you Gary. It's been an interesting and valuable way to spend my lunch time this week.

Thanks Alex and see all next time.

Iron

Thanks for the presentation.  Very informative.

Iron

Ownership of the problem is a great first step, when the group starts working as a mutually supporting team. Its tough to get there in some places.

Iron

Gary, I am involved in upgrading some Gamma Ray Dose Calibrators. Unfortunately I don't have access to Gamma Isotope, infact I am not allowed to keep it. So far, I simulated Current Source circuit instead of Isotope. But this simulation is limited. Do you have any suggestion to solve my problem?

Iron

@raghu comments that "doing it right the first time" only comes after experience. True. Because the experience is what tells you what might fail. But anybody can develop a mind set to look out for what might go wrong, whether they have little or lots of experience in that domain.

Iron

@Alex - What all this about a Starbucks card for today's attendees?

Iron

@Alex - What all this about a Starbucks card for today's attendees?

Iron

@GStringhan - It's good to have you back for this last session of this track.

Iron

You can count me in on debug and testing.

Iron

mark_t00 - Joint ownership is key since the system is shipped as a system, not hardware or software seperated.  The customer doesn't care where the issue is and they shouldn't either and work together to solve the issue.

Iron

clia - no argument from me, good point.

Iron

mark_t00 - Sounds like you need to get both the hardware and software team to own the problem together instead of saying it must be the others issue.

Iron

mark_t00, have you tried formalizing your approach? I've found engaging in a structured and agreed upon DOE goes a long way in reducing the finger pointing.

 

Iron

@apdobaj- I agree with this, but would add that any manager has to have some human element, to quote Gary from earlier.  I have met engineers that would fit into that category that you describe, but you know they would never make good managers because they have no idea how to deal with people individually, and how to capitalize on everyones strengths without allowing each individuals weaknesses to bring down the project.  Nothing against them as engineers, or people for that matter; they just didn't have that skill.

Iron

My engineering career began after 25 years of being an electronic technician for the same company. I designed a test fixture, which helped to analyze a serious problem being caused by a safety defect within a digital timer circuit that would intermittently lock-up and cause a critical output to become enrergized. Doing that, allowed me to become a member of the Systems Integration Engineering Team.

Iron

This is a delicate balancing act

 

Iron

In my view, a good (engineering) manager is one who provides a framework for bringing to bear critical efficiencies and learning from having been through the process numerous times, while at the same time allowing creativity to prosper.

 

Iron

@raghu brings up an interesting (but maybe rhetorical) question. "Isn't debugging an integral part of design process itself?" It is but sometimes it is not planned for in the schedule. It is but it requires that you do some testing before you know what needs to be debugged. 

Iron

Question: I am currently working on a team with an embedded soft core processor in an FPGA.  We have been struggling to find a particular problem and there has been a lot of finger pointing between FPGA design and software design.  Having some trouble getting some people to be willing to add code/hardware to "hack" the problem and get a better picture of what is happening.  I believe EGO is getting in the way, some unwillingness to do this because the problem "can't" be there.  Here come the people skills.  Any suggestions on how to proceed without laying down the iron fist? 

Iron

Do management and teambuilding theories and practices work differently for engineers than for, say, marketing and sales people? Are there different management and teambuilding practices that should be used for engineers?

Blogger

Thanks again, Gary!

Iron

@Alex - What all this about a Starbucks card for today's attendees?

Iron

There have been a lot of management and team-building theories tested over the past two decades. Given that, do you see things improving in effective management and team-building with your clients?

Blogger

OK, guys I need to go take my car out of the metered paring spot. So long, see you next time.

Iron

Thanks, Gary, for including the human-ware aspects.

Blogger

Please REASK any questions you want answered immediately or asked at the beginning that haven't been answered yet.

Blogger

Thanks for all your comments! I'll look through them for questions.

Iron

@luizcosta - Fully agree that MBAs without specific education and field experience in the problems their teams are involved, are useless.  That's one of the reasons that I enrolled in an Executive MBA program.  Only individuals with a minimum of 10 years of experience in their fields could apply and it made the education much more valuable.

Iron

Thanks Gary and Alex

Iron

Thanks for some great debugging and testing information.

 

Iron

@syakovac:  3)  Include example use cases in documentation and use them as test cases.

Great idea!  I wish more developers would do that.

Iron

Thank you Gary, excellent presentation.

Iron

Thanks guys.  Great stuff!

Iron

Good general info.

But please use PDFs in the future, NOT Powerpointless.

Iron

Thanks, Gary and Alex !

Iron

Thx. Gary and Alex.

Iron

Yeah, I like the music at the end.  Good touch, guys!

Iron

What is a rule to apply redundance as a protection?

Testing of inertial guidance systems and the associated electronics but today I spend more time than I want managing others in design and test

Iron

I once told a manager that; "I would rather club small furry animals with a stick for food than work for him."  Moved on and was infinitely happier in a new position

Iron

Alex - I received a nice email from UBM / Design News regarding an offer for attending today's session.  While I appreciate the offer, I'd personally rather not have to deal with my corporate ethics department.  Can UBM / Design News donate the "gift" to charity?

Iron

Thanks Gary and Alex...this is the best week and enjoyed eveyday of the lecture..

Iron

Thanks Gary and Alex for a strong end to the series.

Blogger

Thanks Gary and Alex... Have a nice weekedn!!

Iron

@Gary --  Good stuff.  Will be back in the archives to see a few of the earlier ones I missed...  Thanks a bunch...

if you see a manager with pointy hair .............. run!!!

Iron

Good music! tchun, tchun, ...

Iron

Thanks Gary, great presentation.

Iron

thanks Alex, for keeping everything on track

Iron

thanks Gary. great lecture!!!

Thank you Gary and Alex for another great lecture, and another great series.

Iron

I always assume that two rational people with the same data should come to the same conclusion, so if I had a difference of an opionion with someone, my assumption was they must have some additional data that I did not,  instead of jumping to the conclusion that they were wrong.

Iron

Thanks Gary, great presentation.

Iron

Thanks Gary, great presentation

Iron

Thanks, Gary, for a great set of lectures this week!

Iron

Leader lead by showing. That implies that MBAs with not specific education and field experience in the problems their teams are involved, are useless. 

Iron

Collaboration...do it.

Iron

Thanks Gary - Really enjoyed the week's sessions

Iron

creating targeted documentation, software to targeted users is key skill that i learned how to apply over the past few years

Iron

For designing: All the time consider "The worst situation".

For debugging: First you should suspect to everything is wrong. Second try to localize the bug. Change the part if you are at least 70% sure. Otherwise look more to find the problem.

Iron

the most importam

nt thing i have found goes back to old school...."KNOW YOUR BASICS' or at least understand them as they refe to hardward /sofeware..

 

 

@focusembedded+

 

Iron

@Gary: Key point - Planning to every minute aspect of the project!

Useful things:  1)  Things with a lot of functionality, I offer two ways to configure them, one that is really simple (think big green button named RUN) and another that lets you tweak every possible feature.  You can run it either way or with a combo.

2)  I do all my testing that I possibly can from a system level perspective which lets me know what observability and controllability to put in.

3)  Include example use cases in documentation and use them as test cases.

Iron

Lessons learnerd database.

Iron

Error handling in test scripts to capture unexpected application behavior... helps in capturing failure data and test batch execution

@THasham: *With* engineers, a lot of managers are *still* useless...  ;-)

Test early, test often during development.  I have found it most helpful to test individual components as they are developed, then the system testing goes much smoother.  I have worked with some who leave all the testing to the end, it usually makes system testing take much longer, much harder to solve issues, and the solutions often are less than ideal in order to get the product ready to ship.

Iron

The intuition is applied equally with technical and people problems.

Iron

One thing to remember: Don't ignore anomalies seen during testing that are hard / "impossible" to reproduce.  They often are clues to a subtle problem that will be much harder to deal with after release.

Iron

Without engineers..manager are useless..:D

Iron

Key thing: Have a debriefing at the end of the project.  What did we learn?  What would we do different next time?

Key debug: Get everyone to agree on what the problem is. I think people think they know but if you discuss it then you find out everyone has a different interpretation. You cannot debug without clarity.

Iron

Get all the stake holders in a room if you can and get to the root cause rather than pass the buck around...

Iron

Humility is essential in listening.  Also, don't take criticism personally but evaluate if fair and act towards improvement.

Iron

My key thing used in most problem solving situations is confidently using my intuition. I follow my nose as I sniff through the symptoms and responses.

Iron

We actually bring in the guy who writes the manual for the product early in the game.  If *he* can't explain it or figure out how a user is going to understand it, you probably have a product full of lousy features.  Then you invite the test guys in once you think you know what problem you're solving.  Only *then* do you start actually designing the product.

Key aspect that I have found in my work: collaborating with others.  I have worked on a project with another programmer, and I was able to find all of the bugs in her code that she missed and she was able to find the ones in my own code that I had missed.  Worked well together.

Iron

understand "don't cares" so you don't get bogged down on wrong details

Iron

the hardware designers should consult with the software guys BEFORE they design the board. Sometimes parts are designed you be used (port allocation for example) in certain ways by software

Iron

I have used hackware when I have found issues to help located the bug and that allows additional data collection and to pin point the bug quicker.

Iron

Through over the wall with a pillow around.

Iron

key design most useful - build in debug and data collection into the design

Iron

Look at the things that others do not look.. or miss to look for.

Iron

near-atomic commits in git while debugging on a dedicated branch

Iron

produce reliable, robust c# based terminal emulator applications to device targets

Iron

always assume that my code is at fault

Iron

I call them baby tests, test all along the way

Iron

Thanks for a great session 

Iron

KISS - Keep it simple stupid

 

Iron

Concerning Alex's question about managers...

Many years ago, a manager said, "Good engineers are a dime a dozen, but a good manager is hard to find."  That says a lot about the attitude of managers toward engineers.  In part, he was correct: "Good managers are hard to find."

The day I left the company, I gave this manager a dime and told him he would need it.  :.)

Iron

Alexander Wolfe: What's the most significant point that you think Gary made this week, point or info that's new to you?

During Part 2 of this track, Gary talked about Test Plans.  To make his points, he provided stories of his experiences at HP.  We ALL are familiar with ink jet printers, and hearing his stories of HPs testing allow his points to be driven home in excellent fashion.  We don't get to see behind the curtain very often, so this was the next best thing to getting a tour at HP.  Well done, Gary!

Iron

You can count me in on debug and testing.

Iron

Hello to all of ya.

Iron

it's called thinking out loud (sound board)

Iron

HAVE AN OPEN MIND - BE A GENIOUS - You are indeed

totally agree... i wrote a best practices in creating automation test scripts, design, structure, coding, environment setup, teardown, error handling, reporting and review process

 Best time for debugging is early morning. Never do testing when you are tired.

Iron

Thanks for a great session Gary!

great three points.

Iron

yes... audio is streaming

Iron

@rhall007 - how do you remember the solutions?  wake up and write it down?

 

Iron

Audio still works.

 

Iron

Thats very true Gary - to sometimes just let things be as is, and to use a sounding board - I use my mom who is a teacher!

Iron

Thank you Gary, I enjoyed the lecture.

Iron

if you can say it you can see it ...

great three points..Thanks.Gary!!

Iron

Tell your wife the struggles you're going through in your test efforts: she will hate you, but you'll find the problems. :o) :o)

Iron

Good point about making sure test code is clean. When we would have product failures during testing, the Design Engineers would first be very critical of our testing setups to try and prove it was not their issue.

Iron

slide 12 - we did that for years as an undergrad, explaining the problem to your "teddy bear" - and all of a sudden the lightbulb goes off

Iron

Is the audio stream working?

Iron

I often solve problems when asleep.

Iron

Again, I'd stress co-development of test and executable code is critical -- and it's equally important to have peer review on both early.  Recall that the same guy who wrote the code to test how the Hubble Space Telescope main mirror was ground was the guy who wrote the grinding algorithm.

@RAN: That manager was an idiot.  Leadership is really about taking care of your people or surrounding yourself and your people with the best resources possible.

When I was in the Navy as an Ensign, 1st Divn Officer on USS SARATOGA, I didn't have a chief (you can translate as senior engineer).  I had to earn the respect of my guys.  I got messed with a lot, but eventually, they saw that I was backing them up and rewarding them as they performed for me. 

Build up your team and share your knowledge.  Don't play "I've got a secret".  Build the tribe...

Iron

Best practices, we can all learn from each other's mistakes.

Iron

TOTALLY AGREE GARY: As I said earlier, the requirement specification book(s) should include foram test plan and requirements.

Iron

yep - hurriedly written test code definitely has bitten me before!

Iron

I've worked 10 times harder to make my test hw and sw bullet proof as the object of the test.

Iron

Yes - test code wastes lots of time.

Iron

I've seen that - errors in the test code, not the production code

Iron

@heymanj -- I think that trust in the leads is a sign of a good manager. 

Iron

@syakovac - I know that

Iron

@heymanj: Yeah, I went the same way with the driver!

Iron

AT&T CEO is THE engineer?

second to agoldin

 

Iron

Gary, which slide are we on?

Iron

@slk -- It isn't about the cost of the food.

Iron

manager should have some technical knowledge, but *must* be willing to trust their technical leads - not assume that they have more knowledge than the technical lead

Iron

@Gary, I'm pleased to here about soft skills and social interaction as being a strong part of what we do everyday, not just technical.

Iron

agree with agoldin

Iron

I once told a manager that; "I would rather club small furry animals with a stick for food than work for him."  Moved on and was infinitely happier in a new position

Iron

test,idid not see my posts

Iron

"Test arena" and "production code". I tend to object to this separation. I believe test should be also a formal part of the development process: all in the same big tem.

Iron

 Manager should have technical knowledge 

Iron

Management mostly put too much on legal aspects giving resistance to even small risks or try have a financial cushion in a case...

if you can't do it, teach it

if you can't teach it, manage it

if you can't manage it, sale it

Iron

driver = golf club :-)

 

Iron

aye! Manager should have technical knowledge if managing a technical team! Or make wrong decicions is talent aquisition, not understand what the team is communicating and make bad decisions.

food ... is just a cheap trick.  I'm sure you can afford it too.

Iron

Management? I guess they have to put first things first..So many times, We talk about technical feasibility and the discussion goes towards cost cutting..isnt it more important to make it work and then worry about costs?

Iron

food is tha language of the world.

Iron

Page 8 is very good tip.

Iron

2nd class?  on a good day

Iron

Starbucks, big draw.

Iron

Concerning Alex's question about managers...

Many years ago, a manager said, "Good engineers are a dime a dozen, but a good manager is hard to find."  That says a lot about the attitude of managers toward engineers.  In part, he was correct: "Good managers are hard to find."

The day I left the company, I gave this manager a dime and told him he would need it.  :.)

Iron

One thing about the food is that it works even better if the families are invited.

Iron

most definitely a thumbs up on the food

Iron

food works well. It's a social thing and some shared time away from work.

Iron

I have seen the food trick work REALLY well at one of my last companies.

Iron

Engineering and management seems to be completely different.

Iron

technical knowledge insight is a great plus for engineer or a manager

Iron

@sykovac: "Insane CEO?"  Would you like names and addresses?  You're absolutely right.  Fish rots from the head down.

Management is another challenge. It is good for the right people bad choice for others. Good managers are a great benefit to a project, poor ones can ruin a project.

 

Iron

I left HP a few years ago because Hurd took all the financial rewards away from the really good technical people and gave it to some really poor middle managers.

Iron

Had excellent experience with my Managers & Mentors over the years.  Good people skills with technical skills as well. Moved into Engineering Management for my last 20 yrs

Iron

if you are doing nothing, you don't have mistakes, ... so you can and will be promoted...

Iron

I'm a generalist PM, so I received much friction from senior SW programmers who had the attitude of "he's not an engr, he's a suit".  I had to win them over one at a time and let them know I was a "wannabe engineer but couldn't hack the math".  I had 6yrs of deckplate naval leadership to run with.

Iron

Well, some managers remember they were engineers once. lol! They try to help juniors grow! I don't really want to comment on their types! Gary's todays session speaks all about it!

 

Good managers need to part of the engineering team by interacting in the lab.  Those that only run engineers from an office tend to direct without insight.

Iron

If you do not apply for the management position, or the other for that matter,

tha bigger check goes somewhwew else, no doubt.

Iron

Most engineering management ranks are full of people who didn't like engineering enough to stay with it long enough to become good engineers.  Then they're in a position where they feel vulnerable that the people they manage know they don't have good enough chops to do it themselves.  And the social dynamic there becomes utterly terrible.  The only good engineering managers I've seen were completely ego free or have been in engineering 20+ years themselves -- and that's very rare.

Insanity starts at the top.  If your manager is insane, the whole group will be.  Don't work for a company with an insane CEO.  In R&D, I run into management issues where managers who are trained to be business men or manage manufacturing wreak havok because R&D is all about the unknown but those other fields are all about the known.  Known is predictable.  Unknown is not.

Iron

yet there is something wrong with me.. lol.. I rather deal with technology that people.

Iron

seriously 'tho they forget that their job is to reduce the stress on you not increase it - take obstacles out of your way

Iron

After 25 yrs, I've avoided management at multiple times

 

Iron

@Alex ...  Used to be I couldn't spell Manager now I "R" one

Iron

Yeah, like @danlafleur, engineers get promoted until they can no longer do their (management) job.

Engineers promoted to mangers have a tendency to not let go and have a bad habit of micro-managing.

Iron

Management, this is a question.

Chinese goverment is a team of engineers.  Is it good?

Best managers are those who worked in the trenches for a long time - Worst the one or two year engineers with an MBA :-)  (Nothing against MBA - I have one - but got it after more than 15 years of experience as an engineer)

Iron

Yes, as a business owner, and engineering team supervisor (nuclear power plant control group and telecommunication group).

Iron

Managers must work for their employees, not the other way around.

Iron

My manager has a PHD and is a micro manages.  Give me a manager not a designer

Iron

Managers with enginerring background - are very analytical and are kind of shy on people skills

Iron

thats funny, managers are like people, some do great, others...........

Iron

I am the Engineering Manager thus it would be hard to answer without bias.

The engineers that make for good managers are the same that you can introduce the client to.  The ones that you want to hide when the client come around, are in the right spot just solving engineering problems. 

Iron

Good managers, yes

Iron

I always have to manage managers' expectations.  Solving a problem takes as long as it takes.  No 9 women can make a baby in one month.

Iron

Been there -- much prefer project or technical management to people management.

Iron

Well, since I was a manager for many years, my experience was all positive....  :-)

Iron

but project management we do well better than others.

Iron

Lower management : great.  Technical skill diminishes with seniority.

Iron

I am not a good manager,

Iron

I work about 60 to 85 hours a week, lots of time after work to work on my robotics,,but I'm a typical engineer, so social skills, lol, engineers as managers,, very few are good,, but very few

Iron

@ all - as Ales said, there is no paid overtime in engineering, eventually some free hours what you can take.   I hate this !!!

Iron

Some good, some bad.  It just depends on the person.

Positive. Promoted to be one of them.

Iron

the only good engineering manager is a dead engineering manager  ;-)

Iron

nay to people management..

Iron

I tend to value a job or project that keeps me interested and happily challenged. Management duties takes away from that becuse it isn't as hands on with what I like to do.

Iron

it completely depends on the manager's character and personality and managing experience

 

Iron

yes..agree with ALex

Iron

Managers are not managers because of their skills (usually) but because of their egos.

Iron

the more your job is like hobby the better.  you produce far more quality work in an efficient manner.

for me i dig distributed computing using command semaphores between device and c# based hosts with simple packet passing protocols, fun stuff.  can access and manipulate control registers, ect.

 

Iron

Women love managing.

Iron

@Gary, ever hear of being promoted to your highest level of incompetence?

Iron

@ Greekeng dont see that much now days.

Iron

Consultant, 28 years.

Iron

Alexander Wolfe: What's the most significant point that you think Gary made this week, point or info that's new to you?

During Part 2 of this track, Gary talked about Test Plans.  To make his points, he provided stories of his experiences at HP.  We ALL are familiar with ink jet printers, and hearing his stories of HPs testing allow his points to be driven home in excellent fashion.  We don't get to see behind the curtain very often, so this was the next best thing to getting a tour at HP.  Well done, Gary!

Iron

I work on a salary plus ot

Iron

I had a chip rotated more than once 90 and 180 deg.

Iron

@alexander wolfe: Finance for you!

Iron

Me too, Gary: Apple II+ Motorolla 6502 assembly programming and designing interface boards for it.

Iron

and yes I agree with working myself out of a job, the knowledge I pass is free, so I figure work hard, ensure the company can use your data after to leave and you've find you never leave.. problem you never get promoted either, two headed coin

Iron

I never got paid overtime in engineering. One of the things that really bugged me. You were considered an exempt "professional," so no overtime.

Blogger

@mazianlab - I had once chip rotated 90deg !!!

Iron

Doing it first time only happens with experience and that too only few times i guess..

Iron

provide tools that are reliable, robust, do it right the first time.

Iron

@slk, sometimes assembly people put components like diode or transistor, or capacitor in wrong direction. 

 

 

Iron

@geekeng - I always get undertime, not overtime.  :)

Iron

Yes, when working of specific projects, usually double time..

Iron

Consultants always work themselves out of a job.

Iron

Another one being: try to fix rather than replace

Iron

@tpass - Doing it right the first time is very undervalued.   It is more than TRUE.

Iron

definately, management thinks that you can build something with minimal test and design effort.  Shorter design cycles..  etc...

Iron

Greekeng, you got PAID for your overtime????

Blogger

In my experience, 60 hour work weeks in the middle of a project is common in engineering.

Blogger

Missed errata sheet when designing in complex parts is a big show stopper.

Iron

but I love the money for 60 hours....

Iron

Oh yeah...  the term "hackware" is new to me, but the concept is not.  Do it all the time to flesh out potential problems with new software routines or hardware changes.

Iron

My take: Try to get it right the 1st time

Iron

@Alex: Concept of Hackware. The emphasis on 'Doing it right the first time'! Gary's sessions throughtout the week have been amazing!

The real-world description of solving Gary's daughter's printer problem was very helpful.

Blogger

Management loves 'diving catches' and some people build their careers on it. Doing it right the first time is very undervalued.

Iron

I think Hackware was a good one for me too.

Iron

Should that be "reward" instead of "award"?

Iron

hackware and test harnesses

Iron

@mazianlab - the worst is if you have assy the wrong part (type or value)

Iron

@Alex.... Hackware was new to me.

Iron

Gary brought to me a first glance on what is the real world from a top of the line printer developer and manufacturer.

Iron

THere are many helpful points..but Hackware is the one most siginificant.

Iron

I like the idea of using "hack code"

Iron

Management is always the stumbling block. Much incompetence. Many females wanting to play in this field with "light" knowledge.

Iron

Because I have had to do it, it is very true that hardware problems have to be solved at a later date with software.

Iron

Some other debug and testing documents never point out how important testing your code during developement stage is.

Iron

I think all his points have been great, I think all points made are falling into common sense trouble-shooting skill sets.

Iron

Most significant point: Let's all be geniuses!

Iron

@Alex - Hackware to minimize bugs during development

Iron

Hackware is a concept that I was aware of in a small way. I can see uses now that would have helped in past projects.

Iron

Worst problem is when you are involved in debugging the new PC board assembly mistake.

Iron

@Alex - that you could make money by founding your own company doing consulting etc...

Iron

Wosniak an Jobs split, becaue Woz didn't want to make money, just be a geek, and Jobs dodn't want to make money with just any type of business activity. Jobs wanted to be only involved with the best product from the perpective of the customer and plain art.

Iron

I design embedded systems so have to debug both hardware and software and decide which one (or both is at fault).  And, yes, engineer's egos get involved!

Iron

HW and SW, develop, debug and test, primarily embedded.

 

Iron

design any type of h/w, test, debug and some s/w too

Iron

What's the most significant point that you think Gary made this week, point or info that's new to you?

Blogger

basic service and repair. it involves finguring out the code and make sure the hardware and software work correctly together.

Mainly hardware design, but i've done some software/firmware and digital FPGA design.

Iron

System Architect (HW and SW)

dFEMA is good for final analysis for software testing too

Iron

Electrical engineer, software/firmware development primarily but hardware design as needed. Everything from initial bringup and debug of hardware to quality problems on the line.

Iron

ASIC design engineer (Hardware)

Iron

What about dFMEA for OEM equipment as a formal method (versus Ishikawa)? Always helped me.

Iron

Design test and debug and automated test and diagnostics.

Iron

I was involved in ndebugging and testing for long time.

Iron

Some experience in debug & test

debug and test over 8 years time frame in production environment,  cross trained into MS .NET after which i created terminal emulator applications for both verification engineering and validation engineering stages.  now i am doing c# host to device targets with RS232, IC2, SPI and other protocols and OEM test gear control using SCPI all over C# based tools

 

Iron

both debugging and test

Iron

HW & SW doing both test & debug

Iron

15+ years..test and some debugging

Iron

lots of development, debug and test experience

Iron

isnt debugging an integral part of design process itself?

Iron

Testing of inertial guidance systems and the associated electronics but today I spend more time than I want managing others in design and test

Iron

Been heavily involved in debug and test.  In fact, we spend 3x as much time in testbench development as we do developing the actual source code or design.  It's often in designing the test that we locate the corner cases that make the design itself better.  If you go into the lab to see what will happen, you're already screwed.  You go there already knowing, because you've thought the tests through as part of the design.

Formal debugging and testing: created my businesses software engineering methodology. 

Iron

Debug, test, and integration.

Hardware verification / prototyping / certification.

Iron

Do most of the test and debug on all my designs

Iron

Debug - much, test - some

Iron

Hardware, Software, Debug, Test, .... Yes

Iron

debug yes, test yes

Iron

10+ years of test engineering, perf testing, debugging, 

Iron

lots of embedded hw and firmware debugging. Mostly in test and measurement applications.

Iron

Debugging s/w and h/w

Iron

Yes - Debugging and testing 

Iron

Alex, been involved in debug/test for many years -- my own designs and those of others.

Iron

both debugging and testing

Iron

Yes - debug and test.

Iron

very involved in debugging and testing

Yes, debugging is new for me.  Done h/w troubleshooting with automotive electrical only.

 

Iron

Debug and Test: Yes, mostly non OEM systems, Some OEM

Iron

Novice at Debug and Test

Iron

Product Evaluation Test Manager

Iron

Debugging and testing? - yes

Debug and test? yes to both

Iron

software, self-taught, paid mostly for finding bugs

Iron

have done debugging and testing.

10+ years of test engineering, perf testing, debugging, large systems etc...

Iron

You can count me in on debug and testing.

Iron

I work for a small company so I do all of the software and my own testing.

 

Iron

Debug, yes; test, yes.

Iron

hardware, applied math (control systems theory and microwave eng.), software

Iron

i design/build MS .NET interface to embedded and other device targets - i am creating youtube video series to illustrate my services - please contact me for further on my services, cheers

Iron

@GStringhan - It's good to have you back for this last session of this track.

Iron

Now, Test Engineering

Past, EE Design

Iron

hardware before ... now is mostly software

 

Iron

hardware and software

Iron

I'm hardware more so, and licensed in AZ and Ont Canada

Iron

Background in hardware, doing mostly software now

Iron

And hello today :-)

Iron

software and some firmware

 

Iron

Good afternoon, Gary.

Iron

I'm used 6800 processors and up

Iron
h/w,  s/w = hobby
Iron

Both hardware and sftware

Iron

Background is Digital Hardware & Software

Iron

Primarily software/firmware some hardware

 

I'm a Hardware more so, unless we are talking about PLCs and HMIs, or for robotic applications, then hardware and software using Fuzzy

Iron

Hardware and embedded firmware designer

right now mostly hardware and some software

Iron

Both hardware and software

Iron

Both hardware and software.

Iron

Software QA Analyst

Iron

Both Hardware and Software

Iron

Hardware design and selection

Iron

@flyfysher..please refresh your page.

Iron

Good afternoon, Alex.

Iron

Test Engineer here.

Iron

both hardware and software/firmware

Iron

First timer here, too.  No audio track?

 

Iron

hello to all-Guy who repairs all the stuff you design here

Iron

Hi everyone. Looking forward to the presentation.

Blogger

Good afternoon folks!

Iron

Both hardware and software..but mostly hardware and software as needed.

Iron

Hello Firmware Engineer here.

Iron

Joe Test, u HAVE joined the class.. this is it

 

Blogger

Alexander Wolfe: So Gary can tune his comments, can you put down below whether you're primarily involved in hardware or software?

All the above...

Iron

Hello to all of ya.

Iron

@jl,Thanks for corecting me. It's oldage efect.

Iron

Hello, I'm a first time user.  Where do you click to join the class?

 

Iron

SW Test Engineer here...

My post looks like it was lost in the ether...

Communication electronics  and computer hardware. Firmware, Automated Test and application software as a maintenance programmer

Iron

@MazianLab - if only we could spell hardware ;^)

Iron

Oh I like that... Electrical\Controls Engineer, PCB design and factory automation system design, also robotic automation design

Iron

Alex - I received a nice email from UBM / Design News regarding an offer for attending today's session.  While I appreciate the offer, I'd personally rather not have to deal with my corporate ethics department.  Can UBM / Design News donate the "gift" to charity?

Iron

 Hello Gary and Alex, has been a great week

Iron

Yesterday we got claryfication of cooperation in the team..in smart way, What we add today should be even more effective, we hope.

Haedware and Software.

Iron

Embedded SW Engineer, checking in and ready for a great presentation!

Iron

Good day from Tucson

Iron

Thanks to Alex and Gary...if I am not mistaken..we'll be having starburg coffee..haa hah

Iron

Greetings from MI. THank You for this presentation

 

Hi Everyone,

First time I have been able to make the presentation live.  Looking forward to this presentation.

Iron

Greetings from Pleasanton, CA.

 

Iron

Alex - I'm actually involved in both hardware and software (firmware) but happier on the hardware side :-)

Iron

Can't wait for another great presentation!

Iron

Happy Friday.  Software Engineer here....

Iron

Good Day everyone!!

Hello Gary and Alex..

Iron

Hello Everyone...glad to be here, anxious to hear Gary's presentation today

Iron

So Gary can tune his comments, can you put down below whether you're primarily involved in hardware or software?

Blogger

Good morning Gary, Alex and all, happy Friday.

Iron

hello from sunny miami..

 Today's the last session in this track, so please everyone start entering your closing questions and comments now and we'll talk about them.

Blogger

Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.

Blogger

Please join our Digi-Key Continuing Education Center LinkedIn Group at http://linkd.in/yoNGeY

Blogger

The streaming audio player will appear on this web page when the show starts at 2pm eastern Friday. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

Blogger


Partner Zone
Latest Analysis
The promise of the Internet of Things (IoT) is that devices, gadgets, and appliances we use every day will be able to communicate with one another. This potential is not limited to household items or smartphones, but also things we find in our yard and garden, as evidenced by a recent challenge from the element14 design community.
Researchers have developed a new flexible fabric that integrates both movement and sensors, introducing new potential for technology-embedded clothing and soft robots.
Made by Monkeys highlights products that somehow slipped by the QC cops.
If you didn't realize that PowerPoint presentations are inherently hilarious, you have to see Don McMillan take one apart. McMillan -- aka the Technically Funny Comic -- worked for 10 years as an engineer before he switched to stand-up comedy.
The first Tacoma Narrows Bridge was a Washington State suspension bridge that opened in 1940 and spanned the Tacoma Narrows strait of Puget Sound between Tacoma and the Kitsap Peninsula. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7, just four months after it opened.
More:Blogs|News
Design News Webinar Series
11/19/2014 11:00 a.m. California / 2:00 p.m. New York
11/6/2014 11:00 a.m. California / 2:00 p.m. New York
10/7/2014 8:00 a.m. California / 11:00 a.m. New York
12/11/2014 8:00 a.m. California / 11:00 a.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Dec 1 - 5, An Introduction to Embedded Software Architecture and Design
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Last Archived Class
Sponsored by Littelfuse
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service