On Heroes and Interviews

When I started my career in software development, “heroic effort” was a compliment.  It meant a developer went above and beyond normal hours and “burned the midnight oil” to get a task done.  It meant he or she prioritized work at the top of the list and let other options and responsibilities fall by the wayside in order to get results.  It was indicative of a “can do” attitude.

For years now, heroic effort in the context of software is not a compliment.  Or at the least it’s a back-handed compliment.  It usually comes with suggestions of poor planning, poorly designed code, of an immature development process.  It leads to poor decisions which lead to poor quality.  That’s one reason not to use the word “heroic’ to describe software development activities.  Another is the fact that with a war going on, we have real heroes in our armed forces.  They are involved in life or death struggles; I don’t want to cheapen the definition of a hero.

But there are software development activities we ought to celebrate.  The word that comes to my mind is noble.  Webster defines noble as “possessing, characterized by, or arising from superiority of mind or character, or of ideals or morals.” Examples I see of noble behavior:

·         The software developer who doesn’t settle for mediocrity, but strives to be a craftsman

·         The tester in waterfall environments who seems to always find her schedule squeezed at the end of projects but doesn’t let frustration affect the quality of her work.

·         The developer who always leaves the code better than he found it, but gets his work done on time.

·         The introverted tester who regularly steps out of her comfort zone to help her scrum team become self-organizing and effective.

The difference is attitude.  We all need to make big pushes sometimes and drive projects or programs to completion.  But when you are surrounded by noble people who are driven by the desire to be excellent and do excellent work, those big, last-minute pushes, which never produce the highest quality of work, become much more the exception than the norm. 

This is why technical competence is so important to assess in an interview.  Not because I care about coding trivia, not because the information isn’t readily available on-line, and not because it’s a measure of IQ.  It is important to measure technical competence because it is one indication of a person’s attitude towards excellence.  It is one measure of whether a person is limited by their own sizeable potential, or limited by their lack of passion.

BIBS

The following is a true story.  Anna Maravelas of TheraRising.com writes about in her book How to Reduce Workplace Conflict and Stress.

A man is late for a meeting and seems to be hitting every red light on his way to his appointment.  He gets to yet another red light and is behind a woman in a sedan.  While they are waiting for the light to change, she turns around and begins foraging in the back seat.  Perhaps she is looking for lipstick or a CD or who knows what.  But one thing is certain; she is oblivious to the light.  The light turns green.  The man taps his horn.  She ignores him and keeps searching the back seat.  He is now more aggressive on his horn.  She not only ignores him, she gets out of the car, walks to the back door, opens it, and continues foraging!  He is outraged.  He is now leaning on the horn, and has rolled down his window so he can tell her what he thinks of her lack of consideration.  Eventually, without any acknowledgement, she returns to her front seat and drives off.  Another self-absorbed, oblivious driver.

That night, the woman writes a letter to the local newspaper.  She wants to tell her side of the story.  Her story is this:  Today I was sitting at a red light when I sensed something was wrong.  I turned around and saw that my toddler son in the back seat was choking on something.  Frantically I turned to help but could not reach him.  I jumped out of the car, threw open the back door and – thank God – I was able to dislodge the thing he was choking on.  All of this took a minute or two.  I was fighting to save my baby’s life.  There was a man behind me honking his horn and shouting profanities at me.  He was indignant because I may cause him to sit through a two minute light again.  I could not believe how rude he was.

BIBS stands for Baby In the Back Seat.  It is an acronym to remember this story.  It is an acronym to remember that we have a strong tendency to attribute negative motivation when people behave in ways we do not like, or do not understand.  The stranger does not return our hello greeting because he is arrogant.  The supervisor is overly critical because she is petty and controlling.  The babysitter does not show up because she is a typical irresponsible teenager.  We don’t know why this behavior is happening.  But we tend to invent reasons, and the reasons do not show grace.  How strong is this tendency?  Even when you are aware of it you will still catch yourself doing it. I speak from experience.

Testers and developers have jobs that are converging, but their approaches still cause conflict.  The tester logged multiple low-priority defects because he is anal-retentive, or lacks judgment or is trying to make development look bad.  The developer  gave a demo of a new feature without inviting the tester because he does not think about testing, or does not think the tester adds any value.  This thinking makes a problem worse.  BIBS reminds us to deal with the problem and not the person.  Testers and developers don’t always understand each other well – the pressures, the thought processes, the motivation.  As leaders, BIBS is a tool we can use to remind ourselves and those we influence to show each other grace and focus on the why without vilifying the who.