element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • Product Groups
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Personal Blogs
  • Members
  • More
Personal Blogs
Legacy Personal Blogs Be Excellent to Each Other
  • Blog
  • Documents
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Blog Post Actions
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: chriswhite
  • Date Created: 15 Apr 2015 8:02 PM Date Created
  • Views 522 views
  • Likes 5 likes
  • Comments 4 comments
  • education
  • optimization
  • agile
  • thelinker
  • development
  • embedded.fm
  • software
Related
Recommended

Be Excellent to Each Other

chriswhite
chriswhite
15 Apr 2015

A few weeks back we had Dennis Jackson on the show (Episode 94), ostensibly to talk about UAV development. While we did cover the drone topic and speculate about the future of hovering self-guided robots, we eventually drifted into another topic, one that has come up previously under different names. Dennis called it “simple code”, Chris Svec called it “empathy driven development”, and Jack Ganssle talked with us about “being a grown up engineer.”

 

I am struck by how often these similar concepts have come up on our show. It seems a lot of folks are thinking hard about the engineering profession. Not just about what’s wrong with the industry and big broad issues like diversity and pursuing meaningful applications, but also about simply what it means to be a good engineer.

 

We all have a general sense of what it means to be a good engineer. Ask your average EE or software developer and they’d probably say some mixture of technical savvy and skill, insight, time management, and wisdom. Maybe a few would mention having the ability to communicate, perhaps with both technical and non-technical team members. A few more might say something vague about discipline. So far, so good. I wonder though how many would mention cleverness or use monikers like “code ninja” or “rock star” or (heaven forfend) “hacker”?

 

Once we start using descriptions like that, I think we’ve lost our way a bit. Let’s take “rock star” for example (a word I’ve seen on many job descriptions and heard from many HR directors). It sounds cool. I mean, who doesn’t want to be a rock star? Standing up on stage illuminated by spotlights, being stared at by other wannabe rock stars in the audience, trying to make sense of your awesome skill! Or think about what “code ninja” implies. Creeping along silently, alone, using unmatched and mysterious skill to accomplish the mission, in ways that mere mortals can’t quite fathom. Sounds great!

 

However, there are a couple of big things wrong with these stereotypes. First, no engineer is a true loner. Not even the indie developer working completely on his own. Most of us work in teams, some of them cross-functional teams. We have to be able to communicate what we do to others, and sometimes we have to be able to hand off a project to someone else to finish or maintain. The ninja/rock star that creates something amazing that no one else can understand is a liability, not an asset.

 

Even a lonely indie developer still has to answer to her users, and, as Chris Svec and Dennis Jackson pointed out, she still has to answer to herself six months down the line. How often have you picked up a piece of old code, ridiculed it for being terrible (or so clever it can’t be unwound), and then discovered it was your own?

 

The second thing wrong with these stereotypes is that they encourage the notion that raw technical skill should be prized above all else. In practice, this attitude leads to over-optimized, unreadable, untestable code that “normal people” aren’t smart enough to understand. In reality, it’s merely bad code. Engineering is not a competition, it’s a collaboration. Ninjarockstars whose primary life goal is to prove their superiority (usually by indicating you can’t possibly understand what they’ve done) might be in the wrong business.

 

Enough about the wrong approach though, what are some attitudes we can foster to make things better? Not just for others who have to work with us, but for our future selves as well?

I’d say four things: discipline, maturity, simplicity, and empathy.

 

Discipline, to me, means having the self-control to slow down, to fully understand a project or a problem. It means possibly writing out a state machine by hand instead of just starting to write the code. It means methodical development instead of hacking. It also means following a set of guidelines for development. Maybe the company set these down in the past, or maybe you came up with them yourself (or use some set of universal ones). Understand why they were instituted, so that following them makes sense. Things like code reviews, revision control, static analysis tools, and doing proper design work before coding all can contribute to better products, though they may sound like chores.

 

