Welcome to Rob’s Adam’s Apple, where I will blog about my trials and travails as a programmer and occasional hardware hacker.

I am currently an iThing developer at Barnes and Noble, working on the Nook Reader application. I am also developing an Arduino clone called the Carduino, and am building a Nixie Tube Calculator.

Having over a quarter century of programming experience, there are a few things that I have found to be very important to be a successful programmer.  The first is communication.  This one still trips me up.  When not talking to computers in their respective native tongues, you are talking to:

  1. Other Programmers
  2. People who do not necessarily understand what you are doing, but want to control how you do it.  Also known as Managers.
  3. People who likely don’t understand what you are doing, but want to change how you do it.  Also known as Customers, Clients, and/or Stakeholders.
  4. Other people.  These may include friends, significant others, potential managers, or potential significant others.

I will concern myself with the first 3, the last is up to you.

When communicating with other programmers, be respectful.  You may not understand why they didn’t initialize a variable, which caused it to have a random value and crash the system during a customer demo.  Which may make you think they are stupid or incompetent.  Even if they are, it won’t help to accuse them of it.  When talking to anyone, always consider how you would feel if they said what you’re about to say to you, in the tone of voice you’re about to use.  Now think of how you’d rather hear it and say it that way.  These people may have your back some day – do you want them to tell you about your uninitialized variable first, or the CEO?

When talking to managers, honesty is the key.  These people need to represent you up the food chain.  To do this, they need to know what’s going on.  Resist the temptation to say that the project that you feel will take four weeks can be done in 1.  It can’t, and you may be fired after week two when it’s still only half done.  Better to find out what they need implemented next week, then plan out the following three.  They’ll be less upset, and in the long run you’ll get the reputation of dependability, which leads to promotions.

Stakeholders don’t care how you’re implementing your web fetches.  If you tell them you’re performing asynchronous background fetches, they won’t understand and will feel frustrated.  You always want stakeholders to associate you with warm fuzzies.  Delegate the bad news and compromise to the manager, and come through for the clients.

I definitely speak autobiographically here – hopefully some of you reading this can get the benefit of my mistakes 🙂