Things you don't Learn in College #2: Talk it out when Tensions are High

Okay, this next post should be much more readable than the last to non embedded software people.  Talk in person if someone is angry, or you are angry is the idea.  This is a generic piece of advice you have probably already heard.  Now that I'm at writing generic stuff, I might as well write for MSNBC articles such as "5 ways to be healthy... one, eat well, two, excercise, three get a good nights rest, etc.".  But my hope is that writing my thoughts and experience trying to follow this advice will further elaborate and affirm its importance.

How I Learned: LogicPD

Going back to when I was an applications engineer at LogicPD, I was very close to the "front line" of customer support.  My pal Aaron's resposibility was to qualify potential customers, and shield us from problem customers.  Sometimes times customers would sign up to contract their development out to us, and I often was the guy to help them out.

When in this environment, inevitably you will have to deal with an angry customers.  There are many fish in the customer sea.  Some will be angry for good reasons, such as misleading or "swiss cheese" documentation.  Others are just, well, crazy.  I remember Aaaron saving emails that we deamed "gems".  One of our favorites was one that ended "THIS IS UNEXPECTABLE@!!!!!" (I'll leave it to you to do the translation). 

When this happened, I remember the first thing my leader at the time (Mr. Rempel, who would leave to start Exosite) told us to do was to give them a call on the phone.   And almost 100%, the tension that was in the email didn't come through.  Things could worked out, person to person.  To this day this has stuck with me, both inside and outside of work.

Why it Works

There is so much more communication that happens in person compared to email.  Your tone of voice, your facial expressions, eye contact.  When this is lost, each party fills in the dots.  Dots can be filled in correctly or incorrectly.

More fundamentally, when you communicate over email, you are sending and receiving words from and to a peice of software.  You are in your own head and not communicating with another human being in the moment.  When you talk in person, you never loose site that you are talking to another human being.

Why it is Hard

Like most peices of generic advice, it is easy to listen to, agree with, and accept.  But the act of looking someone in the eyes, not having the leasure of planning and brainstorming each sentence in an email, and telling your true feelings on something is hard to do.  It requires improvising, not overthinking, and courage.  If the person to talk to is someone who you are intimidated by (I've found this inside and outside of work), getting everything out that you are thinking is very hard.  This is the core issue with fear/intimidation management styles.

Beyond the difficulty of actually doing it, simply changing habbits and behavior is very challenging too.  It took a couple "lessons learned" for me before doing this sunk in and stuck.

Why Conflict is Unavoidable

You will never work in a workplace without passionate people.  You will never work somewhere where everyone has the exact same personality.  Even if you are king at avoiding conflict, things will arise at some point in your career.  This is fundamental to being a human being, and working with human beings.

More Tips

• Write down bullet points in your notebook of the key things you want to convey and follow it during the discussion.   Keeping focus when talking in person can be challenging, and could require persistence and steering.
• Read and learn about NVC and NVC in the Workplace.
• In case you forget or realize your built-in habbits aren't changing because of this blog post, get a reminder tatoo backwards on your forehead.  Sometimes that daily note when you look in the mirror is just what is needed.  :)

That's it for this week.  I can't decide whether I want to write about dealing with imperfection or the top 6 people I owe my career to next.  Stay tuned!

Things you don't Learn in College (#1)

In 2004 I got my degree in Computer Engineering from Portland State University.  When I graduated, I was lucky enough to get a job in my field right off the bat.  With 8 years of Embedded System experience behind my belt, I often look back at what I never learned in college.  To get myself to write in here more frequently, I will take my time and write a series of posts about what I do on the job now that I didn't learn in college.

At PSU, and I bet at most college undergraduate Computer Engineering programs, you don't learn about Bill of Material (BOM) management.  And by BOM Management, I mean part numbers, model numbers, assemblies, sub-assemblies, engineering change orders (ECOs), etc.

For pure, high-level software development, this isn't necessary.  Your software is installed on a operating system, there isn't parts to keep track of.  But when you are writing hardware specific software, understanding how part management and change control is essential.  IE: When your firmware is ready for production, how do you add the binary release to the PCB BOM?  If you need to revisit a binary release from a past product, how do you pull that up?  How do you trace that binary, contained (often as a document) in a BOM, back to source control?  How do you get the exact manufacturer part number and spec of a sensor your software controls?

I remember the "on the job training" when I started at LogicPD, which involved using Agile (now owned by Oracle) and having a huge headache trying to understand how each part on a PCB has a part number, part numbers are grouped in a BOM, which also has a part number so that can be contained in another BOM.  This creates a hierarchy.  Then - change management, when you rev a part number versus create a new part number, and assessing whether a new part is form fit or function equavilient of an old one.  Sprinkle in manufacturer part numbers associated with internal part numbers, and reving a part number of BOM with an ECO.

A class or two on this would have been probably a little more important than say, the year of solid state physics I took.  I remember this series of classes being rediculously specialized.  It would have been great if I were getting a PHD, with a career of being a wafer/silicon scientist.  I guess it goes to show who PSU's biggest doners are (ahem, Intel).

Okay, stay tuned for more!

Embedded Software Versioning

Ureka!  I've been thinking about the best way to version embedded software when you release it.  Here you go:

Major.Minor.Sub

Major corresponds to the PCB or product build.
Minor corresponds to the release number.
Sub corresponds to the release iterative release if the Minor number has been branched.

Major
So you are building a product.  There will be 4-5 different prototype  builds of the product before it hits production.  The major number represents the prototype build the software will programmed on.  This could be just for the PCB, or a prototype build of the enitre product.  Usually these are a big deal, thus getting the major revision.

Minor
Minor is for subsequent software releases number after the build.  So the third prototype build comes back with your software preprogrammed on it (version 3.0.0).  Then you make more releases intended for this build (3.1.0, 3.2.0, 3.3.0) as development and testing continues.

Sub
Sub is if you have to branch a minor release to keep the software stable if there are any major features to be added between minor releases.  Ie 3.1.1, 3.1.2, 3.1.3 gets released for tester to regress bugs, while the code is taken apart and put together again for release 3.2.0.  Then of course, all the xx.1 xx.2 and xx.3 changes will need to be merged in at some point.

Another way to describe this: Major subdivides the project by hardware build, Minor subdivides it by software releases, and sub allows a scheme to fix bugs and do sub releases to QA

Yes, this is very similar to regular software version numbering.  But the major is associated with hardware platform.

Would everyone agree with this scheme?  Probably not, and I think that is okay.  You see, revision numbering isn't a one-size-fits-all system.  It all depends on the end-user of the version number.  Who will be using the version number, and what organiziation concepts they will expect of it.  This isn't the same for every industry.

Okay, time for some rest.

Firmware Interview Excercise

Recently I thought of a good job interview excercise for a potential firmware engineer. Here is the excercise for your use, plus guidlines of how to grade it:

Write on the whiteboard C/C++ code to read a memory mapped register, clear a bit, then write it back.

Things I don't care about:

• If there are any simple syntax errors or missing semicolons.
• The variables types used, as long as the candidate knows how many bits they are (int, versus uint32, versus DWORD).

Things I do care about:

• Was the "volatile" keyword used when declaring the variable that would point to the register? (I would hope that the value we get from the register is a fresh, uncached value).
• Did the candidate ask how big the data bus of the system is? (How else would I know how the pointer type?)
• Was it second nature to use the "wordwithbittoflip &= ~MASK" convention.
• Did the candidate ask whether a MMU is being used? (need to make sure you are accessing physical memory, not virtual)
• Did the candidate ask what OS is being used, if any? (tracing back to the MMU question, if there is one being used, getting access to physical memory will vary from OS)

Bonus points:

• The candidate uses bit banding for increased speed.
• The candidate wonders if the system is big or little endian when setting up the mask.

Next chance I get to interview someone maybe I'll give it a shot. It is consistent with Joel On Software guidlines to have the interview candidate write simple, non "gotcha" code. The above should be simple for anyone with embedded experience.