Which brings me to maturity. Maturity often means sometimes doing something unpleasant so that the future is a little better. That could be sticking to the development process even when it seems inefficient. It could mean not taking code review comments personally if a colleague says your code is unclear or overcomplicated. Perhaps it’s just that your code needs to be read by others who might not have your experience or the opportunity to ask you for details. Being a grown up also means dialing back the urge to demonstrate your skills when it is inappropriate.

 

For simplicity, we have many sources to draw from: “Keep it simple, stupid”, “Everything should be made as simple as possible, but not simpler”, “Simplicity is the ultimate sophistication”, etc. Though too easy and trite, the fact that these kinds of quotes are so popular illustrates that there is power in not overcomplicating things. I think the Donald Knuth statement (often misinterpreted) says it best for computer science:

 

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

 

He is not saying that optimization is bad, but that optimizing code at the expense of being methodical about design is an error. It’s easy to fall into that trap: optimization is fun. It’s satisfying to squeeze out that last 5% of performance. It’s also time consuming and if you step back and understand your problem and system resources, potentially unnecessary. Optimized code can also be the most difficult to read and explain. As software engineer Dennis pointed out on his episode, “I want you to be able to explain it to me over lunch in a few minutes” [38:20]. I agree that’s a good metric for simplicity.

 

These ideas fall together if you think about it in terms of empathy, as iRobot’s Chris Svec has been advocating. Think about the next person to come along and read your code, maybe years after you wrote it.

 

“Empathy is putting yourself in someone else’s shoes”[21:35] – Chris Svec

 

Unless you want them to struggle to understand what you were doing, expend some effort at making it as clean and simple as possible. Document well what cannot be easily gleaned from reading the code. Don’t have special scripts and tools that only you know about: share them. Above all (and this may seem odd) be nice to yourself. Think ahead about how you will encounter your code later, about what tools you might wish you had. As a maker or an engineer, consider how difficult it would be to pick up a (home) project six months to a year after taking a hiatus. What can you do to make that easier?

image


This turned into a bit of a lecture, but I think it’s worth sometimes thinking about how we approach work. Not from a technical point of view, but as human beings. As we go about trying to formalize methods to be better engineers like with Agile, we should remind ourselves that those methods aren’t on rails, they establish the ground rules. It still takes effort and compassion to work with others every day.

 


 
Chris Svec is giving a talk about Empathy Driven Development at ESC 2015 Boston.

 

  • Sign in to reply

Top Comments

  • DAB
    DAB over 8 years ago +2
    Excellent post. These are a few tips that all new or budding engineers should learn. I used to tell my newbies that people who plan can succeed, those who do not will just always wonder what went wrong…
  • DAB
    DAB over 8 years ago in reply to Former Member

    I think that you learn much more from errors than you do from successes.

     

    I used to sit down and do a project post mortem so that everyone could provide their view of what worked and what didn't and how we could improve things for the next project.

     

    DAB

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Former Member
    Former Member over 8 years ago

    And what is also important - knoweledge. You have to know about things you are going to manage with.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Former Member
    Former Member over 8 years ago in reply to DAB

    What a great post... I also tell to my students (as I am a lecturer) that they shuld focus more on things that go right instead of wondering of why everything goes wrong. And ofcourse one of the most important point in reaching a goal is hard work...

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • DAB
    DAB over 8 years ago

    Excellent post.

     

    These are a few tips that all new or budding engineers should learn.

     

    I used to tell my newbies that people who plan can succeed, those who do not will just always wonder what went wrong.

     

    The hardest thing for new engineers to learn is that it is the planning process that is so valuable.  That is the time when you consider risks and design/implementation options.

    When the final plan becomes untenable, you can draw on those options to reduce blocks of capability to meet the new timeline.

     

    Knowing what you can change that has the least impact on the final product is an invaluable bit of knowledge when negotiating with managers.

     

    DAB

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube