Practice! Practice!

I recently attended a piano recital for a young man in my neighborhood who studies  music at a local university. He has natural musical aptitude and is an awesome piano talent. During his recital he played compositions from popular yet long since deceased composers: Beethoven, Liszt, Debussy, Prokofiev. If you’re not familiar with any of these names, not to worry. I only know them because my wife’s family is super musical. Kind of funny how most recitals I attend feature music from dead musicians, as if to suggest there are no modern day composers whose music is worth performing. Certainly not the case, but yet another topic best left for a future discussion. Getting back to the recital…

As I watched the young man perform, I was amazed at his dexterity and agility at the piano. Though the expression may be a bit trite, his hands literally danced up and down the keyboard. While I’ve only had a couple of years of piano lessons in my life (hasn’t everybody?), I appreciated not only his talent, but also the hours and hours of practice required to perform at his level – and mind you, this was his Junior year recital. Should he have a Senior year recital, I hope to get an invitation to that performance as well. I’m sure his performance will be no less amazing.

Thinking about his hours of practice set me thinking about engineering design. His musical expertise comes by way of practice, and in order for his practice to be effective he has to spend hours upon hours at the keyboard rehearsing until each note and nuance becomes automatic. While his passion showed in his performance, passion alone for any worthwhile endeavor isn’t enough. It’s the practice that turns passion into skill.

Developing engineering expertise is, in many ways, much like building musical expertise. While engineering school is the typical path for building a solid technical foundation for our careers, it’s how we build on that foundation that really matters. Our level of passion, and our commitment to continual practice (yes, I mean engineering design practice), in many ways determines our career success. Engineering’s corollary to a musical score is a design specification. And just as the musical score tells a musician what to play, but not how to play it, the design specification guides our engineering efforts, but we are free to decide how we turn the written details into a working system. The path from specification to working system may be filled with false starts and mistakes, but willingness to make mistakes is key to perfecting a design – as long as the mistakes happen in simulation or the lab, not in the final product.

I have another neighbor who, at 80 years old, is still going strong as a practicing engineer. I refer to him as “an engineer’s engineer”, complete with a shirt pocket full of pencils and pens and a scientific calculator. I’m pretty sure he hasn’t used many simulation tools during his career – though I must admit I wouldn’t be surprised if he has. But I can imagine him practicing the old-fashioned way, hovered over a green engineering notepad with mechanical pencil moving briskly across the page, and calculator keys near-meltdown as he works on his latest project. The point is that it’s not so much how we practice, but that we do. As engineers, our “performances” are judged on the quality of the systems we design. In a very real sense, each system design we work on is practice for the next. And if your days and weeks are sometimes consumed by writing reports and doing project paper work, try working on a personal project or two. But if you develop projects for you and your family’s use, take the advice from David Penrose, an Aerospace industry engineer, who was interviewed for the November 2012 issue of Circuit Cellar magazine. David’s advice was simple: “Never automate something your spouse will have to fix when you are away”. Wise counsel indeed.

Post Author

Posted December 10th, 2012, by

Post Tags

, , ,

Post Comments

No Comments

About Mike Jensen's Blog

Views, insights, and commentary on mechatronic system design and analysis. Mike Jensen's Blog

Comments

Add Your Comment

Archives

June 2014
  • Wow Factor
  • May 2014
  • SystemVision 5.10.3
  • March 2014
  • IESF 2014: Military & Aerospace
  • Engineering Oops!
  • Big Engineering
  • January 2014
  • SystemVision Model Wizard
  • December 2013
  • SystemVision 5.10.2
  • Modeling: An Engineer’s Dilemma
  • October 2013
  • What is Your Legacy?
  • September 2013
  • Automotive IESF 2013
  • July 2013
  • Simple Design Solutions
  • June 2013
  • SystemVision 5.10
  • May 2013
  • Engineering Muscle Memory
  • EDA vs. Windows 8
  • March 2013
  • VHDL-AMS Stress Modeling – Part 3
  • January 2013
  • VHDL-AMS Stress Modeling – Part 2
  • VHDL-AMS Stress Modeling – Part 1
  • December 2012
  • Practice! Practice!
  • November 2012
  • Sharing Tool Expertise
  • October 2012
  • Preserving Expertise
  • Virtual Prototyping — Really?
  • Innovations in Motion Control Design
  • September 2012
  • Game Changers
  • Do We Overdesign?
  • August 2012
  • Tsunami Remnants
  • July 2012
  • A New Look at Device Modeling
  • SystemVision 5.9
  • June 2012
  • Veyron Physics
  • May 2012
  • Rooster Tail Engineering
  • April 2012
  • Automotive IESF 2012
  • Teaching and Learning CAN Bus
  • March 2012
  • Analog Modeling – Part 6
  • Analog Modeling – Part 5
  • Analog Modeling – Part 4
  • February 2012
  • Analog Modeling – Part 3
  • Analog Modeling – Part 2
  • January 2012
  • Analog Modeling – Part 1
  • Connecting Tools and Processes
  • December 2011
  • Turning-Off and Tuning-In
  • Use vs. Experience
  • Analyzing the Big Picture
  • November 2011
  • Simulating for Reliability
  • October 2011
  • SystemVision 5.8
  • VHDL-AMS Model Portability — Fact or Fiction?
  • September 2011
  • IESF 2011 Moves to Frankfurt
  • Simulation Troubleshooting
  • August 2011
  • Qualities of VHDL-AMS Quantities
  • Military & Aerospace IESF 2011
  • Touring Johnson Space Center
  • July 2011
  • Engineering versus Science
  • June 2011
  • System Reengineering
  • May 2011
  • Integrating Hardware and Software Design
  • Engine Remote Start
  • Integrated System Design
  • Simulation Experiments (Part 3)
  • April 2011
  • Automotive IESF 2011
  • Pushbutton Cars
  • System Simulation with FEA-Base Motor Models
  • March 2011
  • Simulation Experiments (Part 2)
  • Simulation Experiments (Part 1)
  • Japan: Patience and Grace Amid Disaster
  • Top Gear = Driving Fun
  • February 2011
  • Buoyancy
  • Ideas in Motion
  • January 2011
  • The Mechanical Half of Mechatronics
  • Detroit Auto Show
  • Signal-flow vs Conserved System Modeling
  • SystemVision 5.7…Ready, Set, Go!
  • December 2010
  • SystemVision and Windows 7
  • Friction Vacation
  • Simulation Beyond Volts and Amps (Part 4)
  • November 2010
  • Simulation Beyond Volts and Amps (Part 3)
  • Simulation Beyond Volts and Amps (Part 2)
  • Simulation Beyond Volts and Amps (Part 1)
  • October 2010
  • SAE Convergence Recap (and an Unexpected Surprise)
  • VHDL-AMS Black Belt
  • Converging on SAE Convergence
  • System Design vs System Repair
  • September 2010
  • What’s the “AMS” in VHDL-AMS?
  • How Sensitive is Your System?
  • Do You Trust Your Simulator?
  • August 2010
  • What’s in a SPICE Model?
  • Cycling + Gravity = Pain
  • NI Week: Fun for Engineers
  • June 2010
  • Are You a Flexible Thinker?
  • VHDL-AMS and Switch Hysteresis
  • May 2010
  • VHDL-AMS Revisited
  • Segway to U3-X
  • Atomic Glue
  • March 2010
  • IESF Recap
  • February 2010
  • IESF is Coming…
  • System Level HDL-topia
  • January 2010
  • Mastering Design Abstraction
  • The Joy of Disassembly