Knowing What to Tap
Written by
David Goodrich
Tuesday, Mar 24, 2009There is a fine line between good software developers and excellent software developers. Often it is difficult for a non-technical person to understand some of the nuances that separate the good developers from the great developers. A few months ago I wrote an article describing “What Defines a Good Software Developer”. Now I would like to provide you with a little exercise you can use the next time you interview a software developer. Please keep in mind that this is equivalent to a single question and should not be seen as the “one and only” test. You have probably heard this story before:
A woman takes her car into a service station because it is running poorly. She watches as the mechanic opens the hood, stares at the engine for a few minutes and then taps the engine with a hammer. Immediately the car starts to run perfectly.
“That’s amazing” the woman says.
“Thank you,” replies the mechanic, “that will be $100.00.”
“$100.00?” she exclaims, “All you did was tap the engine with a hammer!”
“Yes, it is $5.00 for the tap and $95.00 for knowing what to tap.”
Many situations that software developers face in their day to day routines present them with similar problems. For example let’s represent an arbitrary instruction set with:
1001 1111 0110 1010 0101 0011
As long as we chain these instructions, in this sequence our application will work. Suppose you have an application with twenty-five of the above sequences. Someone makes a change to the application and breaks the application. Your manager asks you to fix it. What do you do? Now, since this is targeted to non-technical people, I will be nice and tell you before hand that there are exactly five errors in the non-functioning application. Finally I will give away, for free (a luxury software developers are never given), that three of the errors are data related (meaning the instructions are out of sequence in three places) and two of the errors are syntactical (meaning that there are two bogus instructions in the code).
Here is the bad code – find the errors:
1001 1111 0110 1010 0101 0011 1001 0110 1111 1010 0101 0011 1001 1101 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 0101 1010 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 010O 0011 1001 1111 0110 1010 0101 1001 0011 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011
Did you find all five errors? Usually, code is kept in source control, meaning that versioned copies of code are kept in case something happens (like our scenario) and an older version is needed to compare changes against. So I will now provide you with a copy of the good, previously functioning code.
Here is the good code:
1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011 1001 1111 0110 1010 0101 0011
Did having the correct code to compare against help you find the errors? Still not too easy, is it. Now imagine that you are trying to perform this exercise while the Vice President of Software Development is sitting in a chair next to you, asking questions about what you are doing and occasionally making suggestions to help you along.
Back to our point - how does this help you determine a good developer from a great developer? Use the exercise above the next time you interview a software developer. Ask him or her to briefly describe how he or she would attack this problem. Beginner / Mid-level developers will most likely attempt to brute force their way through the sequences above and spend hours ferreting out the errors. Senior developers would probably load the bad and the good sequence blocks into a DIFF tool (like SourceGear’s DiffMerge) and find the errors in less than five minutes.
I realize this is a very simplified exercise (but then interview questions should be) however, I have witnessed such scenarios many times during my career - guess how I learned this trick when I was a newbie.
So, where are the errors? Sorry, but I already gave away the big secret – now that you know what to tap, go to it!